After giving up on Cinema's motor to logically regulate rotational speed, is it possible to make a simply rotation controller in expresso whose speed can be regulated by a slider? Like I want to rotate an object 90° every second, but I'd like to ramp up from stationary and then after a bit of time make it rotate faster simply by increasing the degrees it rotates over time. Does that make sense? I'm using the old free gearbuilder plugin that works awesome on this complex gear system but it's motor is doing funky things, probably because it's really old. Thank you very much in advance if anyone has any ideas, my brain hurts after attempting to mostly figure out why Maxon would create a dynamics based motor to begin with.

Hey Troyan, how about something like this, change the 'DegreesPerSecond' userdata slider on the Controller null to control the speed (defaults to 90 degrees per second).

[Edit - I notice the speed increase isn't completely smooth when the speed is animated, I guess it might need a more complex setup, I'd need to spend more time on it. Personally I'd just animate it if I was doing it myself, for me that's the most direct route to getting full control over speed/easing etc.

Another variant, a little smoother when accelerating but still not perfect. Might do the trick though. (I still think keyframes are the way to go though!).

The problem I see with driving absolute rotation values from an expression is when you increase the 'multiplier' (the amount it should rotate per frame/second etc) the driven object suddenly has to 'catch up' to that absolute rotation value, so the acceleration/deceleration will always look a little off. Possibly there's another way to approach it but with a simple animation curve driving the rotation that issue is resolved.

Hey Troyan, how about something like this, change the 'DegreesPerSecond' userdata slider on the Controller null to control the speed (defaults to 90 degrees per second).

the general problem of xpresso is that it is destructive and not content aware. such setup does not respect any keys set previously, you have to tailor that manually into the xpresso setup (where i personally think it is easier and more convenient to write a small python expression or plugin). the same goes of course for any other rotation approach in xpresso (rotation matrices and so on).

for a xpresso setup you would have to look back to the last key and sum that rotation up to the current rotation. you could do that for example by storing the rotation velocity and operate per frame (calculate the rotation difference to the last frame). but that will introduce interpolation problems for files with different frame rates in some cases. to make it 100% waterproof you'll need some python (or coffee). to make it visually more clear what i meant :

the general problem of xpresso is that it is destructive and not content aware. such setup does not respect any keys set previously, you have to tailor that manually into the xpresso setup (where i personally think it is easier and more convenient to write a small python expression or plugin). the same goes of course for any other rotation approach in xpresso (rotation matrices and so on).

for a xpresso setup you would have to look back to the last key and sum that rotation up to the current rotation. you could do that for example by storing the rotation velocity and operate per frame (calculate the rotation difference to the last frame). but that will introduce interpolation problems for files with different frame rates in some cases. to make it 100% waterproof you'll need some python (or coffee). to make it visually more clear what i meant :

Another variant, a little smoother when accelerating but still not perfect. Might do the trick though. (I still think keyframes are the way to go though!).

The problem I see with driving absolute rotation values from an expression is when you increase the 'multiplier' (the amount it should rotate per frame/second etc) the driven object suddenly has to 'catch up' to that absolute rotation value, so the acceleration/deceleration will always look a little off. Possibly there's another way to approach it but with a simple animation curve driving the rotation that issue is resolved.

Cheers,
Brian

Cool, and it works almost identically to Gearbuilders motor, unfortunately it has the same issue, so there must be some fundamental flaw in this approach. Or Cinema processes it strangely. Try this simple test, at frame 0, set a key frame for the rotation to be 0. At 1 second, set a keyframe for the rotation to be 90° and watch what happens after 1 second. There's a nice ramp up like you would expect from 0 to 1 second, then as soon as it hits that 1 second mark the speed snaps down to a much lower rate of speed. It's not a visual temporal thing. Which is what you might be talking about? But it's not a "little" off, it's a lot off. I wholly agree to the manual rotation approach but there's a lot of issues there as well with wanting to ramp up, maintain a speed for an amount of time then vary the speed at different points along the animation. changes would be hell. I'm just thinking there must be a simple approach to controlling rotation speed for someone who is a lot better at math than me.

Follow Us On:

The CGSociety

The CGSociety is the most respected and accessible global organization for creative digital artists. The CGS supports artists at every level by offering a range of services to connect, inform, educate and promote digital artists worldwide. More about us on TheArtSociety.com