A Theoretical Question

[N2056]

My understanding is that animations add to the draw call count, and as such could adversely affect performance in sim. I have a lot of animated keys on the XLS+. Many of them have two parts. One is the day version, and the other is the night version (using a different material). Both parts have their own animation, and only one is ever visible at a given time. If I were to use a animated dummy that both parts linked to would it make a difference? I'm not sure it would as both parts are never displayed together.

 

[N2056]

So after a bit of experimentation I don't see a difference. It would seem that it is the motion of the part that counts...how it is moved seems to not matter.

 

[ErickC]

This is what bothers me: I am doing something right by accident, and I have no idea what it is, so I can't help you. I don't have any of the drawcell-related problems that other FS developers do. None. Nada. Zip.

Let's make a quick comparison here. The last full-resolution, complete FSX model I did was the DC-8-61 for Dreamfleet (project ended up in limbo when my life went out of control and I left FS). The closest comparison I can draw is with the default 737. The landing gear has a similar number of animated parts (but more wheels), the flaps have the same number of segments (four, but I modelled the entire transmission, so mine are an order of magnitude more complex), it has a similar number of other moving things (plus twice the number of engine-related animations), and it has the same number of maps on the external model (two). The 737-800 has a triangle count of 22866 (besides the point, I know, but I tend to think in terms of a triangle count/drawcell ratio for some reason that can be best described as blind faith) and a drawcell count of 162. The DC-8 has a triangle count of 43765 and a drawcell count of 106. Something doesn't add up - the 737 somehow has more animated parts in its list, yet it also has fewer parts that actually move.

When I moved <insert name of project here> from FS9 to FSX, and added the fancy schmancy maps (and upped the triangle count by 2,000 or so, which is besides the point, I suppose), I only gained two drawcells. It went from 47 to 49. I had to animate parts that were not animated before, and clone each wheel. By current "FSX developer logic," I ought to have gained two from the elevators, six from the wheels, two from the ailerons, and one from the rudder. It should have 58. I only gained two overall.

Maybe it's because everyone and their grandma is using 3DS and somehow GMax exports more efficiently? You guys know this stuff better than I do. I just build airliners.

 

[Heretic]

The export format ist standardized. Both 3ds Max and GMax export in X format and XToMDL turns the result from an X file into a, well... MDL file.

 

[ErickC]

That's what I figured - as far as I knew the export process was basically the same. I'm at a loss for ideas. I'm willing to hand test models over to anyone who would like to investigate. I somehow doubt my workflow is all that special.

 

[Heretic]

It could be that unused animation types in keyframes also drive up drawcall count. (G)Max tends to assign all three types of animation (translation, rotation and scale) to, say, just a rotation or translation animation when manually placing keyframe markers or accidentially moving or rotating the part. This at least produces a lot of empty animations that tend to clutter up the animation list when the exported MDL file is viewed in ModelConverterX. Maybe worth an experiment?

 

[ErickC]

Possibly - part of my process is that I always create only the keys I intend to use, and only animate once my keys are created!

 

[n4gix]

Hmmm... I always use "AutoKey" when doing animations.

 

[Lane Street]

The 737-800 has a triangle count of 22866 (besides the point, I know, but I tend to think in terms of a triangle count/drawcell ratio for some reason that can be best described as blind faith) and a drawcell count of 162. The DC-8 has a triangle count of 43765 and a drawcell count of 106. Something doesn't add up - the 737 somehow has more animated parts in its list, yet it also has fewer parts that actually move.

Would LODs have anything to do with this?

cheers,
Lane

 

[ErickC]

That probably it explains the animation list, but even still, drawcells in modelconverterX are calculated on a per-LOD basis.

 

[Ronald]

Can these articles be of any help to this challenge?
Directx10 (and the DX10 fixer tool):
- http://www.mutleyshangar.com/reviews/bc/dx10/dx10.htm

Steve's FSX technical analysis website (about drawcalls)
- https://stevesfsxanalysis.wordpress.com/
- https://stevesfsxanalysis.wordpress.com/category/drawcalls/

Intel's Graphic Performance Analyzer tool (which enable everyone to really measure what goes on under the hood?)
- https://software.intel.com/en-us/gpa
- http://gpa.helpmax.net/en/intel-gra...introduction-to-the-intel-gpa-frame-analyzer/

 

[ErickC]

I had a thought today while animating a main gear assembly. My understanding of drawcalls is that they basically add up to:

(number of meshes) x (number of materials in those meshes)

Ergo, if I have a fuselage, and it's one part, but has two materials, and I have a wing, and it's one part and one material, and those two meshes and three materials are it, and nothing is animated, then I ought to have three drawcalls. Fuselage would be 1 x 2, wing would be 1 x 1. If I had another five parts, and those used, say, the wing material, then it would be Fuselage ( 2 x 1 = 2 ), and the wing parts ( 6 x 1 = 6) for a total of 8 drawcalls.

I am incredibly lazy, so I combine parts - especially parts that have to be mirrored - relentlessly. If any two parts share a pivot and move together, I combine them. So someone who has a landing gear composed of several parts, but all linked to the top assembly, would have way more drawcalls than me, since I would simply attach all of those meshes into a single part (and treat every part as a "mini-scene" in and of itself, selecting and hiding certain elements when it came time to map).

Might this, combined with my not wanting to manage more than three or four texture sheets, be why my drawcall counts have historically been so low? The default airplanes seem to follow this methodology (hence the awkward shading on the 737 vertical stabilizer - the ten or so extra vertices would have been worth a separate smooth group, I think).

 

[Heretic]

The number of objects per material is irrelevant since XToMDL/MakeMDL collapses the mesh for each material into a single object. If objects A, B and C share the same material and object C is animated, objects A and B will be collapsed into object 1 with their material while object C will receive a clone of the shared material and become object 2 in the .mdl file. Import a .mdl file into ModelConverter and take a look at the hierarchy editor. You'll see what I mean.
This is also what makes importing precompiled objects into 3ds Max or Blender (with the permission of the original author, of course) so annoying since objects are clumped together by material, no matter where or what these objects were before.

The rules of thumb for drawcall- and memory-efficient models remains: As much detail as necessary with as little vertices, animations, materials and texture size as possible.

 

[ErickC]

I'm not disagreeing with you, I'm talking about the way I combine animated parts that share motion. I do it because I don't want to clone multiple parts and then rebuild a whole hierarchy. If I have a main gear that has a side strut that links to a pushrod - say, a 737s - and if the pushrod itself contains the common axis of rotation, I will just attach the strut to the rod. I don't know how common my methodology is, but I've had friends send me their models, and I seem to be the odd one out in that department.

 

[Heretic]

Just wanted to clear things up about your understanding of drawcalls.

If combining stuff makes a model more efficient, combine anything you can get your hands on!

 

[Amengol]

Good discussion, but I just like to say thanks to Ronald for the links. Very handy!

 

[kalong]

accidentally found this thread
this my project on MV22B Osprey showroom

model with no animation on it own (see the picture)
1. fuselage
2. wing
3. engine left
4. proprotor tip (last 2 light_L ..... and proprotor_L1....)

other than that, each model have their own animation with different coding in modeldef.xml. command animation from C++ gauge.
overall animation is good if not more 4 code work simultaneously in one hierachy. i.e. wing folding, nacelles movement, rotor head (small rotation) and blade folding, if it animated folding together it make effect to last hierarchy (blade) animated with lag.

My FOLD and STOW animation more complex than a landing gear animation, as landing gear has 1-3 different coding in complex model animation.

 

[antaris]

Hi lads

So, the bottom line here is to design following the rules mentioned by Björn and Erik?

Perhaps I am wrong, however I think is fair to mention:
If you clean your Makemdl.parts.xml / XToMDL.parts.xml files (I don't know if it is the equivalent in FSX), it could have an impact on the model performance. I think if you have additional code used for animated parts than is actually requiered by the model, this may cause more load to the system. I can't remember where I read about this, but if I am correct, it was from Fr. Bill Leaming.

Theory:
Removing "old" selfmade code from another projects and start always with a "fresh copy" of the files mentioned above, it would prevent the creation of more drawcalls. It is unknown to me if the compilers handles the entire dictionary part (aka Makemdl.exe / XToMDL.exe and equivalents for scenery). If this is true, what would happen if we use only the code required by the model at hand?

In other words, what if we carefully select the exact code (self made and default standard) and create a "thinner" version of the Makemdl.parts.xml / XToMDL.parts.xml files? Probably, a helicopter with skids will no need the default code for the landing gear or refrigeration flaps part names! Just wondering...

Starting for the obvious and for the sake of being methodical with this theory:

1. What will happen to the model with an empty model part dictionary?
2. It will crash the compiling process? or...
3. There will be no animations? (*)
   
4. Can we use a "thinner" version of the Makemdl.parts.xml / XToMDL.parts.xml files?
5. And more important, this action will enhance the number of drawcalls created?

(*) Only the ones embedded in the flight simulator's core code; in case you invoke some of them.

I will experiment with this theory and take advantage of everything mentioned here. I hope this makes sense and that it is also happen to be correct.


Cheers,
Sergio.

 

[n4gix]

Sergio, when exporting from .gmax or .max, only those things that are required are "pulled" from the modeldef.xml file and placed in the .xanim file. If they aren't referenced by the model, then they are ignored.

Whe compiling the .x and .xanim files, XtoMDL.exe will again read the modeldef.xml file and only use whatever is in the .xanim file to obtain the rest of the data needed.

Ultimately, the only real advantage from using a "thin modeldef.xml" file is that it is easier on YOU the modeler to use...

 

[antaris]

Good evening to everyone

Dear Fr. Leaming:
Just what I thought... Well, at least this is the happiest and also the fastest demystification of a theory
Thank you kindly, you already saved me from spend a couple of hours cleaning and testing this idea.

All the best,
Sergio.