• Which the release of FS2020 we see an explosition of activity on the forun and of course we are very happy to see this. But having all questions about FS2020 in one forum becomes a bit messy. So therefore we would like to ask you all to use the following guidelines when posting your questions:

    • Tag FS2020 specific questions with the MSFS2020 tag.
    • Questions about making 3D assets can be posted in the 3D asset design forum. Either post them in the subforum of the modelling tool you use or in the general forum if they are general.
    • Questions about aircraft design can be posted in the Aircraft design forum
    • Questions about airport design can be posted in the FS2020 airport design forum. Once airport development tools have been updated for FS2020 you can post tool speciifc questions in the subforums of those tools as well of course.
    • Questions about terrain design can be posted in the FS2020 terrain design forum.
    • Questions about SimConnect can be posted in the SimConnect forum.

    Any other question that is not specific to an aspect of development or tool can be posted in the General chat forum.

    By following these guidelines we make sure that the forums remain easy to read for everybody and also that the right people can find your post to answer it.

FSXA Animations and Drawcalls

Yeah my experience is an animation will add a draw call – like everyone’s posted. Personally I don’t think using separate small textures for animated parts is a good idea. For me reducing the number of texture maps should still be the goal (along with all the other things that reduce render load).

I can’t speak for FSX but working with another game engine we were told not all draw calls were equal. This particular engine had a feature, I think we called it a soft-draw-call, were separate draw calls that used the same texture map were handled differently. In such a case the texture was carried forward and made for a quicker draw. Take this anecdote with a grain of salt…the discussion was years ago and I can’t say I had a great grasp on the technical concepts...plus it wasn't FS. But the take away message to the team was - fewer texture maps mean better performance.

Eliminating any unnecessary draw calls makes an efficient model…but with 3D gauges and such we’re still going to have plenty of draw calls ;)
 
Last edited:
Heretic said:
If <Visibility> tags do not affect drawcalls, I'll use them to "animate" switches. No one cares about the way an "On-Off" switch transitions between its two positions anyways.
Click to expand...


PropTrash got me into this with opening cowlings and things. Just make them disappear. I used to have all these crazy 'flipping and spinning' cowlings, but they do not always sit flat on the ground if the plane was parked at speed, leaving it shifted on its landing gear. Making things appear, disappear, (like engines also) removes them from the 'live draw call list' making them run more efficient.

I like the switch (flip type) with just two animation points, on/off. Smart... Alot of animations are so fast that they dont need 50 key frames.. Just two, or appear on, appear off.


If only we could retune the FSX game engine so that it didnt stammer on draw calls...
 
dmaher said:
..... Personally I don’t think using separate small textures for animated parts is a good idea. For me reducing the number of texture maps should still be the goal (along with all the other things that reduce render load).
Click to expand...

It sounds counter intuitive at first look BUT that would depend on how the drawcalls are handled.

The exact point is that whether or not you combine textures and feel that you are reducing the rendered load ... you are not. The textures associated with each identical material set get loaded into VRAM for each animation set and rendered as if it were a completely unique texture sheet. (at least that's the theory)

You cannot save drawcalls for animations by making smaller texture sheets ... but if the drawcall only pertains to those bits, loading a smaller texture will be faster and consume less video memory.

The postulated process is that if you use a combined (say 1024) texture ... that 1024 texture gets loaded n(animations) x m (material) times ... regardless of the materials being the same. If this is the case, then a combined texture will be LESS efficient, even though you have less files.

Same most-likely applies to animated / skinned elements in scenery.

So (in theory) .. combine textures for non-animated parts. Group them (by animation) for animated parts ....

Very interesting design difference.

EDIT:

Not all drawcalls are equal, but a single more "complex" drawcall is felt to be more efficient than multiple "simple" drawcalls. Eg single drawcall with a spec / shader / bump map as opposed to 5 drawcalls each with varying spec and reflective properties. You have a certain number of shaders on a modern video card ... and the most efficient use of these is paramount.
 
Last edited:
Hello hcornea,

exactly! Thanks for making my point a bit more clear. :idea:

There is yet another thing to consider: the issue gets worse if your material uses more than one texture slots. Imagine you have a material with specmap, bumpmap and envir.map. Take your control surfaces as an example. Usually one uses the same material for the wings and the ailerons for instance. But by tagging the animation all of these texture maps gets loaded to the memory AGAIN. :eek:

Again: the suggested performance optimization is not suitable for every single instance. But if you are modelling at the limit (huge, high-res textures, lots of detail, lots of polys), consider this new strategy! Just make the test and I promise you that you'll be surprised! ;)

Vitus
 
Hello again,

I wish to correct the statement previously made. It appeared to me that my assumption was wrong. My assumption was that with each drawcall, the texture maps are loaded into the vram again, that's not true! And here is an easy way to prove that:
When you change from the exterior view to the interior after some time, the interior textures are not loaded instantly all the time (depending on the complexity of the model of course). But when the missing texture is finally shown in the VC, ALL the parts that use this texture are drawn correctly at once. Therefore I think it is safe to assume that the memory is just allocated ONCE for each map.

That being said, I had this effect of a better performance after splitting the huge texture map to a couple of separate maps for the animated parts and I have no explanation for that....

For the last days I've been busy cutting out all (ok, almost all) animated parts from the huge 4096x4096 texture maps and put them into smaller maps. As a result for this work I am using... I don't know... about 50 different materials by now. It seems that the positive effect now turns backwards again, meaning an decrease of overall performance.

As a conclusion, the suggested procedure of using separate maps for each animated parts might not be feasible after all. What I want to try next is some sort of intermediate step. I will merge a great deal of maps into 1024x1024 textures and apply these to the animated part. Let's hope that this is the right way to go.

All the best,
Vitus
 
aaaaaaaaaaaah, and there is another thing I noticed:
not every animation automatically leads to another drawcall! I animated two headsets that are dangling left and right depending on the aircraft's attitude. This is done using skinned mesh animations. When I checked out the model with Arnos modelconverterX I noticed that the corresponding texturemap has only ONE drawcall. Make sense of that! :confused:
 
Vitus said:
...
When you change from the exterior view to the interior after some time, the interior textures are not loaded instantly all the time (depending on the complexity of the model of course). But when the missing texture is finally shown in the VC, ALL the parts that use this texture are drawn correctly at once. Therefore I think it is safe to assume that the memory is just allocated ONCE for each map.
Click to expand...

I'm not sure you can safely assume this ... but it does mean that the texture is loaded from the disk (perhaps into cache?) and thence into VRAM close together.

Interesting observation though.
 
Last edited:
Vitus said:
As a conclusion, the suggested procedure of using separate maps for each animated parts might not be feasible after all. What I want to try next is some sort of intermediate step. I will merge a great deal of maps into 1024x1024 textures and apply these to the animated part. Let's hope that this is the right way to go.

Vitus
Click to expand...


I remember when FSX first came out. I went to repaint the sleek Bombardier mini liner and found that they had mapped the doors to a totally different texture sheet. Making an elaborate, flowing repaint on that thing was next to impossible with doors being huge prints on one sheet, and the airliner hull on another.

I was told later that it was for 'animated parts' that Aces did this, (stock FSX airliner in the FSX package).

So... They did this also. Maybe they know something about this. But 'why' would animated parts be given separate sheets if they are rarely animated. Another words, its not a Ambient like the headphones, the doors are only opened on the ground at a stand still. I would think that grouping them 'with' the same master fuselage texture would have made sense....


Bill
LHC
 
Because they are still separate drawcalls ... even if they are not being animated. -- performance design.
 
You must log in or register to reply here.
Back
Top