FSX Hidden Costs of Complexity

[n4gix]

While working one of my projects, I've finally run across a model for which the complexity has become a major stumbling block to progress. To wit, the overhead panel for a 737-200C...

This thing has so many moving parts (switches, switch guards, knobs, needles, etc.) that the overhead (pun intended) cost is enormous!

Just by itself the completely animated and scripted overhead panel has:

29,326 Texture Vertices (tverts) and 161 Drawcalls (DCs)!

The complete cockpit alone has:
143,274 tverts and 667 DCs...

Although this successfully compiles, I've noticed that some of the smaller objects, such as the compass ball, and some LED lights are not being drawn in the sim at all, which of course is quite unacceptable!

I've been trying to find a workaround this problem for the past two weeks and I'm at my wit's end. I even took the time to strip out any and all mesh that can't be seen (such as the fully detailed seat bases, 3d circuit breakers, and so forth), but even reducing the total poly count hasn't fixed the disappearing parts issue...

Worst of all, should I include anything other than the cockpit in the model, the animated ailerons, spoilers, leading edge devices, flaps, rudder and elevator/horizontal stabilizer B L O W UP into huge, misplaced and unanimated objects in the scene...

I've also taken the time to eliminate all of the warnings about Degenerated Polys, and made certain that two errors about "Index Buffers" overflowing (too many tverts per FSX Material) have been eliminated.

Any suggestions beyond what I've already tried?

 

[Au-MaV]

Hi Bill
I vaguely remember Rick Piper had an issue with his goshawk t-45 VC that had duel cockpits..He ran into similar problems when the animated parts exceeded a certain number, not sure the numbers but it was I think around 250ish..We just thought it was a fsds issue and Im not sure if he found a fix...

 

[FelixFFDS]

Totally off my rocker ....

Can the sim handle switching between models (mdl files), depending on the view?

Example, in the front view you see 737A_interior.mdl; but when the view clicks to front_upper - the model is switched to 737B_interior.mdl, and a static graphic replaces whatever portion of the "front" view is visible...

PRO: you only have certain portions of the interior "active" at any given time.

CON: the static graphic has to be "blurry" since the "current" values of the semi-visible gauges and switches would be fixed (but the user's eyes will be on the now active switches/gauges)


Alternative - the same - view sensitive - as above, but using one mdl file, creating a masking static graphic to hide the non-"active" sections


------------------
Basically, this is drawing from the "old" fixed cockpit concept of switching panel sections on/off, except that the switching is "controlled" by the mouse movement - when the view goes into a certain quadrant-of-view, the active section "comes to life" and the section you just left becomes a static graphic.

You would get some "flicker" (for lack of a better term) as you pan from one "section" to another.


(Courtesy of Inspector Poly's Think Tanked)

 

[Zeiten]

Had / have the same problem you are encountering.

Parts with animations and visual conditions started disappearing.
Removed some parts and others came back etc etc.

The only solution I came up with was to replace most of the tiny polygons used on most buttons to indicate ON / OFF e.g with mapped 2D gauges.

 

[Heretic]

Well, I'd try to reduce part count by whatever means possible.


Also, 650+ drawcalls is hardly acceptible in my book.

 

[Daniel-45]

Hello,

Not sure.
But we have to stay with an FS core code coming frome ages...
-
Even with sp....
You are never sure to avoid an "overflow" for a reason or another.
-
Perhap's we could name it "limitation".
Somewhere "FFF" or one or two "F" more ...
Then you reach the limit of a precise acceptable value.
Just because it was dimensionned on 16b not more ..
-
Transcoder "Gmax or 3ds to FS" are perhap's somewhere the same.
They are old.
Ten years old for the youngers ! ;-))
-
Polys ?
Drawcalls?
Who know ?
-
How do you count DC ?
Just because it's the kind of test I will like to do.
-
Just for fun I'm ready to do a "bad beast" .
And make measure.

Daniel

 

[hairyspin]

..He ran into similar problems when the animated parts exceeded a certain number, not sure the numbers but it was I think around 250ish..

That being the case I'd hazard a guess the limit would be 256 animated parts, but I'd like to hear how many animated parts Bill's VC actually has.

 

[n4gix]

That being the case I'd hazard a guess the limit would be 256 animated parts, but I'd like to hear how many animated parts Bill's VC actually has.

I'm glad that I asked for ideas, because the problem is an excess of animations. Whether it is animated objects or XML script animations remains an open question.

In any event, I've found that if I omit precisely 16 animated objects, the missing compass ball shows up again. Why that specific object is the first to be "dropped" is a mystery, but it is the one constant "flag" that the limit has been reached!

According to my buildlog.txt, there are currently 498 unique animations defined in the modeldef.xml for the virtual cockpit.

As for how to "fix" the problem, I guess I'll have to begin by replacing most if not all of the "3d drums" and substitute either XML or C gauges for them if I'm to have any hope at all of bringing the exterior animated parts back into the interior model.

 

[n4gix]

Well, I'd try to reduce part count by whatever means possible.

Also, 650+ drawcalls is hardly acceptible in my book.

They are what they are only because every animated object by necessity will generate one draw call. There's simply no way around that!

The overhead panel for example has 161 drawcalls, only five of which are static objects, each of which is mapped to separate FSX Materials (five bitmaps). That leaves 156 animated objects...

The interior model of the T-38A has a total of 434 drawcalls, but also is much less complex, despite having dual cockpits.

 

[Luka]

I'm not sure that this will help, but I remember that I had a similar problem with FS9. I read somewhere that it is not a problem in a number of animated parts, but the overall complexity of animations.
First, I replaced the length animations from 0/100 to 0/1 for all on/off switches, because there is no real animation, but just jumping from one position to another. Same for selector switches, I left only required number of keyframes. Also as you say, I replaced most of 3d drums with simple 2d gauges, because neither of them have no real animation, just jumps between values (except on altitude counter).
Once again, I'm not sure that this will help for FSX.

 

[Heretic]

Bill:
Are the "on/off" switches keyframe animated?
What about just "reducing" them to "visibility" style animations instead?

Or getting rid of any keyframe animations for the switch guards...

 

[n4gix]

Thanks for the suggestions Luka & Heretic.

All switches are keyframe animated. What is confusing is that I've been unable to confirm whether the apparent "limit" is related only to the total number of animation definitions, or if <Visibility> definitions are included in the total.

The reason being that the specific symptoms of "overload" progress from a single animated object (the compass ball) to <Visibility> objects.

1. compass ball (animated object)
2. parking brake light (visibility object)
3. LED lights (visibility objects on the cargo bay smoke/fire detect subpanel)

This is as far as I've gone in diagnosing the sequence, as beyond this point whatever objects are affected appears to be somewhat chaotic and random. But, at 'step #3' the sequence of LED lights failing to appear is predictable. Each additional animated object I remove enables the LED lights to appear one at a time until all of them are being displayed.

Reworking the animations on the overhead to reduce keyframe "load" would be a massive undertaking at this juncture, without any guarantee of a positive outcome.

For whatever it's worth, the XML script for this project currently is a total of ~27,000 lines...

As for the drum objects, they are keyframed at one unit per step, i.e. either 0-9 or 0-11 (some drums have a 'blank' and '-' face in addition to digits 1-9).

 

[lionheart]

This 'might' be the 'bottleneck' issue based on system RAM that the 32bit compiler experiences.

Maybe give the 3DS Max 64 bit compiler that Sean had made for Prepar3D a try and see if that compiler will produce all of the animated objects in the scene.



Bill

 

[n4gix]

This 'might' be the 'bottleneck' issue based on system RAM that the 32bit compiler experiences.

Maybe give the 3DS Max 64 bit compiler that Sean had made for Prepar3D a try and see if that compiler will produce all of the animated objects in the scene.

Bill

I had completely forgotten about that. Now there's an idea worth trying, if I can find the link to download it!

 

[lionheart]

I had completely forgotten about that. Now there's an idea worth trying, if I can find the link to download it!

Good luck on that. I have no idea where it might be. He was working with Lockheed Martin, so it might be in the Prepar3D forums.

Sean had a prototype here for download for a while.

Does anyone have his email?

 

[hairyspin]

XtoMDL x64

The link is here

 

[n4gix]

I found it on his Blog. Evidently he's not been too active at further development, since the latest blog entry is from the beginning of this year!

 

[lionheart]

I found it on his Blog. Evidently he's not been too active at further development, since the latest blog entry is from the beginning of this year!

I was hoping that they (Prepar3D) would have integrated his work into the P3 SDK by now. Odd...



Bill

 

[hairyspin]

Erm, I'd say he hasn't been too busy with his blog! He posted here in Sept/Oct about progress with his modeling toolset. His blog is probably as active as my Facebook page: gosh it's dusty in there.

 

[n4gix]

FOLLOWUP:

Okay, now that I've taken some time to do some serious investigation, here are some observations I've made along the way.

1. The "exterior parts" required by the interior model has only 25 unique animations, so it's not a major contributor to the overall animation limit problem.

2. The entire interior model (including the above mentioned #1) has 520 unique animations, the vast majority of which are "custom XML animations."

3. All animations are included in the compiled model, even if the objects that use them are NOT included in the compiled model!

For example, I have two separate autopilots; SP77 and SP177, only one of which will be in any given compiled model. By saving the SP77's objects to a new .max file, and deleting them from the current scene, I've now reduced the animation count by 27, making the total number of animations in the model only 493...

...which oddly enough is just enough to allow the entire model to compile and be seen properly in FSX.

Because of this, I've come to the conclusion that the actual animation limit is 500...

4. Visibility tags are not counted as "animations," which makes sense because they don't require any GUIDs, hence no <Animation.../> entries.

Because of this, every two or three position switch that currently uses an animation can be replaced with two or three objects representing the off/middle/on positions, and use <Visibility> to control their appearance!

In any case, now that I've found a new road to follow, I'll begin by replacing all of the switches in the overhead (the biggest offender) with static switch objects and eliminate as many animations as possible!

ADDENDUM:
I've tested using the <Visibility> and confirmed that it will reduce the animation count by one for each simple switch that's modified. There are 69 such chrome toggle switches on the overhead alone, so that is a substantial reduction already!

The "Bad News" is that I've got one shed-load of XML to revise now!