"I wonder why our own shadow models are larger then the self generated versions? And you know, it just hit me. I wonder if applying 'flat black' to all of them, or a generic base material, would cut down the frame rate hit. It might be materials. For instance, I just duplicated the exterior into a shadow node, and its all textured. It may be 'floating' in the GC buffer along with the rest of the plane, making it an exterior, VC, and shadow set of models. Perhaps the 'stock' shadow model compiles with 'no materials'. (Just thinking out loud)."
You know Bill, that’s a
really good question! Namely, what effect (if any) do the materials and textures have on the shadow model?
I did a quick test with a simple model, just some tubes slapped together to look like an airplane, textured with 4 different bitmaps, and a different material was assigned to each. I exported the model twice, once as an exterior model, and again as a shadow model. After compiling the .x files, I found the texture and material defs in the .asm files were identical between the exterior and shadow models. Loading that .mdl file, I set the frame rate slider to unlimited, and took note of the highest number. I then exported an un-textured version of the model, with only one material assigned to all parts, and saved it as the shadow model. I loaded that .mdl file in FS2004, and
saw a whopping gain of 14 FPS!
By comparison, turning aircraft shadows off on the first test only gained 1-2 FPS. That seems to imply that FS2004 is loading everything twice, and those resources aren’t released when aircraft shadows are disabled. I think that might be true…but I’m not competent to declare that for certain.
I’m always cautious about quick tests with simple objects. It often turns out differently when you try the same thing with a complex model vs. one with 100 polygons, and there’s no such thing as absolutes with many aspects of MSFS – there are too many variables in software and hardware among the masses - but this does seem to warrant further investigation. Gaining even half of those 14 FPS might make a big difference for someone with low-end or mid-range hardware.
I wasn’t too keen on making a shadow model for the Bull Stearman - for one thing having shadows turned on with it doesn’t affect performance at all for me, since I run with the slider locked at 30 and the FPS never dips below 60, for another, well, it’s a little more complicated on this model than on others I’ve done, and constitutes a major investment of time.
But if a dedicated shadow model, un-textured and having only a single material applied to all parts would increase performance that dramatically, then it would seem wasteful not to do it after all. And I would expect the performance gain to be even greater if low poly parts were used. For instance, I wasn’t going to use a 27,000 polygon engine for the shadow model, or wings and stabilizers with rib geometry etc. Trimming everything down is a big chore when making a shadow model, but this texture/material thing leads me to believe it could be well worth the time.
It might be the key to greatly increased performance with extreme poly models (and other models too), so you should try some tests of your own. Anyway, thanks for the heads-up!
One last thing on the shadow models: I just checked the shadow model on an old project; it’s much cut down, and it comes in at 17,000 pre-compile polygons (all textured and with multiple materials), and looks good even as an exterior model. Since my current exterior model is over 400,000, using something that size that would mean a savings of over 380,000 polys, which
should help even more! (I hope).
“On 'another' side note. I had a issue when exporting today via Gmax. Some parts were mis-locating again today. It seems to be a issue when adding more parts, that every now and then, temporarily, I will get issues suddenly popping up, then they all go away.
This time, while experimenting, I decided to change LOD numbers on the 'interior' models. They were interior, 700, 800, and 900. I changed them to 750, 850, and 950, and the darn thing compiled flawlessly. The exterior models were 'dynamic, 300, 400, 600, with the pilot section being 500, which is not in the interior set.
Why that would fix it is beyond me. I can only figure there is a mathmatical bug occurring.”
Your adventures in LOD numbers are like a trip to the Twilight Zone Bill. lol
I have no idea why that’s happening; you might try doing a file comparison between .x files exported with different LOD numbers, just to check for differences – but if you’re like me you’ll probably just move on and be grateful it works now!
