Very high poly model - XToMdl limitations - A call for help.

[Mr.FaosFX]

Thanks for clearing that up guys, I was going crazy for a minute...phew!!

 

[RGS]

Firstly a *huge* thanks to Sean for making this happen, I really can't say this enough .

Now a quick post regarding the model's performance:

The full VC model is now in FSX, displaying exactly as intended.

I seem to get about the same FPS as for other addon A/C (actually mostly a bit better); roughly 30FPS over moderately built up areas such as SE England, more rural/barren locations obviously give higher numbers with cities having the opposite effect . Whilst I'm not 'over the moon' at 30FPS (and in some cases mid 20s), this is the same for all other A/C on my setup and not just my super detailed model. In fact I have yet to find a case where my model performs significantly worse than others (barring some very simple default A/C that were carryovers from FS2004).

My FSX settings are mostly maxxed out with the exception of autogen density which is set to 'dense' and water one notch down from the max. Anti-aliasing is on and screen res is 2560x1600. My specs in brief: QX6700 Extreme @ 2.6 (stock), GTX480, 4GB Dominator RAM, 680i motherboard. Machine was *very* fast when I bought it, but that was around 5 years ago. Only recent component is the graphics card, which whilst good, I suspect that both my processor and FSX probably aren’t making the most out of it. I’m currently running the model ‘on top of’ a default FSX flight model/file structure until getting my own done, so flight dynamics, sounds, lights etc are all being used by the sim. Textures are all in place (multiple 4096s) except the emissive night variants which aren't yet hooked up. As mentioned in a previous post the only thing missing from a feature standpoint is the animations (all gauges, doors etc) and not sure how much of a hit they’ll have. This is really the only thing I’m worried about performance-wise though as it seems like the rest is working out quite well. If anyone can think of any other variables that I should take into account please let me know! I'm guessing this lack of anims is why my model has a bit of an advantage over some of the others right now, either through less draw calls (elements that will be animated need to be detached into new objects) and/or just the overhead of the anims, mouse-able points etc.

I was hoping that the FSX engine only rendered elements of the model that were on screen. So for e.g. the cabin (back) wouldn't be drawn when looking forward and the main panel not rendered when looking back. This would then mean a *huge* saving in terms of visible polycount, as this being a VC and not an exterior you only ever see bits of it at a time on screen and depending on your field of view it shouldn't ever have to display over half of the model (in my model anyway, in fact mostly *much* less than that!). With that said I seem to get the same FPS whether I only have a small part of the VC on screen or I move the camera outside and render the entire thing, so maybe FSX's culling only works on a model basis and not an object one? More testing needed here though before I'll know for sure.

Finally, if I add normal maps to some of the mesh the frame rate does take a significant hit and the .mdl file size increases massively. More on this soon as I do more testing.

Right now I'm just super stoked (and enormously relieved!) to see everything up and running as it should be. I'll have a much better idea in a week or two, but for now it's all looking quite promising .

Cheers,


Robert

 

[tgibson]

Arno has said that the entire MDL is loaded into memory, whether used or not. For example, all LOD models are loaded into memory at all times, even if they are never actually displayed. How this affects the frame rate (vs the model that is displayed at the moment) is not clear to me.

Hope this helps,

 

[lionheart]

Awesome!!!!

This is great news.

 

[theisomizer]

Posted!

See here: http://www.fsdeveloper.com/forum/showthread.php?t=126704

Let's try to keep all discussion of this release to that thread, so I don't loose my mind with so many threads

 

[Mr.FaosFX]

Arno has said that the entire MDL is loaded into memory, whether used or not. For example, all LOD models are loaded into memory at all times, even if they are never actually displayed. How this affects the frame rate (vs the model that is displayed at the moment) is not clear to me.

Hope this helps,

This is because Direct3D only renders what is currently visible. The entire model maybe fully loaded in memory but it should not impact frame rates because the entire model is not being rendered only what is visible is rendered ... if you tried to render the entire model you would have a z bias war of pixels and all sorts of gibberish appearing on the screen.

Note that in FS9 we have the option of using c_wheelwell, l_wheelwell & r_wheelwell so that these parts disappear when not visible, why Microsoft chose to do it this way baffles me. The Direct3D interface is fully capable of rendering this out if its not visible. It all works by position of vertices in 3d space, which ever vertex is closest to the camera wins and gets rendered. You shouldn't need c_wheelwell or any of that stuff to hide it from view but I guess the main reason they did this is to allow more development options? X_wheewell still is a pointless feature.

That is one of the reasons why I had to use XML to make the reverser_wells only appear when reverse thrust is activated. For some reason, FS9 believes that it should render it anyway, even when its clear that the pixels it should be rendering are the ones ahead of the reverser_well. However, there is one advantage to this, as Arno has stated, the entire model is loaded in memory, so as long as the wheel well is in place, Direct3D still has to do math to either render it or not even when using the zbuffer to do it. If you remove the part from the render queue, it gets bypassed completely which actually saves on frame rates....so hmmm, I guess its not pointless after all.

Hopefully that clears it up?

 

[Mr.FaosFX]

Firstly a *huge* thanks to Sean for making this happen, I really can't say this enough .

Now a quick post regarding the model's performance:

The full VC model is now in FSX, displaying exactly as intended.

I seem to get about the same FPS as for other addon A/C (actually mostly a bit better); roughly 30FPS over moderately built up areas such as SE England, more rural/barren locations obviously give higher numbers with cities having the opposite effect . Whilst I'm not 'over the moon' at 30FPS (and in some cases mid 20s), this is the same for all other A/C on my setup and not just my super detailed model. In fact I have yet to find a case where my model performs significantly worse than others (barring some very simple default A/C that were carryovers from FS2004).

My FSX settings are mostly maxxed out with the exception of autogen density which is set to 'dense' and water one notch down from the max. Anti-aliasing is on and screen res is 2560x1600. My specs in brief: QX6700 Extreme @ 2.6 (stock), GTX480, 4GB Dominator RAM, 680i motherboard. Machine was *very* fast when I bought it, but that was around 5 years ago. Only recent component is the graphics card, which whilst good, I suspect that both my processor and FSX probably aren’t making the most out of it. I’m currently running the model ‘on top of’ a default FSX flight model/file structure until getting my own done, so flight dynamics, sounds, lights etc are all being used by the sim. Textures are all in place (multiple 4096s) except the emissive night variants which aren't yet hooked up. As mentioned in a previous post the only thing missing from a feature standpoint is the animations (all gauges, doors etc) and not sure how much of a hit they’ll have. This is really the only thing I’m worried about performance-wise though as it seems like the rest is working out quite well. If anyone can think of any other variables that I should take into account please let me know! I'm guessing this lack of anims is why my model has a bit of an advantage over some of the others right now, either through less draw calls (elements that will be animated need to be detached into new objects) and/or just the overhead of the anims, mouse-able points etc.

I was hoping that the FSX engine only rendered elements of the model that were on screen. So for e.g. the cabin (back) wouldn't be drawn when looking forward and the main panel not rendered when looking back. This would then mean a *huge* saving in terms of visible polycount, as this being a VC and not an exterior you only ever see bits of it at a time on screen and depending on your field of view it shouldn't ever have to display over half of the model (in my model anyway, in fact mostly *much* less than that!). With that said I seem to get the same FPS whether I only have a small part of the VC on screen or I move the camera outside and render the entire thing, so maybe FSX's culling only works on a model basis and not an object one? More testing needed here though before I'll know for sure.

Finally, if I add normal maps to some of the mesh the frame rate does take a significant hit and the .mdl file size increases massively. More on this soon as I do more testing.

Right now I'm just super stoked (and enormously relieved!) to see everything up and running as it should be. I'll have a much better idea in a week or two, but for now it's all looking quite promising .

Cheers,


Robert

Great news! :-]

 

[hairyspin]

Excellent news!! Been following this thread wondering if Robert would ever find an answer to this problem, thinking probably not. Then Sean pulls that rabbit out of the hat and we all go home happy.

There's going to be a number of developers very happy with this news: I can think of a few!

 

[Lefteris Kalamaras]

I was hoping that the FSX engine only rendered elements of the model that were on screen. So for e.g. the cabin (back) wouldn't be drawn when looking forward and the main panel not rendered when looking back. This would then mean a *huge* saving in terms of visible polycount, as this being a VC and not an exterior you only ever see bits of it at a time on screen and depending on your field of view it shouldn't ever have to display over half of the model (in my model anyway, in fact mostly *much* less than that!). With that said I seem to get the same FPS whether I only have a small part of the VC on screen or I move the camera outside and render the entire thing, so maybe FSX's culling only works on a model basis and not an object one? More testing needed here though before I'll know for sure.

I recall having a discussion with someone at ACES about this (Adrian? I forget) and the quote was that there is no partial rendering of the model as the savings would be negated by the need to calculate shadowing anyway.

Regardless of the reason though, reality is - the model is always being rendered completely. I recall that in some of our Concorde-X testing we tried using visibility tags to hide (via code) 99% of the cockpit and frame rates remained the same...

Lefteris

 

[n4gix]

I remember reading of this some years ago myself. I do know that what used to work in FS9 (hiding parts of a model for performance gains*) no longer works in FSX.

 

[Lefteris Kalamaras]

I remember reading of this some years ago myself. I do know that what used to work in FS9 (hiding parts of a model) no longer works in FSX.

Bill,

just to clarify: Hiding parts of a model works fine, it just has no performance gains...

 

[lionheart]

Hiding parts (such as the engine, landing gear assembly when fully up, etc) worked great in FS9 (and still does). Sorry that it doesnt work that way in FSX. It is a great asset in FS9 for high detail that only shows on the ground.

 

[n4gix]

Bill,

just to clarify: Hiding parts of a model works fine, it just has no performance gains...

I quit typing too soon, as that was what I meant to clarify! I use hide/unhide quite a bit actually, as it's a very easy way to do custom strobe and beacon lights as an example.

This for example will "double-flash" an "lighted poly" (and/or attached effect file) every 2 seconds...

    <!-- STROBE LIGHT FLASHER -->
    (A:LIGHT STROBE,bool)
    (A:ELECTRICAL MASTER BATTERY,bool)
    and
        if{
          (P:Absolute time,seconds) 2 % 0.4 > !
            if{
              (P:Absolute time,seconds) 0.2 % 0.1 > !
              if{ 1 (>L:Strobe,bool) }
              els{ 0 (>L:Strobe,bool) }
          }