General Category > Anim8or v0.98 Discussion Forum

Feature Request Thread

<< < (3/58) > >>

Tier 2 - Object Editor - ability to Hide points in edit mode

Ok, I added all of your suggestions the best I could. Water Music, I wasn't sure about your request for passively controlled bones and non-linear speed options (I could make a guess but I won't). Please explain a little more about those features.

I'm +1'ing the ASL modularity request, and I added the following ASL-related requests that I had mentioned in the past:

ASL - SetAttribute: Set and edit attributes using ASL
ASL - Shape.Get/SetParameterValue - Accessible by all script types (including other parametric mesh scripts).
ASL - Face.SetMaterial - For parametric mesh plugins. A parametric mesh can only hold one material via Shape.SetMaterial. This would allow you to apply multiple materials to a shape.
ASL - Shape update mechanism: A way to keep shapes "live" if needed, or a way to update the shape via another script.
ASL - Texture Weights - They aren't accessible via ASL
ASL - Quaternion arithmetic: addition, subtraction, multiplication, division
ASL - Point3 multiplication/division
ASL - QuaterniontoRPY: Similar to RPYtoQuaternion, except the other way around
ASL - Quaternion.slerp(q1, q2, t): slerps between the two quaterinions q1 and q2 by float t. t is between 0 and 1.
ASL - Quaternion.lerp(q1, q2, t), Quaternion.squad(q1, q2, q3, q4, t): same as Quaternion.slerp except different effect
ASL - Vector and quaternion comparison operators: Something like if($vector != (0,0,0))

Water Music:
RAXX: By "non-linear speed options" I was referring to the fact that a bone in a sequence always moves at a steady rate between keyframes: (total angle/#frames) per frame.  It would be nice to specify that the motion should start slow and end fast (like when throwing a punch), start fast and end slow (like reacting to the above mentioned punch), or start and end slow but moving faster in the middle (like moving to pick up something delicate).  The only way to do these now is to add a whole bunch of keyframes, and try to tweak them all manually so that they flow naturally. ***edit since this is in development already, let's just ignore this one.

Warning:  long geek rant
As for "passively-controlled bones," I basically mean ragdoll physics.  Moving an arm is something we do actively, but long hair moves in predefined ways according to outside influences.  I'll try to quickly lay those out here, first to illustrate what I'm talking about, second to make it easier for Steve to implement, and lastly if there are any amateur game makers out there it is pretty simple to implement these for decent looking results.

Note:  3d physics are not real physics, so this is meant as an approximation specifically for 3d animation.  Some corners are cut, for ease of implementation.  As animation operates in step functions, better results are obtained the more "frames" there are.

Right, so a bone in modelling is essentially a vector and I can summarize what I am going to say by saying that we will derive the bones new orientation for each frame by adding all of the vector influences on that bone that we can think of.  Definition of terms: S1 is the new xyz position of the bones root for the new frame; E1 is the end position for the same bone, same frame which we are trying to solve; S0 & E0 are the start and end for the previous frame; S-1 & E-1 are for the frame before that.

Inertial vector: we start with the vector S1 to E0, which represents the mass "resisting" new motion
Momentum vector: we add the vector E-1 to E0 to continue any existing motion
Gravity vector: we add a user-defined vector straight up or down the y-axis (depending on whether it is to rise or sink and to what rate).  This will need to be uniquely defined for each bone.
Wind vector: Another user-defined variable indicates how strongly wind affects the bone.  The wind vector is that variable multiplied by the wind vector at the bone's location (more on that in a minute)
Spring vector: This is the tricky one and can be done in a couple of ways.  The easiest, but least correct, way is to add a vector from the bones current end position to what would be the bone's default rest position, multiplied by another user-defined variable representing the strength of the spring.  A more accurate approach looks at the angle difference between the bones current position and its default rest position, and accelerates the bone towards that rest position consistent with the formula (Moment of Inertia)*(angular acceleration)=-((spring coefficient)*(change in angle)-(drag)).  I'll pull resistance out for now to simplify it to: (user-defined variable)*(-change in angle).  This gives a theoretical angle correction, and our spring vector becomes the vector between E1 before the spring correction to E1 after the spring correction.
Resistance vector:  This will take another user-defined variable μ for the resistance.  The resistance vector equals E1 - μ(E1 - E0)
Bounceback vector: If E1 is outside its limits on its x, y, or z axis, or with collision detection if it intersects another object, you could have the bone bounce back along that axis by a fraction of the amount that it would otherwise be over.

Add them all up, correct the bone length back to normal and watch it sort itself out.

This brings us to the many ways to set up wind/tide.  The easiest is simply to set a wind vector for the entire scene.  The next level of complexity allows the user to alter the strength and direction of that vector using keyframes.  The next level allows the user to create wind splines through a scene, along which pulses of wind travel affecting bones proportionally based on proximity.  The last level would create tweakable splines around objects automatically.  However it is used, each time a wind vector is called up it should be randomized slightly for effect.  And if you are really a glutton for punishment, you could affect an object's wind drag according to how much of its profile is showing, how perpendicular the wind vector is to the polygon normals, etc.

Anyway, thus ends the long rant.  I place no demands on this being implemented, I just hope its helpful.  And if the mods feel it is too long/out of place then feel free to delete this post.  Thanks.

Anim8or already has a form of non-linear speed, with its implementation of the Graph Editor (see attachment). It's not available in the sequence editor, however. Just the scene editor.

I should mention that Steve seems to intend on implementing exactly what you want, for a future release:

hi Raxx and every one, it is great that anim8or if finaly being updated.
though we already have few of it's capability from our coder by ASL, i have few wish and thought for it :

* the spin tool is good but it will be better if we can alter/redefine polygon inner triangle formation by vertex.
* undo option for ASL command script at least a back-up of last working shape/Mesh will be worthy.
* a simple texture mapper (simple window with image in back and selected face can be mapped there).
* position, rotation and scale helper will be great and worthy.
* non uniform scale and rotate face tool worked badly before(some time or mostly).
* group of vertex rotated by its average center will be worthy, moving face by vertex as well.
* selection group set (V/E/F) can be more helpful in modeling.
* user input for ASL at least yes/no, value input, slider value input will be great, accessing user interface data as well.

* anim8or was mostly compatible and portable before this release :
  i can run v97d in win98, 2000, xp, windows-live, 2003, from card/flash drive using 200mb xp installation in it.
  the dll dependency made v97e non-portable/compatible, as it require to install it before running. as far as i know simply putting the dll on the same folder usualy don't work.
  i have Celleron D processor, 256mb DDR1 RAM, VIA/S3G UniChrome Pro IGP Graphics support, privious worked well with it. i tested v97d in Pentium 3, 4, with older system as well, it also work using wine in Linux.

i am too poor to update my PC for win7/win8, sad to know anim8or is being updated for them, being less portable/compatible :'( :'( :'( :'( :'( :'( :'( :'( :'( :'( :'( :'( :'( :'( :'( :'( :'(


[0] Message Index

[#] Next page

[*] Previous page

Go to full version