FSX Animation "overshooting" (even with linear controller) if "stationary" phase is included

[theFiddler]

Greetings and a Happy New Year to All!

First problem of the year: I am stumped by a very basic animation for FSX ("Gold" variant).
It's a test case for a scenery object (not aircraft) animation, supposed to simulate a lift moving up and down a tower (on the outside).

So in GMax I have a static cylinder (the "tower") and an animated box (the "cabin") running up and down it.
Position animation along the z-axis only, no rotation or scaling involved.

The cycle goes like this (total length of animation: 100 frames, just for testing)

frame
#0 - #20: stationary at ground position
#21 - #50: move to top
#51 - #70: stationary at top position
#71 - #100: move to ground

...rinse and repeat.

Looks OK in the TrackView function curve.
Works correctly in both GMax and MCX.

The problem: In FSX the cabin will "overshoot" instead of stopping at the top/ground.
It will slow down but rise above the top of the tower roof, or move into the ground, resp. There is no truly stationary phase, the overshooting "eats up" the planned pause time.

Now, I know this overshooting will happen if the Position controller is "Bézier" (the GMax default).
But I have changed all three controllers to linear (even Rotation and Scale which are not used at all).
I have also added extra keyframes, shortly before top and ground (#48 and #98) and halfway through the movement phases (#37 and #88).
All to no avail.

After much animation testing (and animated language, too) I eventually discovered that removing the two stationary phases seems to be the only trick that helps:
Even all those extra keyframes are then no longer needed.
The cabin will now run to the correct top and ground positions, without overshooting, but will then of course immediately continue with reversed direction, i.e. no pause any more.

However, those pauses are needed to give the PAX a chance to step in or out!

Hence my questions:

• Is this a known problem?
• If so, what is a solution?
• Or am I overlooking something trivial?

Thanks in advance for all hints!

Cheers,
Martin

 

[=rk=]

Martin, you want to be aware that an animation is "rendered," the static key frames are interpreted by whichever 3d software you are using, Gmax, MCX, or FSX and the render engines are not the same. Bear in mind now, the operative term is interpreted, it's extremely likely you just have to make your instructions clearer. I ran into this exact same problem animating a monorail to travel between two building models.

Unfortunately, the solution will probably be discovered through trial and error, but I think your initial mistake might have been neglecting not include a key frame to designate the end of the pause. Also, your description of frame sequences is not specific, you do not note the actual key frames.

#0 - #20: stationary at ground position
#21 - #50: move to top
#51 - #70: stationary at top position
#71 - #100: move to ground

Could more clearly be expressed as:

#1 = key frame 00, ( x,y,z) position 0,0,0
#2 = key frame 20, ( x,y,z) position 0,0,0
#3 = key frame 21, ( x,y,z) position 0,0,0
#4 = key frame 50, ( x,y,z) position 0,10,0
#5 = key frame 51, ( x,y,z) position 0,10,0
#6 = key frame 70, ( x,y,z) position 0,10,0
#7 = key frame 71, ( x,y,z) position 0,10,0
#8 = key frame 100, ( x,y,z) position 0,0,0

You can see that key frames #3 and #6 define the specific end of a stationary phase and it's not clear that they are included. If they are, then another transitional definition is required. You can key each frame, there is no limit to the number of key frames, so you can specify the animation transition for each frame.

 

[theFiddler]

Could more clearly be expressed as:

#1 = key frame 00, ( x,y,z) position 0,0,0
#2 = key frame 20, ( x,y,z) position 0,0,0
#3 = key frame 21, ( x,y,z) position 0,0,0
#4 = key frame 50, ( x,y,z) position 0,10,0
#5 = key frame 51, ( x,y,z) position 0,10,0
#6 = key frame 70, ( x,y,z) position 0,10,0
#7 = key frame 71, ( x,y,z) position 0,10,0
#8 = key frame 100, ( x,y,z) position 0,0,0

Hello Rick,

many thanks for your very prompt reply! An auspicious start into the new year, all the more so as your advice did (almost) solve my problem
I was indeed missing the keyframes #3, #5, and #7 in your list above. I have still not quite wrapped my head about why these "twin keyframes" are necessary, i.e. why one keyframe is not enough to define the end of the stationary period. Perhaps it is so that one and the same keyframe cannot be "incoming" (end of stationary) and "outgoing" (start of movement) at the same time, in a manner of speaking. But be that as it may, they do certainly work.

Moreover, there is still a residual problemlet: In FSX, the cabin does now stop at the prescribed positions as intended, and it does observe the prescribed stationary phase. But immediately before arrival at, and again directly after departure from, the correct "parking"position (top or bottom), it still does a very fast hop to what was the "overshoot" position before, and then back again to the correct position.
It goes so quickly that it appears as a flicker, and can be properly seen only at sim speed 1/4.
Anyhow, I suppose this is a case for further "trial and error" fine-tuning, but am now definitely on the right track.

Thanks again!

Cheers,
Martin