Making wheels spin as car moves on local Y axis

Question

I'd like to know how to make my car wheels rotate when a vehicle is moved forward in the local Y axis, regardless of what rotations on other axes the car may possess. This should specifically work with an armature.

Answer 1

Normally or most often, people do this with simple drivers.

1. create a empty-cube over your car.
2. Make the empty the parent of the car and wheels.
3. on the wheels object X-rotation insert driver, "manually create later".
4. in the grapheditor (in animation mode), at bottem set drivers.
5. in graph editor Select the wheel
6. expand right side of grapheditor screen go to tab drivers
7. under variable, select your object (defaults to transformation) notice that you can select the channel you like to transform this gets into the variable var, and a little bit higher in the screen you put in a little math to use "var * 2" or less or more (speed) positive/negative for direction.

Eventually using these principles a car might look like this then And one could rotate the z axis of the wheel using a modifier (copy from z rot of the small (green) bones above it) so inner wheel would turn more as compared to the outer wheel. In Below a simple car with 4 wheels and a armature to stear it all have the empty cube as parent. In the below example i let the small bones "track to" the front bones to get more realistic stearing Using bone constrains, but you might also just take rotation from a single bone armature.

The constrain on the wheel to copy its Z rotation from an armature bone The armature has not been bound to the mesh itself with automatic weightpaint, its a simple setup. As everything is parented to the empty cube wheels will stay in place.

Answer 2

You cannot easily do this, because it is impossible. @Nathan is right, but I'll add here my explanation:

When moving the car in the scene, you want the wheels to correctly follow - let's move the car 2 different ways:

In first example the wheels traveled longer distance, yet the end car position is the same.

Without Blender accessing and knowing what the path was, it is impossible to compute the wheels rotation, because it can be anything based on how the car was manipulated. When you interactively move objects in the viewport, Blender does not store your moves. The bones only remember their rest and their final (pose) position.

Blender can access what the path was from:

• animation keyframes
• from defined path the car is traveling (follow path constraint)
• from simulation that treats the movement on frame-by-frame basis (you can have a little python script running in background as app.handler and turning the wheels, it could look similar to this, or you can implement this with nodes in Animation Nodes addon)

The easiest and most common method would be to use the path. How to setup a driver that rotates the wheel is here:

How can we animate a ball rolling over a path?

It's convenient to offset the curve for left and right wheels and setup both sides separately, so they rotate correctly when turning.

Answer 3

This is actually one of those problems that sounds simple but is very tricky and poorly defined. And understanding why that is is very important.

Here I have a bone that I have moved in its local Y axis from the origin. How far has it moved in that axis?

I've provided two choices for you. One is the smallest distance from the bone to its original position. The other is its distance from the origin along its current Y axis. Which is the correct distance?

Don't bother, they're both wrong.

Check it out. Here's the same bone, rotated to be run parallel to its undeformed XZ plane. How far has it traveled in its local Y axis? For the second option, the projection to the origin along its local axis, it has traveled an infinite distance.

Maybe the first option, the sheer distance from the origin, sounds ok. But did it move in its local Y axis and then rotate, or did it rotate and then move in its local X axis?

When it comes to the way Blender stores bone transformations, it always takes the attitude that the bone first moved and then rotated. (That's probably because of some of the details of the math involved.) Because of this, when the bone rotates, the axis of its motion changes.

I saved the closest answer for last, because I wanted you to think about how this problem gets defined.

In this case, what we have is the projection along the local Y axis to the plane with the same rotation as the bone itself. This still might not be what you want. Because check out what happens when we rotate the bone:

The distance that the bone has moved along the Y axis changed. Even though the bone itself didn't move. That means that what's going to happen if you use this measurement of local Y translation is that your wheels aren't just going to rotate when you move in the local Y axis (although they will do that reliably), they will also rotate when you rotate the bone-- because rotating the bone changes the distance that the bone has moved. At least in this measurement. (The only conceivable one where it doesn't, that's the first option way back at the beginning.)

Now, maybe that's what you want. So I'll explain how I made this model.

You have three bones. You have your main control bone, to which your car body might be weighted. It's a root bone, no constraints. You have a floor bone, establishing the plane to which to measure distance. This is also a root bone, but it uses a copy rotation constraint in world space, targeting the main control bone. Finally, you have a bone that measures the distance to the main control bone. In order to acquire the proper orientation, it is parented to the main control bone. In order to be constrained to its particular plane, it has two floor constraints targeting the floor bone, in both Y and -Y axes, with rotation enabled. In order to measure the distance to the main control, it has a stretch-to-constraint.

Now, you can use a transformation constraint that translates the Y scale of this bone into the rotation of another bone.

Caveat: Transformation constraints don't play nicely with negative scales, so if you move your control bone below the plane, the wheels will spin in the wrong direction.

These issues are basically why you don't want to do this without using a follow path constraint. Use a follow path constraint instead, and drive both the offset and your wheels' rotation with the same value. That's the right way to do it.