Macser

Yeah. Keep collision meshes (geo) as simple as you can. Fire geos can be a little more specific. But don't waste your time making them conform to the res lods. Simple closed shapes are best. The way they look is irrelevant, as you'll never see them. Simpler shapes give an engine less to keep track of. If you look at Bnae's video on the last page you can see he's using Cycles as opposed to Blender internal. At a base level the output would be pretty much the same. Although Cycles tends to be slightly more accurate. But to be honest, not in a massive way. Not in relation to baking at least. But the one advantage it does have is the ability to use a cage to control the rays. It's not as good as xnormal. Few applications are, seeing as that's what it was specifically designed for. But nonetheless it does work, and depending on the model it can produce comparable results.

Where quads are preferrable is during the construction stage. So always keep a source model in quad form. They're easier to manage for edits. They're also well suited to characters. But that's another discussion in of itself. Tris and ngons are fine most of the time within the application you're using. Particulary for hard surface models ,where you have open areas without any changes in angle from one loop to another. Games are slightly different. It's better to have the model fully triangulated for the finished p3d. Although it's not a requirement. The main reason being, that you don't know in advance how the engine will turn the edges once it triangulates the faces. Before rendering in game all models are triangulated anyway. Regardless of how you've constructed it. Here's a quick bake down, from a sub surfed model to a simple low poly. distance at 0, bias at 0.1. Both models are smooth shaded with autosmooth on and set to 180 degrees. The low poly doesn't need to be super detailed to look decent. When ever it's possible put your seams in places you might expect to see a break or some sharpness in the real thing. Getting rid of seams can be a pain in the neck where normal maps are concerned. The less work you have to do with them, the better.

The high detail version of your models don't need any materials or uv assignments. All you really want from them are the normals. The low detail version is the one you bake all the information to. So it will require materials/uvs. Unless you actually want those sharp edges then you should make sure both models are set to smooth shading. The low poly should follow the contours of the high as closely as possible. For the caps I'm not seeing any faces. So I'll assume they're ngons. Although there's nothing wrong with ngons, there's certain situations where they don't work as well as you'd expect. Especially for game models. I'd break those caps down into tris for the low poly.

It's well made. The unwrap looks good too. The only part that would raise an eyebrow for me would be around the filling hole. The top section could be reduced without messing with the overall look. It doesn't need to be contiguous. The cap/filling hole could be separated from the flat section. Which could help with any shading errors around that area, if there's any present. The ridges along the main cylindrical section could be done without too. But that's debatable, as unlike the top section they do contribute to the silhouette. I think it's a personal choice for you more than anything else. You could certainly go with something a lot less detailed. And I think most would for something that adds to a scene, rather than acts as a focal point. As was suggested, baking might offset some loss of detail. :)

I've looked at one of the accounts not long after it was created. You can see them quickly slot in the replies to various threads to get the post count up, and then go from there until they're presumably shut down. I don't think it's possible with that kind of system to completely filter them out. I'm on another site where the post count not only needs to get above 10 for a new member, but each of the posts is moderated until that limit is reached. Because the moderators are volunteers there too, it can take a while for a post to be vetted. As they obviously have other things to take care of. One post can take 2 or 3 days to get cleared. Even if you reply to a few, they're still seen based on the number of moderators available. It seems obstructive, or even harsh. But the fact you have to wait for each individual post to be vetted will test the patience of a real person. I've seen more than one get pretty angry about it and basically storm off. If you're genuinely interested in being there you'll wait it out. Considering a human spammer wants immediate access and the ability to flood the place as soon as possible, they may not bother to hang around. It's more a psychological than technological approach. Whether that would work here though is another matter. And of course this is a site linked to a commercial enterprise. I'm sure it's a balancing act between security and potentially discouraging a repeat customer.

Yeah. Where I've had similar issues I've run the cabling along the back of the arm. Not following it exactly. But close enough that it can flex in line with it, rather than countering it.

So how much range of motion were you hoping for in the cables? I mean have you tried using the standard bones and blending the weights between the selections? Without extra bones it wouldn't be perfect. But it may be possible to get something acceptable at least.

Blendanims are used for procedural animations. In practical terms that's the tilting of the upper body sections when the player or AI look up and down. It takes what ever animation is playing and offsets it by the required amount. Blendanims gives you a bit of control over that. so you could in theory reduce extremes in the offset between the selections in the torso. Abdomen, chest , neck and head. But it doesn't relate to the weighting of the model. Not directly at least. Because of this procedural type of animation, and the fact the bones affected by it are hard-coded, anything above the waist will not be included in the tilting up or down. Although you can add new bones. You can't add them to the hard-coded bones. For example, if you added finger bones, they'd animate fine and maintain their positions as you key framed them. But as soon as the character looks up or down the fingers will stay exactly where they are. Even if you include them in the hand selection. I assume they work like config based anims. This is based on practical experience, rather than reading.

Maybe. But simply having a majority doesn't make it a good choice. I don't think he's in because he's the best one for the job. It's just as likely people are angry about the current political and economic state of their country. And wanted what they see as an alternative to the usual parade of slimy two faced double talkers they get come election time. More of the same in other words. Ironically he's as much of a shit talker as any career politician. He's made some promises "bigly". It'll be interesting to see how he actually gets it done.

Brilliant.... <_< I suppose it probably didn't really matter in the long run. I feel like they're both lying windbags. Not that all politicians are bad. I just haven't met or seen any I'd trust to run a sweet shop. Never mind run a country ( into the ground?). I wonder if we'll be able to see the wall from space.

That looks like it should be a fairly tough nut to crack. :)

It happens. I've often overlooked things staring me right in the face. Sometimes a fresh pair of eyes is exactly what's needed. :)

I just meant that the only problems that you might encounter with rtms would be the creation of them. But that process won't cause what's happening to you. I know one thing for sure. If you ever see a character default to the zero frame, or t-pose as it's often called, then it's because the engine can't find the animation it's being instructed to play. It's not an animation as such. Think of it like the base state of the model. With no rtm playing on it that's how the model looks. Now that I've said that I looked back at your config. file="foxholestand.rtm"; Tells the engine to look for \DTA\Anim\foxholestand.rtm. I assume you didn't pack your own rtm in there and re-binarise it. It should ideally be: file= "\myfolder\foxholestand.rtm"; Where you specify a custom addon folder containing your rtms. It's not enough to put the rtm in your addon folder. With custom data the engine needs the correct path to the folder specified. The path should always start with a backslash, followed by the addon folder name. A subfolder if needed. And then the actual file name. As I said. My mind's not in tip-top condition at the moment. :) Even if the proxy is roughly placed the rtm can be used to correct the character's position.

Hello. My head's a bit fuzzy at the moment. Got a cold. I don't see anything that pops out at me. Have you tried setting the scope value to public/2? The only guidelines relating to a rtm would be in it's initial creation. Other than that, you reference it in configs or scripts like any other source file. In the same way you would textures or sound samples. Edit: Actually you shouldn't be able to select it from the mission editor if the scope is set to 1 or protected. Are you sure you're actually selecting your addon and not a "duplicate" or similar class without a custom animation?

Hopefully I can help spad out, by finishing the content I intended to when the project started. :)

Ok. If you're happy doing it that way, that's up to you. But I only used the vehicle anims as an example. Probably not the best way to illustrate it though in hindsight. Anyway it works the same way for other animations. If you found yourself something closer to your surrender anim amongst the default classes it might look better. Happy to help in any case. :)

I didn't mean add them to that class. Rather create two new classes that it connects to and leads into a terminal state. Dead states will have a "terminal=1" entry in their definitions. Or grab a couple of appropriate classes that already exist. I don't have access to A3 content, so I can't cite examples. It would be similar to how static vehicle anims work. You have the default anim with variants, or not, then that connects to a "dying" state. The dying state in turn connects to a dead/terminal state.

What other stuff? Other than the max toolset there's literally nothing else out there. So there's no basis for comparison. How can something that's been released for free and taken a good chunk of someone's time be bashed? It does exactly what Alwarren intended it to do and more. If people have any problems with it, the most likely reason is their own inability to use it correctly. Sometimes people just don't have the time or interest to keep these tools updated. If that happens, then we just have to accept it. They don't owe the community anything. Least of all, reasons. In fact I'd suggest it's the other way around. :)

Ok. I may be barking up the wrong tree, as the saying goes, but I think you need that animation to connect to a dying state, then on to a dead/terminal state. As to what would be appropriate, If there's already a surrender animation in CfgMovesMalesdr it should have a sequence of states it connects to cover a character being killed. Right now, to me at least, it makes sense that the animation just locks in place. As it's not connected to anything else. Assuming that's the full definition.

The weights are already present in any available sample model, whether they're characters, vehicles or weapons. They take the form of named selections. In Blender these are represented as vertex groups. They are present when you import a model that already has named selections. On export of a P3D these vertex groups are saved, again, as named selections. As I mentioned already that's how I created my blend file. I didn't create any weights. The bones in the armature are named exactly the same as the selections in the model. The vertex groups. All I did was bring in the A3 samples and apply an armature modifier to them. By default the modifier uses available vertex groups to bind to a mesh. There's no magic or complicated procedure for that part. You don't need to parent the mesh to the rig or do any automatic weights as it's already weighted. Nothing is created by the modifier. It simply grabs the existing vertex groups and forces them to follow the bones, based on the weight distribution. The A2 example I posted above wasn't edited in any way either. It's just a sample model with an armature modifier on it. The modifier is obviously not "applied". It remains active to accommodate deformation. The only editing you would need to do, is what Al did. Make them suitable for an A3 character mesh. Which means pulling around verts to make sure the A3 mesh doesn't poke through any of the clothing,vests and equipment. For a uniform you would need to fill in the gaps in the upper torso, as the A2 meshes have none behind the vests. Of all the processes you might encounter, this is one of the simplest to deal with. Animating and then creating the configs, is the tricky part. Note: If you were interested in creating a rig of your own the rigify addon is very easy to setup and modify.

It will show the textures plugged into a material. But it's only reliable with diffuse/colour maps. The tangent basis is different for normal maps, and the channel setup for SMDI is different too. So they won't display correctly. It may be possible to use cycles to invert/ mask channels. But it's not something I've done. :) The main plus point to using something like Blender is the modeling and uv tools. Which are far more flexible and well featured than O2/OB. Even if you can't see some textures you'll still be able to verify they are well mapped to the faces. As for creating lower resolution lods, the first 2 or 3 at least are probably best done by hand. Mostly because they could still be close enough to see any big changes in the topology. After that the decimate modifier will do a decent job reducing polycount, while trying to maintain UVs and the general silhouette.

Ok. I want to be crystal clear. The models inside the Armarig blend file are from the BI A3 samples. The weights are unedited. What ever weight distribution you see is from BI. For me to have made any edits would've defeated the purpose of creating it. Usually you would do the weighting after the character has been created. In this case though they already exist. I made absolutely no changes what so ever to the weighting. :) There's no need to use my rig with either the toolbox or for any other purpose. I just made it to give people something to animate with or check out model deformation without having to create their own. Which can be a tedious process if you're not used to it. Or just unfamiliar with Blender. A rig allows you to check your model against the default samples. The best way to find areas that are clipping or deforming badly, is to put the character into some poses, or do some simple animations. This will show up those areas before you start going in game. Otherwise you end up bouncing back and forth from game to modeling software until you get it right. This is probably more important for A3, as the character and the clothing are separate. Which is why Al had to do some reconstruction/adjustment of the meshes. Otherwise the arms, legs and other areas would protrude through the clothing. As for that model. I'm not exactly sure what happened there. If I bring in a default A2 east soldier and just add an armature modifier, I get expected deformation. Is it a custom mesh?

Are you exporting/importing to a particular format other than P3D? Why the need for so much trial and error? What you see in the viewport inside Blender is what you get in the viewer for O2/OB. You can apply a tiling texture to faces and scale the UVs any way you like while seeing it in real-time in the viewport. Depending on the construction of your mesh you can easily dissolve edges/verts without collapsing the borders. On top of that you can also decimate without losing the Uv coordinates for lower res lods. And you're right. It's highly unlikely the developers use something like Object builder for anything other than very small adjustments, if at all. And with good reason. It's very limited.

If you intend on having some underground, how are you going to access it? I assume the terrain will clip into it unless you can somehow carve out a piece. So is the object center at the base of the building? Or situated where this basement level begins? The object origin in blender usually equates to the ground plane in O2.

Based on the information available, that's how I read it. :) BI wiki quote: 1 stands for discrete skinning values (0 or 100 % for each vertex of every selection), 0 stands for non-discrete (each vertex may have different skinning values for selections - animations have just partial effect on that vertex) In practical terms 0-100% = No influence at all, or full influence on every vert in a named selection. Great for a tank,car or something robotic. Not so good for something more organic. I don't really know if it actually normalises the weights based on that value. I had a look at the source files myself, and exported it to P3D. The rtms play fine and the mesh deforms as it should. I can't be 100% sure, but I think it's more of a config issue than anything else. Perhaps a mismatch between the bone hierarchy in the rtm and the model.cfg.