Since it was brought to my attention in another post, I thought I'd bring up a discussion about scripting in the scene editor. More specifically, controller scripting. Currently it's entirely too restricted. Aside from making basic turntable animations, there's not much incentive to use controller scripts in the scene editor simply because it's mostly crippled. I can't count the number of hours I wasted trying to implement physics and IK and animated textures, only to fail on the first two multiple times and only succeed on getting animated textures done with limited success.
Controllers"Controllers" should be changed to a different name, in the context of this post. Instead, it'd be better to call them "properties". Properties that can be animated. A script can have properties but properties can't have scripts. These properties can be built-in, like position or orientation, or they can be custom-made.
Controller ScriptingAny element in the scene should be able to have a script attached to it. Do away with separate controller scripts for position, orientation, scale, etc. Instead, make it so that one or more "script" elements can be added to any element (aside from other scripts) in the scene. Double clicking this script element on the timetrack or graph editor pops up a dialog box with the script in a textarea and on/off keyable options.
For example. Object01 has a script attached to it. That script can read and/or edit its parent (Object01) and its parent's position, orientation, scale, visibility, etc. It can also look up and edit any other element's properties. It can look up its own self as well.
I recommend creating an "element" Anim8or data type similar to the object editor's "shape" data type, in that it can access all internal properties and lookup custom properties for any element in the scene.
Hierarchy, order of operationsThis is a big one. A script attached to an element must be able to read and write the data for any and all scene elements, including children, parents, and siblings. Do away with babysitting using strict circular dependency rules. It just hampers the user. Instead use an order of operations and otherwise catch/halt infinite loops (with an option to set a directive to not catch/halt loops for that script).
Order of operations is a set of rules the scene follows regarding animation. With this, there becomes no reason to worry about circular dependency.
There are two types of animation. Keyed animation and scripted. All scripts get executed first in a specific hierarchy. Then the keyed animation gets run on top of that (additive).
The hierarchy for script execution is simple. It executes scripts in order of highest in the parent/child relationship to lowest (depth-first search with optional customization on which child gets hit first, basically). So in the following image, let's assume these are all scripts below the scene element.
Horizontally, in which order? If not set then it'll run in the order that Anim8or reads them. Otherwise, if a directive is set (like #index(1);), it'll run it in the order that's set in the scripts. Now let's assume "a" is set to run first. "a" might read and modify properties of an element. "b" might read and modify the same properties as well. So "a" reads and modifies them first. Then "b" reads the properties (that have been changed by "a") and modifies it further.
What about "d" and "e"? If they also change the same properties, then it'd be done in this order: "a", "d", "e", "b". In fact, the order of this entire operation would be "a", "d", "e", "b", "f", "g", "c", "m", "n".
Previous-frame data (or, passing variables between frames)There should be ways to lookup previous frames' data. The current problem with doing anything physics-like is that there's no way to change, say, acceleration without using tricks. I can give an initial trajectory with direction and acceleration, but beyond a nice looking arc there's really not much else to do. I believe
ENSONIQ5 could probably give a nice long rant about this issue ;)
Bones/FiguresSomewhat related. Currently, a figure can't be expanded in the timetrack to show all its bones in its hierarchy. All controllers/parameters are listed on one level. Firstly, this needs to be changed so that it properly shows its relations in the timetrack as if it were a stack of elements in the scene editor. Secondly, scripts and elements should be able to be attached to bones and/or objects that are attached to bones. Basically, an individual bone should be treated like an element.
An element should be expandable with visual differentiation between its properties (position, orientation, scale, etc) and its child elements. Italics or something for the properties. When keyframing a bone, it should have the same "position", "orientation", "scale" point3 keys that elements have. No more flat-listing a long series of "boneXX-X", "boneXX-Y", "boneXX-Z" immediately under the figure. A simple "orientation" parameter under each bone would be much, much better. And yes, scale should be a point3 value so that non-uniform scale becomes possible.
I already mentioned in other posts how important translation and scaling of bones is in animation, so I won't go there.
