X-Plane 9 will feature key-framed animation for the rotation and translation animations (but not the show-hide animations). Basically:
- You can have more than two key frames.
- Interpolation between them is linear.
- Extrapolation off the ends is linear (use two equal-value key frames to clamp).
Key frames will be available for all OBJs: scenery, cockpit and aircraft parts. I will try to post a spec soon – the implementation is very similar to the RFC I posted a while ago.
(If you read the .tcl code in the AC3D plugin, you may have guessed that this was coming.)
Trigger
Now I know somebody is going to ask me: “will this allow me to make an animation X start when event Y happens in the sim?” The answer is: no! Key frames allow you to map the relationship between an input dataref and your geometry in any way you want. But if the input dataref is not changing, the output position cannot change either.
Example: you can use key frames to make complex things happen as the gear deploys. Gear deployment is a ratio that starts at 0 and slowly changes to 1 as the gear deploys (over the cycle time as set in PlaneMaker). So you can use this to make the wheels move forward first, then down.
But you cannot use key frames in the cockpit to make the gear handle move slowly. The gear handle dataref is really a switch – it instantly changes from 0 to 1. If you set up a nice key framed animation, we will instantly jump from the animation position at 0 to the animation position at 1.
In other words, whether or not you have key frames, the timing of an animation comes from datarefs, and datarefs alone. I am not planning any extensions to the OBJ system any time soon that will let you trigger animations from events. In other words, you can’t synthesize timed sequences from an OBJ. (The purpose of OBJs is to visualize things, not model things.)
If you want to create timing data, write a plugin. If you don’t know how to code, I have seen at least one plugin that lets authors “invent” simple datarefs using a text file.
No Spare Datarefs
And while I’m going off on a tangent about authoring and datarefs, we will not be adding any “spare” datarefs. Again, datarefs should be made with plugins, and non-programmers should use a plugin that creates datarefs from text files. We will not be creating any “unused” datarefs in the sim.
Why not? Think of the integration problems. Even if we make 100, what happens if Joe uses “spare dataref 93” in the cockpit of his great 747 and Fred uses “spare dataref 93” for the windmills turning in his scenery pack? Splat.
The naming convention of datarefs start with the company or author who created it – or “sim” for X-Plane itself. This is intentional – it assures that two independent authors won’t use the same dataref name and create conflicts between add-ons!
Is the direction of the wind able to act as a datarefs ?
Changing the direction of windmill automaticaly could be nice
Direction of the wind is already a dataref! And all datarefs can act on key frames. This is how the windsocks work in 860!
However, you can’t DIRECTLY control the direction of windmilling with the wind, because something has to make the object spin. So what you’d really have to do is…
Have a outer animation that rotates the object 180 degrees when the wind changes direction (basically it’d be like taking the prop off the plane, flipping it, and putting it back on).
THEN have the rotation animation that makes the prop move. (But you can’t easily scale this to wind speed – you need to use a timer.)
THEN flip the object over again (inside the rotation) using wind direction.
In other words, what we’ve done is flip the object twice (so no visual changes happens) but flip the rotation once (so CW becomes CCW).
But…this is an ugly solution and probably not what you want…it won’t create natural windmilling the way x-plane does when it calculates the interaction of the prop with the wind, taking the heading of the prop vs. velocity vector of the wind into consideration.
Animation is not a substitute for simulation!