API Question Retain animation with ClearMeshes

[indy91]

I am running into a problem with trying to animate the rendezvous radar (as an example, it happens with other animations) for the NASSP Lunar Module. It works pretty well, except it snaps into a weird position at staging.

When the descent stage is dropped a function calls ClearMeshes(true), using true there should retain the animations associated with the meshes. The meshes are then loaded in the same order again, so that shouldn't be the cause of the issue.

The problem seems to happen with animation components that are added as a child of others. Here some of the code for the RR:

ach_RadarPitch = lem->AddAnimationComponent(anim_RRPitch, 0.0f, 1.0f, mgt_Radar_pivot);
	ach_RadarYaw = lem->AddAnimationComponent(anim_RRYaw, 0.0f, 1.0f, mgt_Radar_Antenna, ach_RadarPitch);

where, I think, only the animation of ach_RadarYaw has the issue happening.

Interestingly when the RR is in the same state as the mesh by default (so animation states 0.0 and 0.0) then the RR looks the same after staging. It is almost as if, when the meshes are loaded again, Orbiter doesn't keep track of where the animation state currently is or it thinks it's in the same state as before and applies the current animation state twice, so adding a wrong offset. Does that make sense? Could it also be a pre step vs. post step issue? The ClearMeshes gets call in pre step. I am not sure how we can work around this or if it is an Orbiter bug or so. Any help would be appreciated.

 

[4throck]

I guess Clearmeshes only keeps animation definitions, not status.
So perhaps you can handle status yourself and apply them when needed?

 

[indy91]

Well, it works like this. The animation state goes from 0 to 1. Let's say the animation is in the state 0.4 when the meshes are cleared with the animations being retained. It kind of keeps the 0.4 state as a new default mesh state, so if you use SetAnimation(0.4), as you would before, then the visual state of the mesh is actually 0.4 + 0.4 = 0.8 intead of 0.4. That's why there is no problem when the mesh was in its 0 state at ClearMeshes, because 0 + 0 = 0. Reloading Orbiter of course fixes the issue, but something goes wrong at ClearMeshes(true). And I think this only applies to an animation component that is a child of another animation component.

 

[fred18]

I think that the small bug is that when you define a new animation you define also its initial state but in this case the redefinition of the animation gets the current status as initial so its changed. What about setting all the animations to state 0 just before clearing the meshes? you can store the animation state in your variable, set the animation to 0, clear the meshes and then set the animation to the value stored.

 

[indy91]

It does not work doing that in the same timestep as the ClearMeshes. Doing it one timestep early (or maybe pre and post step) might work, but then the whole function that uses ClearMeshes needs to be delayed in some way, which is not really feasible.

What we could of course do is not retain the animations and create them again when the meshes get cleared. Alternatively we could just delete the meshes and animations not used anymore, so mostly the descent stage mesh. I'll look into it.

EDIT: jalexb88 solved the issue by reducing the number of separate meshes we use for the LM and just deleting the ones not needed anymore. So ClearMeshes isn't used and the animation issues can't happen.

 

[4throck]

You can handle execute once functions by adding a bool variable.
When you jettison the stage, you set the variable to true, and then set it back to false once your function has executed.
Of course, the function only runs if the variable is true.
That will give you a delay of one step.