- Edited
Use case for transform constraint
I don't see when this would be useful rather than just moving the bone?
When we finish it you will be able to use it to constrain bones and animate the weight. This means you could do stuff like constrain a bone to two other bones and make it appear as if you're changing the skeleton hierarchy.
For example if you wanted a character to go pick up a hat. First the weight is set to 0. Then when the hand reaches the hat, you set the weight to 100 and it will now follow the hand.
I hope that clears it up
Also mix != 100% enables something that would be difficult to do manually: having a bone part way between two other bones at all times. How often that is needed, I'm not sure, but it may be interesting.
Eventually the transform constraint will also support scale and rotation.
I like Shiu's use case.
You can make a character throw a revolver in the air temporarily, let it move independent of his hand. Then he can catch it again. Cool stuff. Eventually.
Shiu wroteWhen we finish it you will be able to use it to constrain bones and animate the weight. This means you could do stuff like constrain a bone to two other bones and make it appear as if you're changing the skeleton hierarchy.
For example if you wanted a character to go pick up a hat. First the weight is set to 0. Then when the hand reaches the hat, you set the weight to 100 and it will now follow the hand.I hope that clears it up
This is what I thought, and what I tried out, but I couldn't get it working.
Baby steps.
As far as I know, constraints aren't very heavy. In any case they don't affect runtime performance nearly as much as IK.
Use the source, kxs! Transform constraints are not going to be the bottleneck in your application. Neither are IK constraints. The IK constraints code looks scary (and it is!) but all that stuff exists just to make sure it works correctly in all case. It has fast paths that cover most cases, but even the most extreme case that does all the math is not going be the breaking point for your game.
Pharan wroteI like Shiu's use case.
You can make a character throw a revolver in the air temporarily, let it move independent of his hand. Then he can catch it again. Cool stuff. Eventually.
Hey, it would be awesome if you could make an example!
The feature isn't implemented yet. I'm sure we'll make a sample when it is.
Nate wroteAlso mix != 100% enables something that would be difficult to do manually: having a bone part way between two other bones at all times. How often that is needed, I'm not sure, but it may be interesting.
Eventually the transform constraint will also support scale and rotation.
Is this how you could potentially support Piston/Expanding objects?
E.g. the rear leg section which needs to slide in/out when the leg is moving.
Xelnath wroteIs this how you could potentially support Piston/Expanding objects?
No, I don't think so. We can continue discussing your in the thread you created.
Hello,
Is there a planned release date for the key-able transform constraint? The character I'm working on interacts with quite a few objects that will end up in world space so this feature would be invaluable.
It's actually quite tricky with nonuniform scale. We'd like to get some other features done first, so it may be some time.
One thing you can do is have the same images on different bones, so you can hide/show them to make it seem as if a character picked up something.
Thanks Nate, I hadn't thought of that!
Will try it tonight.
Hi all,
Just wondering what you have in mind about the final constraint tool:
Maybe i'm mistaking but i was thinking about what 3d softwares offer at the moment: for each transformations a tick box for each axes (X, Y, Z) that allow you to limit the behaviour of a child regarding to his parent.
A concrete exemple on spine: a drop shadow, i wish it could be possible to parent a bone which contain a shadow asset that can only move on Y axis even if his parent is moving both X & Y axes?!