I am trying to rig a wheel rolling around in any direction, and have it rotate automatically when moving using an armature. The Transformation Constraint seems to be ideal for this, however it does only work on one global axis. I broke it down to this simple example with just a simple “wheel” and a bone controlling it:
(Also I did not figure out how to make a gif out of Blender viewport, so I had to render it and create in Gimp.)
So at first the wheel rolls correctly with the bone along the Y axis. Then the bone rotates together with the wheel by 90° and starts moving again. Here I did not manage to have the wheel roll along the X axis. However, moving along the Y axis again makes the wheel rotate wrongly now.
Here is the setup I would expect to work:
I suspect there is a bug in the Space settings of the Transformation Constraint; I cannot make it work with any cominbation of these.
Does anyone have an idea how to make this work?
I also attach the blend file of this example for easy trying out. WheelRig.blend (578.2 KB)
Thanks a lot of any hint!
I have tried the same without success. I remember someone writing, that you need to bake the animation, but the current state of rigging based on bones only should be addressed in future releases. Hope.
You can’t do it (at least, not with constraints only) because in order to know how far to roll, your wheel has to remember where it’s been-- you can have two paths that end in the same orientation but with different lengths. And constraints don’t have any memory of earlier frames-- definitely not any memory of earlier viewport activity in the same frame!
It would probably be possible with Animation Nodes (which I’m starting to learn) but it probably still wouldn’t be worth doing, and it wouldn’t show up properly in the viewport, just when using keyframed animation.
The "right"ish way to do this is to give your wheel a follow path constraint or something similar and then drive its rotation on the basis of how far its travelled along that path. The only way that I know how to do that automatically requires editing the driver whenever you edit the path, but again, there are probably some tools to handle that of which I’m unaware.
Yes, but then the drive needs to know the path length to clac the rotation, based on the radius of the wheel. Animation nodes have a spline length node, but they are not for rigging, more for procedural animation.
Ok, too bad this does not work, because it would be really handy.
But then I wonder what the Pose Space is there for. It sounds like it would just conform to the local (pose) movement no matter the global orientation, what else? Still suspecting a bug here.
Will try out alternative ways later.
Hey, This has long been a ‘Thorn’ in Blenders foot - And NO it is not a ‘bug’, just a ‘short coming’ of a ‘Central Coordinates’ system that is not dynamic - in a nutshell. My solution to this is to create 3 rotating (rolling) ‘Actions’ (1) Start_Action (2) Rolling_Action (3) Stop_Action. Then using these actions in the NLA editor you can achieve endless combinations for rolling. You can keep some type of automated wheel rotation around for those times it works, just animate its on/off property.
Exactly, yup, you need to know the length of your path (as well as the circumference of your wheel) to know how far the wheel has to rotate.
But I would suspect you could use animation nodes to fill in these blanks for you. I wouldn’t recommend thinking that anything is ever for any particular purpose-- I imagine when normal maps first started being used, you heard people saying, “But textures are for colors, not vectors!”-- but procedural animation is what rigging is anyways. It’s setting up the procedures by which an object is animated, for the animator to provide the parameters to that procedure. In this case, the procedure is “Follow a path. Rotate in a single local axis based on the distance we’ve traveled along that path divided by the wheel circumference.” The parameter for that procedure s the path.
Well in C4D i use a phyton script add in a tag. It reads the bounding box size an use it for the calc. Then it takes the world position for distance. Done.
In Modo you have a special node that reads the relativ position in world space and put out the rotation.
If you just want to roll based on distance from origin, you can do that with constraints, but I don’t know why you’d want to. It’s not remotely right.
Point a root level bone at the position of the wheel. Damped track the wheel. Give it a child copying location from the wheel. The local Y translation of that child is the distance of your wheel from the world origin. You can use that distance as the input to a transformation constraint on a child of the wheel. (Can also do that relatively simply with drivers instead if you’d prefer.)
The reason it’s not rolling when you rotate it 90deg is because of rotation order. The “direction” axis needs to come after the “rolling” axis. Alternatively you can use a hierarchy of objects or empties to separate those movements : have a parent above the wheel responsible for giving direction, and let the wheel itself roll in its local space). edit I may have misunderstood what you did there, maybe I’m not being accurate. The rest below still stands though.
For the problem of distance travelled, there needs to be some sort of awareness of previous state, which is an area Blender unfortunately lacks in. Thankfully wheel movement is usually not paramount in a film’s direction, so you should be fine animating the wheel rolling at the very end, once most of the shot is set in stone.
Yes it’s not nay distance, but the position before and after the frame. It’s just that this is calculated automatically and you only need radius and world position as inputs for the calc.
Sorry I am not following. How is this calculated automatically ? Yes, I believe you’re right in those two variables (wheel radius and distance travelled) would be the only things needed… In the case of the object following a curve, that distance would be the delta arc length between two points of the curve. The idea is having a system that’s able to expose and cache this step information. That’s what the new simulation context in 2.90 is supposed to allow for, especially when it’s expanded to manage object level transformations (not in 2.90).
As far as I know there is no way to do this currently in Blender (apart from using rigid body physics, which as a number of implications, or using AN as others have intelligently pointed out).
I wanted to throw my two pennies onto this thread cos I had this issue with one of my vehicle rigs. I wound up using three transform constraints and using drivers to stipulate which one is currently active.
It’s not a perfect solution by any means, but I feel it’d be good enough in the vast majority of them.wheel_down.blend (3.4 MB)
I’m not sure how I would tackle this as far as instructions go, but what I have here seems to work.
