Anim8or Community

Please login or register.

Login with username, password and session length
Advanced search  

News:

An update to Anim8or, v1.00b, is available with a few bug fixes. Get your copy HERE. See the "ReadMe" file for details.

Pages: 1 ... 16 17 [18] 19 20

Author Topic: Feature Request Thread  (Read 65282 times)

Raxx

  • Administrator
  • Hero Member
  • *****
  • Posts: 1448
    • View Profile
Re: Feature Request Thread
« Reply #255 on: March 17, 2016, 08:19:07 pm »

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.
« Last Edit: March 17, 2016, 08:28:36 pm by Raxx »
Logged

nemyax

  • Full Member
  • ***
  • Posts: 214
    • View Profile
Re: Feature Request Thread
« Reply #256 on: March 23, 2016, 09:46:55 am »

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 points
This 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 command
These 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.
Logged

Raxx

  • Administrator
  • Hero Member
  • *****
  • Posts: 1448
    • View Profile
Re: Feature Request Thread
« Reply #257 on: March 23, 2016, 04:26:16 pm »

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.
« Last Edit: March 24, 2016, 12:12:38 am by Raxx »
Logged

slex

  • Jr. Member
  • **
  • Posts: 87
  • 3D-TV
    • View Profile
Re: Feature Request Thread
« Reply #258 on: March 23, 2016, 11:06:22 pm »

'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'
« Last Edit: April 02, 2016, 05:27:03 pm by slex »
Logged

Raxx

  • Administrator
  • Hero Member
  • *****
  • Posts: 1448
    • View Profile
Re: Feature Request Thread
« Reply #259 on: March 24, 2016, 12:13:31 am »

'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

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.
Logged

slex

  • Jr. Member
  • **
  • Posts: 87
  • 3D-TV
    • View Profile
Re: Feature Request Thread
« Reply #260 on: March 24, 2016, 02:22:22 am »

Those three colored rings around selected bones(trackball) rotate bones only toward user.
 
 -With only mouse buttons while without trackball I always know where the bone will go regardless of the view point and move it back after a while- because it rotates them toward workspace
 -Trackball rotations of the bones are unpredictable and require a lot of 'Arc rotate' to fit object to the sight, if I move some bone and rotate the sight few times there is no way to get back the bone on the previous place without using 'undo'.
 
-Simultaneous use of standalone LMB/MMB/RMB and trackball is impossible , so I always use 'select all' and 'toggle trackball visibility' to hide all the rings(thanks kreator), they are making trouble- it would be much better if let's say on the right side of the screen would pop-up the trackball for the selected bone(away from the object).
Logged

Raxx

  • Administrator
  • Hero Member
  • *****
  • Posts: 1448
    • View Profile
Re: Feature Request Thread
« Reply #261 on: March 24, 2016, 03:10:06 am »

Hit 'o' for object space/coordinates.

Interestingly, object space doesn't match up directly with the bone axes. However I prefer the trackball object space version since it's not as confusing, which reinforces my opinion that the LMB/MMB/RMB X/Y/Z deal isn't necessary anymore.
Logged

slex

  • Jr. Member
  • **
  • Posts: 87
  • 3D-TV
    • View Profile
Re: Feature Request Thread
« Reply #262 on: March 24, 2016, 03:58:58 am »

Hit 'o' for object space/coordinates.

 :) didn't notice that before, thanks 4 great advice :-X.

Logged

Steve

  • Administrator
  • Hero Member
  • *****
  • Posts: 1532
    • View Profile
Re: Feature Request Thread
« Reply #263 on: March 24, 2016, 05:06:07 am »

Object space is the coordinate system of the bone *after* the X, Z and Y rotations have been applied. The coordinate system of the trackball always has it's X, Y and Z axes at right angles but the bone axes are applied one after another and therefore don't have this property. I.E. the individual X, Y, Z bone axes can show Gimbal Lock but the track ball can't.
Logged

johnar

  • Sr. Member
  • ****
  • Posts: 814
  • Make it, Move it--Give it Life
    • View Profile
    • youtube vids
Re: Feature Request Thread
« Reply #264 on: March 27, 2016, 01:00:50 pm »

I've been playing with character animation and it's certainly improved heaps. The trackball is awesome and being able to "key all" and "key selected" bones in scene mode is a real game changer.
 One thing i could think to request at this stage would be to 'show bones only in selected views'(when the bone rotate is selected). I imagine this would work similar to when you choose wireframe view in one of multiple views, and the wireframe shows only in that view.
 The advantage would be that you could animate bones in one, (or more), views, and still have a clean image in the camera view.  ;)
Logged
%

slex

  • Jr. Member
  • **
  • Posts: 87
  • 3D-TV
    • View Profile
Re: Feature Request Thread
« Reply #265 on: March 31, 2016, 05:38:36 am »

It would be great if 'bone influences' in figure mode could be shown/hidden according to selection of the mouse clicks on the bone. It is very crowded now when all the orange and yellow orbs are shown at the same time, and it's hard to adjust the skinning because of that.

Adding some hot button to slow down the mouse movements while it's pressed?

Logged

Water Music

  • Jr. Member
  • **
  • Posts: 86
    • View Profile
Re: Feature Request Thread
« Reply #266 on: March 31, 2016, 06:41:45 pm »

Slex: I have a mouse with a slow-down button at the thumb, which is incredibly useful for this type of work.
Logged

johnar

  • Sr. Member
  • ****
  • Posts: 814
  • Make it, Move it--Give it Life
    • View Profile
    • youtube vids
Re: Feature Request Thread
« Reply #267 on: April 02, 2016, 05:32:46 am »

Weight painting and not enough colours. This has been mentioned a few times and while rigging a fishy-thing today i realised it could be a fairly simple fix.
 When you first add an object to a multi-boned figure, the object will normally first take the color of the main parent bone, (when 1st selecting weight painting), so trouble starts when bones further along the chain have the same color already, making it impossible to see the painting happening on that part of the object.
 So, if the first/parent bone only showed a unique/different color than the rest, then that could solve the problem 99% of the time?
 Hope i explained that so it makes sense.
« Last Edit: April 02, 2016, 05:34:19 am by johnar »
Logged
%

slex

  • Jr. Member
  • **
  • Posts: 87
  • 3D-TV
    • View Profile
Re: Feature Request Thread
« Reply #268 on: April 02, 2016, 05:28:39 pm »

jonhar, +1 from me  :)
Logged

nemyax

  • Full Member
  • ***
  • Posts: 214
    • View Profile
Re: Feature Request Thread
« Reply #269 on: April 27, 2016, 10:53:56 am »

Obviously, most of these requests are things found in regular programming languages. If instead an API/dll extension system was being worked on, I really couldn't care less about these requests and just wait for that to save myself all the headache :P
Steve, is there a chance Anim8or might get an SDK?
Logged
Pages: 1 ... 16 17 [18] 19 20