What's the maximum number of animated objects allowed in a model?

[xtremepro67]

There seems to be a maximum number of animated objects allowed in a model but I cannot find any explanation for this in the SDK. Does anyone know?

I'm building a complex virtual cockpit and after reaching a certain number of animations in the model (objects that are tagged to an animation in the modeldef.xml), strange geometrical figures start popping up and flashing in the VC when the model is loaded in the sim. In addition, some animated objects are missing or appear weirdly distorted at the origin of the model (like in the middle of the cabin, in the case of a VC).

All these objects are animated properly and there was no error generated by XtoMDL.

Simply removing the animation from a few objects solved the issues. Adding a single extra switch on the main panel, and there goes the problem again.

So there must be some kind of limitation and hopefully a possible workaround. I don't have the exact count of animated objects in my model, but I don't think it's in excess of 200...

Anyway, this is a serious drawback when developing complex 3D virtual cockpits (of course, we don't have this issue on exterior models which contain less animations).

Hope someone at LM could help.

(Using P3Dv3, P3Dv3 SDK and 3ds Max 2015)

[Mike LM]

There seems to be a maximum number of animated objects allowed in a model but I cannot find any explanation for this in the SDK. Does anyone know?

There is a limit of 128 bones per model, and a limit of 64 connected bones. Any one vertex of a model can be influenced by a maximum of four bones. Models will fail if they exceed these limits. However, there is no limit on the number of animations.

You should take a look at our Online SDK under SDK > Modelling SDK for more information.

- Mike

[xtremepro67]

Hi Mike, and thank you for your input.

There are no bones in my interior model (VC). I've read the topic about the limitation in bones, but nothing about the maximum of tagged objects linked to an animation or with an attachment. Thank you for mentioning that there is no limit on the number of animations.

Unfortunately, the issues I am reporting happen only after I reach a certain number of objects tagged for animation (ex.: switches on the main panel). When this happens, I only have to remove the tag (animation) from a few switches (for example), so to lower the number of animations in the model, and everything goes back to normal.

I don't think it is code-specific because it doesn't matter which object is tagged for animation. It could be any object.

I get no error messages from XtoMDL and the MDL is produced normally. However, I get weird stuff when the model is loaded in the sim, like missing parts, dancing geometric figures that pop up on the screen, or distorted parts at the center (origin) of the model. Those animated objects that are not affected by the issue are normal and work perfectly.

[Mike Jones]

Hello xtremepro67,
I was notified about your email today, and I want to apologize for this thread somehow slipping through the cracks. The first thing we would recommend trying, since you are not using bones, would be to turn off Optimize_Parts under the Sim section of the config file.

[SIM]
SYSCLOCK=0
OPTIMIZE_PARTS=1 <---------- set this to 0

If that does not fix the problem, please let us know and we will continue this discussion. Again, sorry for the delay.

Mike Jones

[xtremepro67]

Hi Mike,

Thank you for the hint.

The modification to the Prepar3D.cfg file you proposed:

[SIM]
SYSCLOCK=0
OPTIMIZE_PARTS=1 <---------- set this to 0

is a temporary fix that worked well for P3Dv3 and solved the geometry issue. However, it is not the solution we expected. Plus it has no effect in P3Dv1/FSX, and we need to export for all platforms as we always did.

We would really like to know and understand what is causing this issue so we can maybe modify/repair the 3ds Max model before we export it, if this is where the problem is.

We consider it is not good practice to ask users to modify the Prepar3D.cfg in order for the model to display properly in the sim. Exported models should be compatible with the sim without this modification.

Again, this issue is not created by bones, or the absence of bones, as early suggested. There are no bones in our model. It occurs only after a certain number of animation tags is reached in the model (in our case, the interior model - the exterior model has no issue). If we remove a few animation tags after the issue starts to occur, the geometry becomes normal again.

It doesn't matter which part is tagged for animation. It could be any part. We don't think it's part-related. We tried removing some tags, adding a few more elsewhere, rearranging the hierarchy, etc. without success.

So there is definitely a link between the number of parts tagged for animation, or maybe the way they are organized in the hierarchy, or whatever. Please note that the geometry is otherwise perfectly normal, until we exceed a certain number of animation tags. The model is compiled with no error, and the fully animated model displays properly and is fully functional in P3Dv3 as long as OPTIMIZE_PARTS=0.

Questions:

1. Is there something we can do with the 3ds Max model before exporting it so the resulting MDL wont't need the modification to the Prepar3D.cfg file to display properly on all platforms?

2. What is the solution to produce a P3Dv1.x/FSX model with no geometry issue, besides reducing the number of animations which would seriously impact our work and compromise our project?

3. We would really like to understand what is going on here and why exceeding a certain number of animation tags creates geometry issues in a model which is otherwise perfectly normal.

4. What does the line "OPTIMIZE_PARTS=0" do exactly and why is it required in order for our model to display properly in the sim. We never had such an issue before, even when creating complex models with many animations.

Many thanks in advance for your help and support.

-Alain

[Beau Hollis]

Optimize parts basically goes through the model looking for parts that use the same material. It then creates bones for each part and combines the mesh for each part into skinned mesh. A common example of this is a numeric keypad. Because each button is animated separate, it has to draw separately, which slows things down. The optimization step can combine the entire keypad into one draw call and using a bone to animate the vertices of each button.

You mentioned adding one or two new switches will cause the model to break. If you give these two new switches a unique texture, does the problem still occur? If not, you may be able to work around this issue by using a larger number of smaller textures. With a different texture/material mapped to different parts, they could no longer be skinned and would not be modified during optimization.

It's been a while since i've gone through the model optimization code. If there is a bug or limitation in the total number of animations that can be processed during the optimization, we could likely fix it in a future release, but would not have a way to get your model working properly on older versions.

[xtremepro67]

Hi Beau,

Thank you for your prompt response. Very much appreciated.

Your example of a keypad is interesting, however, what if the keys are not animated in the same manner? Or are totally unrelated?

For example, in our model, why would the sim decide to "optimize" the yokes or the door (by destroying their geometry) when a few more switches on the main panel - which are totally unrelated and don't even share the same material and textures - are tagged for animation?

We've made a few more tests today based on your suggestions:

1. We started with the 3ds Max model at the point where we seem not to exceed the number of animations that causes the issue. This model displays well in the sim. Then we simply tagged 8 more switches for animation. When we loaded the model in the sim, suddently the pedals and one yoke were missing and some distorted polygons appeared at the center of the model back in the cabin. These parts don't even share the same material/textures and are totally unrelated.

2. We duplicated the material assigned to theses 8 switches, renamed the material and reassigned the new material (with the new name) to the 8 switches. In other words, the 8 switches now have a different material than all the other switches in the VC. We didn't change the textures however. Same issue again. No pedals, no yoke...

3. We performed the same test as in 2, but this time we assigned new textures to the new material (unrelated textures with no switches mapped on them). There are 4 texture sheets assigned to each of our materials, so we changed them all to be sure. We removed the reflection texture just to make sure that it is not duplicated. No change. Still the same issue again.

4. Starting from 3, we removed the animation tags from 2 switches. Now, the yoke is back and only one set of pedals is missing.

5. Starting from 4, we removed the animation tag from 1 more switch. No change.

6. Starting from 5, we removed the animation tag from 1 more switch. A little improvement, only one pedal is missing, is probably crunched by the optimization method and appears distorted at the middle of the model back in the cabin.

7. Starting from 6, we removed the animation tag from 1 more switch. No change.

8. Starting from 7, we removed the animation tag from 1 more switch. This leaves us with only 2 more animated switches from where we started. This time, we have no more issue.

9. Starting from 8, we reassigned the original material/textures to all the 8 extra switches. Everything is perfectly normal. No issue.

While this problem may somehow be related to the part optimization process, including the sharing of materials and textures, we tend to believe it is probably more related to a serious limitation or bug concerning the maximum number of animations allowed in a model.

The only way we could solve the issue is by removing a number of animations from our interior model, which seriously affects our project.

If you could give me an easy way to count the animation tags in the model, I can give you the magic number. After step 9 above, I can assure you, we are at the limit.


*******

Since early February, when we first informed you of this issue, you won't believe the time we've spent trying to solve it, without success. There is a limit to what a developer can do from his side:

1. In one of our early tests, we exported the model without processing the textures. We still ended up with the same geometry issue (as shown in the screenshots I've sent to Mike yesterday). Only after removing a few animations were we able to solve the issue.

2. We've split the materials so less parts would use the same material. We didn't change the textures however, just the materials. No success.

3. Then we removed the materials from many animated parts. No success.

4. Then we removed the materials from all parts in the model. No success.

5. Then we removed the textures from some of the materials. No success, although we could observe less geometrical artefacts but still many parts were missing or distorted. No success.


********

In our view, all this may be a serious issue that could compromise the work of professional developers (like ourselves) involved in complex projects with many animated parts. We believe the "optimize part" topic (and related issues, including the maximum number of animations allowed in a model, if any) should strongly be addressed in the SDK.

This has a serious impact on how professional developers plan their work, organize the part's hierarchy, decide which part should be animated, determine the number of materials and textures and how they will be assigned to parts, etc. It's important for developers to know in advance if there is a maximum number of animated parts that are allowed for a given material, texture or model, for example, or other similar considerations. There is nothing worse for developers to be caught off guard at the end of a project witch such an issue that they never encountered before and for which there is no documentation and, unfortunately, little support.

From our side, we've never seen this issue before in our ten years of developing complex addons for the Ace platform (including P3D).

Any more hint or suggestion is of course welcome.

Thank you again for your help.

[Beau Hollis]

Thanks for another thorough post. I spent some time reviewing the optimization code. I haven't found any specific animation count limitations as of yet, although I can confirm the max bone count is currently defined as 64. I have a suggestion that may help. It looks like parts already marked for skinning are excluded from optimization, so you may be able to work around the issue by assigning a bone to some of your parts. I don't have time to test the theory right now, but it looks like this would provide you a way to flag some or all of your model not to be optimized regardless of whether or not the user has the optimize parts setting enabled in the Prepar3D.cfg.

[xtremepro67]

Hi Beau,

No prob. We really want this issue resolved because it has a serious impact on the types of projects we do for both our users and professional clients. We'll do what needs to be done.

The problem is that we have too many outstanding parts waiting to be tagged for animation and we will exceed 64. Plus, these are mostly small switches, needles and knobs. I can test it with the single extra switch that is causing the issue when tagged for the purpose of our discussion, but cannot do it for all the remaining parts that need to be animated.

I could also import a skinned mesh with bones from our exterior model into the VC and link it to the main VC dummy. This will have the same effect as adding bones to existing parts. A bit tedious, but we can try.

We've made another test a few weeks ago:

We created a simple VC model consisting of a back panel and up to 1000 copies of the same animated switch. There were no other animated parts in the model however, because we only wanted to test the hypothetical limit to the number of animations in a model. Also, the switches (all copies, not instances) all had the same animation/code.

We did not observe any geometry issue, even with 1000 switches animated. They all shared the same material/textures. We found it pretty strange because in the real model, we start having trouble when we exceed a certain number of animations.

We also suspected the way the animated parts are organized in the model. For example, the switch's parent is a back panel, the back panel's parent is the main panel frame, the main panel frame's parent is a dummy for all cockpit parts, the vc dummy's parent is the main interior model dummy (root) placed at the origin of the model.

So we tried rearranging the hierarchy in different ways to see if it might solve the issue. It didn't but we noticed that each time we changed something in the hierarchy, the faulty parts (those that are getting "crunched" by the part optimization process) are never the same from one test to the next. Sometimes, it could be a missing yoke, or missing lights, or a missing door, etc. depending on how we organize the hierarchy. So it is very hard to find the logic behind all this.

Also, we observed that many parts that are affected by the optimization process are not necessarily parts that contain an animation but they all have one thing in common: they are the child of an animated part. For example, even though it's only the hinge that is animated, all the door parts linked to that hinge are affected. Sometimes, the entire door disappears when a new, totally unrelated part is tagged for animation.

Finally we noticed that it is not always the new part tagged for animation that gets affected. For example, tagging a new switch will make it fully normal and functional in the VC, but a pedal will be missing (even though both are not related and don't even share the same material/textures).

The only thing all parts, animated or not, have in common is that ultimately, they are all linked to the root dummy through other parts or dummies.

Today, we are about to do the following test:

We will keep only the parts tagged for animation and get rid of all the other parts in the interior model. We will rearrange the hierarchy if necessary, so ultimately all the parts are linked to the root dummy. We will check for geometry issues. We are doing this test because we want to make sure it is not some other parts in the model that are causing the issue, even though without animations, the geometry of the model is perfectly normal.

We'll keep you posted on our results.

Many thanks again for your help.

[xtremepro67]

One last and very personal comment, coming from the point of view of a developer:

The way the "optimize part" stuff currently works doesn't help us at all, even though the intent (to improve performance in the sim) is good. Why? Because we have no control over the optimization process. The software seems to decide randomly for itself which parts should be "optimized" and this leads to bad choices with the kind of results we are getting: unrelated parts that are simply crushed and destroyed by the "optimization" process, flying geometric figures in the VC, missing parts, which also destroy our model and render it unusable (without modifying the sim's .cfg file).

Why should the software decide to "optimize" a door, yoke or pedal by destroying its geometry when an unrelated extra switch is tagged for animation? By "unrelated", we mean not sharing the same material/texture/hierarchy node, etc. So far, we couldn't find the logic behind it or we would have made the necessary changes to our models so the parts would be spared during optimization.

What can be done to the model so the this doesn't occur? We've been addressing this issue since early February and unfortunately, we still don't have a practical and definite answer/solution that works at the model level (not by changing a line in the sim's .cfg file). Adding bones to our animations is not a solution: we have over 300 animations in some of our models.

Exported models should not appear distorted when loaded in the sim (like they never were before), whatever parts are "optimized" or not. And this on all platforms (including P3Dv1/FSX).

It must be noted that without the extra animation tags, the geometry is perfectly normal in the sim. So we don't think it's a geometry issue at the model level. Maybe we did something wrong or there is something we don't yet understand, but so far, after dozens of tests, we can't find it.

Still hoping for a miracle... ;-)

P.S.: Our last test (isolating only the parts that are animated to make sure other parts were not creating the issue) was inconclusive.

[Beau Hollis]

I can understand your frustration. The goal of the optimization code is to speed up model rendering while having no impact on how the model displays. That isn't happening in the case of your model, so there is almost certainly a bug in the optimization routine. We would certainly like to fix it in a future release, but we've investigated as far as we can without having a method to reproduce the issue. If you can post a test model that reproduces the issue, we may be able to look into it a bit further. Otherwise, what we may do in a future release, is provide a way to flag a model to be excluded from the optimization routine, so that the config change is not required.

We unfortunately cannot do anything about this issue in FSX or P3Dv1, or P3Dv2. To my knowledge, you are the first developer to report this issue, so it's possible that developers of other complex add-on models have found ways to work around the issue.

[JB3DG]

In some cases they replace animated rotating drum indicators with a moving texture in a gauge. Or use visibility tags for switch positions and have multiple clones of the same switch, one for each position.

[xtremepro67]

There are always ways to work around issues, as long as we know them in advance so we can plan some alternatives (doing things differently when building the 3D model). What's frustrating is being caught off guard after months of development with something we we never expected, that we never encountered before and for which there is no documentation and little support.

Many developers use 2D gauges in virtual cockpits, which substantially reduces the number of 3D animations. This is probably why few of them encountered the issue. Using visibility tags for switches is a good suggestion, but between us, this is not how things should normally be.

We've developed models with large numbers of animations in the past and we never had this issue with the old XtoMDL for FSX. Unfortunately, we can no longer use the old XtoMDL due to the increased number of polygons in our current model and because we need to produce a native P3Dv3 addon as well.

Please refer to this post, maybe we're not the first ones to report this issue, but it seems that in this case, there was no follow up since 2013, until we appended our post back in February:

http://www.prepar3d.com/forum/viewtopic ... 309&t=9628

[xtremepro67]

Unfortunately, exceeding a certain number of visibility tags has the same effect as too many animation tags (P3Dv3 with OPTIMIZE_PARTS=1).

1. Fist we removed the animation tags from all switches in our VC model. No more geometry issue.
2. Then we duplicated every switch, one copy for the OFF position, the other for the ON position. Still no geometry issue.
3. We tagged about 10 switches with both a mouse rectangle and a visibility tag. Geometry issues started to appear again.
4. We gradually removed the visibility tag from a few switches but kept the mouse rectangle. The geometry issues disappeared one by one as we gradually removed the visibility tags. Mouse rectangles seem to have no negative effect on geometry.

Conclusion: too many visibility tags have the same effect on the optimization process as too many animation tags (they both affect geometry after a limit is reached).

We also exported for P3Dv1 and FSX. We don't know if these platforms also "optimize" parts but we are getting the same geometry issue on both platforms. OPTIMIZE_PARTS=0 has no effect.

Depressing...

Is it possible that in our case the issue might be related to exporting/compiling the model and not to the optimization process at the sim level? The reason I'm asking is that the same issue occurs in P3Dv3, P3Dv1 and FSX which are 3 different platforms. Unless they "optimize" parts the same way, we found it strange that exactly the same issue occurs on all 3 platforms.

(We currently use the P3Dv3 plugin in 3ds Max 2015 and we produce the model with both the XtoMDL for P3Dv3 and P3Dv1.)

[xtremepro67]

CONCLUSION to this saga

To all fellow developers:

We were finally able to solve our problem by ourselves by going around the issue. Please note that the issue we reported 6 months ago is not resolved yet, but at last, LMT seems to have acknowledged the problem and admits that "there is almost certainly a bug in the optimization routine. We would certainly like to fix it in a future release... We unfortunately cannot do anything about this issue in FSX or P3Dv1, or P3Dv2" (see post above).

So all our tests seem to demonstrate (from the beginning) that there is indeed a limit to the number of animation tags and visibility tags that you can have in a model before you start having geometry issues with a model that is otherwise perfectly normal when loaded in the sim.

So, when building your models, especially your virtual cockpits where you usually have more animations (like switches and needles) and visibility tags (like lights and annunciators), try to keep them to a minimum.

In our case, since we could not have substantially reduced the number of animations without depreciating the model, we optimized the visibility tags by removing the unnecessary ones and combining them as much as possible. For example, if you have 20 lamp posts on your instrument panel that all come ON and OFF at the same time, instead of tagging them individually, you can combine them into one single part and only use one visibility tag. This will significantly reduce the number of visibility tags in your model and, logically, will also improve performance by reducing the number of draw calls.

Of course, using 2D gauges in your VC instead of fully modeled instruments/lights in 3D would also reduce the number of animations in your model. However, in our case, we rarely use 2D gauges in our VCs for a number of reasons, so there was a limit to the number of animations that we could have cut. Using visibility tags to simulate the two states of a switch, for example, is not a real solution because too many visibility tags also affect geometry. Additionally, a 2-state "animation" is not realistic in some cases.

At this time, we are unable to determine the exact number of animation/visibility tags that should not be exceeded or if their numbers are combined or not (in which case, this would offer more flexibility because the number in one category of tags will not affect the number in the other category). All we can say is that after a certain limit is reached, you get into trouble.

The only real solution we found at this time: optimize your model yourself by reducing the number of animation/visibility tags (if not, the sim will take care of it and destroy your geometry).

Hope all this helps.