Animating rotation speed


I would like to set up a rig (xpresso or other) where I can control the speed of rotation of several wheels which are part of a machine (each wheel affecting the others via belt system)

I need the wheels to be spinning at one speed, then at a point in time, begin to slow to a different speed, and then maintain that new slower speed.
Ive been trying several approaches, but changing rotation speed will usually wind the objects backward to a new rotation degree state b4 moving again.

Any help would be appreciated.




will take a look. Thanks benytone


At it’s simplest, you just pipe Time into the rotation parameter you need. Then use a user slider affecting a multiplier for the Time. Then you can set additional multipliers before the input of specific object rotations. For example. If a wheel is half circumference of the larger wheel, you can put a x2 multiplier before it. So it always spins at double the speed after Time runs thru it.

So in the end to speed up and slow down the machine you are only keyframing one User Slider.

I made an example project file for you:


Thx Chris (was hoping you’d see this :slight_smile: )

I have a set up like this now–just in testing mode on one proxy object for now. In order to get a number to multiiply I am running through a range mapper like so. I am keyframing the rangemapper output value–but still getting that unwinding effect as the value changes. I dont do a lot of xpresso–and it shows.

AHA–just saw your updated scene file link…thanks…


Hi Chris

Tried your scene file (THANKS)
Works great for changing the speed in the editor, however, if I keyframe the speed to start at say 100, and then over 30 frames add another keyframe to bring the speed down to 10, I still get that unwinding of the wheels before they start moving again. This seems to be the result I get no matter what procedural set up I try.


Well–Ive ditched the xpresso idea for now as the deadline looms. Instead I am nesting nulls each with a different rotation speed. I can just diminish the parent null to a slower speed as needed and the child null will then continue to spin at the new slower speed.

Using the inheritance effector for all other wheels targetting the rotation of a master wheel. Constraints were working fine too–but the problem with constraints is if you screw something up and need to tweak–the objects wont snap back to their pre-constrained positions in space. Inheritance is working well enough for me–but Im sure theres some obvious thing Im overlooking in the xpresso solution, and would like to get to the bottom of it later.


Well, I tried with small luck to use a ADD node as a buffer. So as the slider went to slower speeds it gave a corisponding number to be added back to time to fill in the gap. So it wouldn’t reverse or go to odd speeds. The key was getting the right number to be added back. But then I got tired. :slight_smile:

There is some really elegant math solution here somewhere that way smarter people than you and I will point out :wink:

Obviously it’s possible, there are procedural physics simulations that don’t go backwards when they slow down.


mjr Rotator (v.2) over at XPresso24 is a great example, if you can get logged in.

Cheers, Alan.


Thanks chris–appreciate the help–but dont lose sleep over my problems.
I’ve tried to buffer my ADD node too–usually means quitting ichat. :wink:

Rantan Al is correct --there is a great solution over at xpresso24 that solved the issue.
Studying the set up now.


Another goodie is Pavel’s MoXPig Rotator.

I have one which is even simpler but can I find the dam’ thing.

I’ve had as much sleep as you Joel. :smiley:

Cheers, Alan.



Here’s another way to handle that, it’s a bit unorthodox, but it works and it’s a very simple rig. It’s what I call my perpetual motion machine rig. :smiley:

Cactus Dan


:thumbsup: Thanks Cactus Dan. That will work great too.
I was thinking along these lines originally (coincidentally inspired by a response you gave me a few years ago to a similar dilemma) but with all the wheels involved I wasnt sure if it would be a good approach. Using a rig like yours however as the master object and then using xpresso or mograph inheritance to target it and drive the rotation of other objects in the scene (with mutipliers as needed for different speeds) is another good way of doing this.

Rantan Al–I was thinking about moxpig but havent dug into that yet. Its caused some crashing for me in the past.



I don’t know if I mentioned it before, but that setup was an accidental discovery. I accidentally put the target object as a child of the object that was targeting it and it started spinning on it own, so I thought, “Oh, cool. Look at that.” :smiley:

Cactus Dan


veyr different but sensible solution the problem


Gaah! I found some of the set-ups I had made before and it suffers from the “JoelD’s” when I added go faster-slower keyframes.

One of them originally used Dan’s idea of a target rotator and I changed it to an XPresso only drive. Seems to be that you need a Memory node and compare with the previous frame somewhere in the equation.

Cheers, Alan.



Hehe, actually the logic of the set up is quite simple.

Since the target is a child of the object and is offset from the direction of the object’s Z axis, you can see that on each viewport update it’s going to rotate by that much, trying to achieve the target direction:

Then after it rotates by that much, it ends up pushing it’s target child object by that much, too:

Since during animation, the view is only updated once per frame, it will always animate at that speed. :wink:

Cactus Dan


This thread has been automatically closed as it remained inactive for 12 months. If you wish to continue the discussion, please create a new thread in the appropriate forum.