Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Raxx]

animating bone length should translate vertices along the bone, kind of like they're attached to a hydraulic cylinder. scaling could be a separate tool

That's the same effect as moving/translating a bone (except moving also allows you to work in the other 2 axes).

[Deepthought]

wouldn't moving in the other 2 axes disconnect the bone from its parent?

[Raxx]

Physically, it'll "disconnect" it from its parent if moved on any axis. But so what? The bone still moves and rotates if its parent moves and rotates, except offset from the head of the parent bone. In some animation packages, the relationship between child and parent is shown by a dashed line going from the parent's head to the child's base, so even if it's "disconnected", it's still easy to see what's going on.

The current skeletal animation system in Anim8or is extremely, extremely rigid. Without being able to freely move, rotate, and scale bones, I don't think there's much hope for a good IK and constraints implementation later on.

Visualize, if you will, the current Anim8or getting bone length animation implemented, where it translates the vertices along the length of the bone. Now visualize, afterwards scaling gets implemented where the vertices scale with the bone. Now it becomes really confusing since visually, scaling a bone along the Y axis would look the same as changing the length of the bone, except this same "action" has two different effects. Now assuming that hurdle somehow gets crossed, visualize Anim8or with bone translation finally implemented. Changing bone length becomes redundant, so all that work gets scrapped and all the prior confusion and headache could have been avoided.

[Deepthought]

If you're gonna change something might as well go big. and that would reduce confusion.

[Raxx]

I did kind of start getting into it in this post and subsequent posts. While it's mostly about bone creation, it shows how "disconnected" bones work in two other animation programs. When animating, translation and rotation works much the same way as in the video.

[nemyax]

A traditional bone in a 3D package is:

• A transformation
• A link to the parent, if any
• Some visualisation attributes (shape, drawing mode, length, etc.)
• Some constraint-related attributes (FK limits, IK limits, etc.)

It's obligatory that at least all of the transforms (translation, rotation and scale) be animatable.

[Deepthought]

so: if you scaled a bone, it would move the child bones and scale the vertices?

[Steve]

Any change to a bone's transform matrix will affect any vertices that it influences (and of course will move/rotate any child bones).  Currently the only thing that you can change is the orientation but if support for scaling, length and location are added then the vertices will move/scale like this:

changing length: vertices near the root will not move much, those near the tip will scale more or less as the bone scales.  Any change is in the direction of the bone.

changing scale: vertices scale away from or towards the bone.  It's not clear where the center of the scaling should be - the base of the bone, the center?

moving: all vertices move equally.

Does that sound OK?

[nemyax]

so: if you scaled a bone, it would move the child bones and scale the vertices?

It would offset and scale the child bones, unless they are configured not to inherit scale (a common option in animation software).

[Raxx]

changing length: vertices near the root will not move much, those near the tip will scale more or less as the bone scales.  Any change is in the direction of the bone.

changing scale: vertices scale away from or towards the bone.  It's not clear where the center of the scaling should be - the base of the bone, the center?

I don't see any point in implementing length animation when there's scaling animation, unless you're just describing what would naturally happen when scaling along the Y axis? As I mentioned in an earlier post, if both length and scale were separate entities, it'd become confusing differentiating between the two when in the workspace.

In Blender, scaling starts from the base of the bone, and the vertices scale at the same rate that the bone does (as if the vertices and bone were in a group with the bone's base as the center of geometry).

Also, as nemyax mentioned, in Blender (and I'm sure most other animation packages) bones have the option to inherit scale, location, and orientation, which can each separately be enabled/disabled. Which means that if scaling a forearm bone, it can become massive, but if the hand bone is set to not inherit scale, it'll remain in its small original state. If set to inherit, it'll scale with the forearm bone. In Blender inheritance is enabled for all three transforms by default.

Also the option to be connected/disconnected, which means that when connected, there's no way to move the bone away from its parent bone (the base is stuck to the parent's head). When disconnected it can be moved away. This option becomes important not just for normal animation, but also later on when constraints are implemented.

[nemyax]

Also the option to be connected/disconnected, which means that when connected, there's no way to move the bone away from its parent bone (the base is stuck to the parent's head). When disconnected it can be moved away. This option becomes important not just for normal animation, but also later on when constraints are implemented.

In Blender, this option is there mainly for historical reasons. However, it still matters for auto-IK, which acts only on "connected" chains. If the Blender team were to revise the auto-IK implementation to allow configurable chain length, then the "Connected" option would become redundant, because translation can be locked anyway.

[Water Music]

Assuming the root of the bone is the origin and the bone moves in the positive z direction, the obvious center for x and y scaling would be the line where x and y equal 0, i.e. away from the center of the bone.  The trick is what to do with vertices that are influenced by the bone that have a negative z value.  Do they stretch behind the bone?  That could throw the joint off.  Do they not stretch?  That could throw off the proportion of the limb.  Do you take the most negative z value vertex influenced by the bone as the 0-stretch point and stretch out from there?  That might cause joint problems as well.  I don't have a good answer, I think you'd have to experiment to see which works best.

[Raxx]

Also the option to be connected/disconnected, which means that when connected, there's no way to move the bone away from its parent bone (the base is stuck to the parent's head). When disconnected it can be moved away. This option becomes important not just for normal animation, but also later on when constraints are implemented.

In Blender, this option is there mainly for historical reasons. However, it still matters for auto-IK, which acts only on "connected" chains. If the Blender team were to revise the auto-IK implementation to allow configurable chain length, then the "Connected" option would become redundant, because translation can be locked anyway.

That's true. If Anim8or could lock scale and translation of bones like it can lock/limit rotation, there won't be much use for the connected attribute.

Assuming the root of the bone is the origin and the bone moves in the positive z direction, the obvious center for x and y scaling would be the line where x and y equal 0, i.e. away from the center of the bone.  The trick is what to do with vertices that are influenced by the bone that have a negative z value.  Do they stretch behind the bone?  That could throw the joint off.  Do they not stretch?  That could throw off the proportion of the limb.  Do you take the most negative z value vertex influenced by the bone as the 0-stretch point and stretch out from there?  That might cause joint problems as well.  I don't have a good answer, I think you'd have to experiment to see which works best.

Your negative z value would indeed scale the other direction. Just like how on your x/y plane, those in the negative quadrants would scale opposite of the positive quadrants. If you don't want such a thing, then either don't assign vertices behind the bone to that bone, or move the bone so that no assigned vertices are behind it.

[nemyax]

The trick is what to do with vertices that are influenced by the bone that have a negative z value.

Vertices simply follow the transformations of the bones that influence them, in accordance with the influence factors (weights). If you're giving a bone a negative scale, it's only expected that the vertices will go along.

Assuming the root of the bone is the origin and the bone moves in the positive z direction, the obvious center for x and y scaling would be the line where x and y equal 0, i.e. away from the center of the bone.

A bone should have only one transformation. It's hard enough to get it right with one coordinate system per bone, what with parenting and constraints. Having multiple transformations per bone is just wrong.

[Deepthought]

What would be the use case for scaling? besides a GMOD inflator tool type thing