• Editor

  • Range Constraint

    engleski
Related Discussions
...
10 dana kasnije

Hello,
It would be useful to have a new constraint type that limits what transformation values the constrained bones can have.
It would have a parent-relative mode and a root-relative mode; it would allow for minimum and maximum values to be set for position (requires separate x/y), rotation, scale, and shear; and each of those would have a mix.
The most obvious application for this I can think of is limb range of motion.
You could, for example, restrain a leg to never bend though a character's body. Take a human character facing right. Setting a range constraint on the thigh bone to parent-relative mode and limiting its angle to something like 350 (angle when thigh is bent back, slightly behind the torso) to 170 (angle where thigh is as far in front of character as possible). And you could give it a 95% mix so instead of stopping, the rotation just slows greatly for 171-349.

More than just simplifying certain animations, this would allow animators to build in a sort of fail-safe to prevent procedural animations from doing anything really weird in corner cases. It could also help with certain pseudo-physics things in spine (constrain a skeleton's translation to a box that acts like walls, ceiling and floor, especially useful on leg IK targets with regards to the floor).

Overall, it could be a major convenience in spine, and simplify certain things for developers manipulating animations at runtime.

Bump bump, tssshhhhh.

Yea. I also need this feature too. I exactly facing the same problem . e.g. leg/arm stuff blending too much with main bone.

I have a reduced version suggested some months ago for other simpler cases because I believe it would take less time to implement but I guess I am wrong...
Locking a value of a bone?

Range limiter would be better than just locking a value as it is more flexible.

Note that it is not similar to "constraints for converting one transform property to another ".
Range limiter should be able to work on its own(stand alone) to enforce values with user input. Referencing other thing for the range limit values could be a different kind of range limiter but it should not be enforced to do so. Otherwise it will make the workflow more complicated when needed.
This kind of constraints should also be the highest priority implicitly(performed last in the constraint queue). Otherwise it just became meaningless when clamped a value and that value get modified by some other transform constraints later on. So such range constraints should their own processing queue at the very end instead of sharing the same queue with current constraints.

I think they should be in the same queue, it's the users responsibility to ensure they are applied so that they actually take effect. There may be applications where users want to put limits on transforms made by some constraints, but allow transforms from other constraints to break those limits.

Haha. I cannot think of a case where you need to setup a range limit constraint but also some other transform constraint want to break it.
But it doesn't hurt much to have them share the same queue. My concern is there are just too much item in the constraint queue for complex project. Range constraint generally would be the last thing to do to ensure the value is clamped probably but there maybe exceptional cases as you mentioned. It would be great if the constraint queue could support grouping/folder so that I can group constraint and make things more manageable visually. e.g. I could put all my range constraints to a group at the end and fold it to make things more readable. I could also group constraints by zones. Sometimes things just get messy when there are like 20 constraints in the list.

Would love this, rotation restriction so that things like necks don't rotate to impossible angles.

@fantasyz Yeah groups of constraints would be great, just collapsible folders. And perhaps each group (and each constraint for that matter) could have a pin to top/bottom option. New items would be added to no group and with no pin, so they would be between pinned top/bottom groups.

Oh, and with the pinning feature, maybe range constraints would be unique in that they are created with 'pin to bottom' set.

6 mjeseci kasnije

Hello, any news about this feature ?