General Category > Anim8or v0.98 Discussion Forum

Feature Request Thread

<< < (52/59) > >>

Raxx:
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 Scripting
Any 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 operations
This 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/Figures
Somewhat 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.

nemyax:
Numeric input for transforms and transform presets
At this time Anim8or has the following numeric input and preset capabilities for transforms in the object editor:

* An Edit | Rotate menu that works only for objects
* An Edit | Scale menu that works only for objects
* An Edit | Move Points command that works only for pointsThis looks like an oversight. How about a context-sensitive set of transform commands that would work on whatever is currently selected? Like this:

* Edit | Rotate menu
* Edit | Scale menu
* Edit | Move commandThese should work for both objects and components (any components), depending on what is currently selected.
Where a dialog box is invoked (Edit | Rotate | Custom, Edit | Scale | Custom and Edit | Move), it should include two radio buttons: World space and Current space. The Current space option should apply the transform in the space that is currently selected in the toolbar. Changes to the numeric values should be previewed in real time, as they are in the primitive properties dialog boxes.
And of course scaling by 0 in any axis should not be disallowed. It's a common way to flatten things.

Raxx:
A few more requests to stack on. Some of these have probably already been requested before:

Slide Edges and Multiple Elements
Let the slide tool slide edges. Basically clicking and dragging on an edge slides the edge in the direction of movement along its adjacent edges. Clicking and dragging on multiple connected edges slides the entire set. Clicking and dragging on multiple points does a best guess sliding action.

Edge Loop Manipulation
Let holding shift automatically highlight edge loops (the same way they're detected using q). This feature can be put in nearly all the point edit tools except the topo tool unless the topo tool shift/dissolve operation is moved to a different button.

Face Loop Manipulation
If highlighting faces, basically do the same as above except with faces. How to do this: If shift is pressed, it'll highlight the faces between the quad ring (same detection as Q) of the closest edge of that face. The below video shows what I mean:


Pretend that the yellow selected faces are the areas that get highlighted when shift is held down.

Axis-Restricted Bone Creation
Currently disabling axes have no effect on bone creation. If I wanted to create a bone sticking straight up, the only choice I have is to enable grid snap.

Object Space
Allow object space manipulations to apply to bones. This way (as an example of use), if the Y axis is solely enabled and it's set to local, then creating a bone will create it along the Y axis of and Y-rotated to the parent bone, rather than the global Y axis. I know this can be done with fast select disabled, but it's a bit of an odd thing having to disable it to get that behavior. In fact, it seems if fast select is disabled while trying to create bones, it doesn't always work.

Screen-space rotate bones
In sequence/scene editors, I feel that when you have Edit Bones active and left-click drag on a bone (in fast select or when dragging outside the circle), it should rotate it along the screen space instead of the X axis. In other words, ditch the LMB/MMB/RMB X/Y/Z relationship with manipulation since it's inherently less intuitive than rotating in screen space. I say this because there are now rotation widgets so that when in Object Space you can rotate according to the old relationship anyway.

slex:
'Loop selection of edges/faces with shift or similar' would be great.+1

'Screen-space rotate bones' can already be done with trackball, applying that also to the mouse buttons would badly reduce the mobility of the bones.-1 updated after advice from raxx +1 , now I had to update again- when bones of the hand are rotated it is much easier to use LMB/MMB/RMB than selecting each bone and moving it with the orb, it is better to leave it the way it works now.

'Axis-Restricted Bone Creation' sounds good.+1

I would add a request for 'possibility of linking the bone/s rotation and position with the target in scene'

Raxx:

--- Quote from: slex on March 23, 2016, 07:06:22 pm ---'Screen-space rotate bones' can already be done with trackball, applying that also to the mouse buttons would badly reduce the mobility of the bones.-1

--- End quote ---

I'm not entirely sure what you mean. The only way that local manipulation (the way it currently is) trumps the far more intuitive screen space manipulation is when doing purely mechanical animations that need precision along a single axis, or when doing minor adjustments like rotating around the bone's Y axis. Even then, it's easier to use the widget than to use the mouse buttons, so basically there's no point in having the LMB/MMB/RMB X/Y/Z mechanic.

Note: I updated my previous post to further detail what I meant.

Navigation

[0] Message Index

[#] Next page

[*] Previous page