PDA

View Full Version : No motion blur when using expressions



phorne_tca
09-09-2010, 10:47 AM
I built a simple rig for a fan blade. I have a "Driver" null (a simple null as a ring that rotates on the bank channel only) which, when rotated from 0 to -180 degrees moves another "Controller" null vertically in the Y direction from 0m to 1m. The expression on the Controller is "mapRange([Driver.Rotation.B],0,180,0,1)" and the expression the fan blade object itself is "10 * Frame * [Controller.Position.Y]".

The idea is straightforward - you rotate the driver to 180 degrees, and the fan blade object continues to turn. You rotate it to 0 degrees and the fan blade object is stopped. And the rig works perfectly fine.

However I'm not getting any motion blur on the object. I do however get motion blur on it when the Driver is animating from 0 to 180 degrees. So let's say the Driver is at 0 degrees at frame 0 and 180 degrees at frame 10. From frames 0 to 9, I get motion blur, but from 10 and on I don't.

Is this a known bug or am I missing something in the expression?? I've tried all different camera types and all different motion blur types for each camera - does the same thing on all of them.

Any help would be GREATLY appreciated!!!

-Patrick

phorne_tca
09-09-2010, 10:52 AM
btw, using LW 9.6 x64, if that matters

bazsa73
09-09-2010, 11:30 AM
I would just handanimate it. This whole expression-rig business sounds way too complicated.

phorne_tca
09-09-2010, 11:33 AM
well, that's what I broke down and did, but at this point, I'm more curious as to why motion blur won't work...

bazsa73
09-09-2010, 12:15 PM
Maybe you should share your scene, so the expression gurus could study it.

phorne_tca
09-09-2010, 12:39 PM
Sure thing :)

xchrisx
09-09-2010, 06:01 PM
Only had a couple mins to try this but, I believe the answer is this:
instead of (10 * Frame * [FanBladeController_CTRL.Position.Y])
use (10 * Time * 24 * [FanBladeController_CTRL.Position.Y])

if you zoom in on the curves you will see the Frame expression is very jagged and this is probably causing your problem with motion blur. Using Time * (framerate) essentially makes a smooth curve for sub frame calculations. By the way Skvarla says hello.

phorne_tca
09-09-2010, 06:23 PM
Lol - I was wondering how long it'd take for this thread to get back to Skvarla... I blame him for it not working :D

Thanks for the tip - that worked like a charm. (I couldn't see any changes in the graph editor for the rotation of the fan blade or any other objects for this jaggedness that you're talking about...but it works, so I'll take your word for it that it's actually there :) )

Many thanks!

jeric_synergy
09-09-2010, 06:23 PM
I built a simple rig for a fan blade. I have a "Driver" null (a simple null as a ring that rotates on the bank channel only) which, when rotated from 0 to -180 degrees moves another "Controller" null vertically in the Y direction from 0m to 1m. The expression on the Controller is "mapRange([Driver.Rotation.B],0,180,0,1)" and the expression the fan blade object itself is "10 * Frame * [Controller.Position.Y]".

The idea is straightforward - you rotate the driver to 180 degrees, and the fan blade object continues to turn. You rotate it to 0 degrees and the fan blade object is stopped. And the rig works perfectly fine.

::puzzles at it, then gives up:: Please, could you explain the theory behind this to a noob-like entity??

For instance, you say "on the fan blade object itself", but you don't tell which channel the expression is applied to.

Thanks!

phorne_tca
09-09-2010, 07:18 PM
The expression is attached to the FanBlade_Object.Rotation.B channel (so that the fan blade rotates).

The theory is that you have an null object moving up in the Y axis (or any other axis really) from 0m to 1m. This essentially gives you a scalar value which you can multiply by within the expression. So, you've got your degrees of rotation of the fan blade object (in the example I provided, it was 10 degrees, so 10), multiplied by the current Frame (so Frame, or Time * 24), times the Position.Y of the controller null.

So, let's assume your controller's height is at .5m:
on frame 0 you'd have: (10 {degrees of rotation per frame} *0 {your current frame} * .5 {the controller's height) = 0 degrees of rotation on your fan blade object.

on frame 10, (10 *10 * .5) = 50 degrees of rotation
on frame 100, (10 * 100 *.5) = 500 degrees of rotation

If your controller's height is at 1m, then on frame 100 you'd have (10 * 100 * 1)= 1000 degrees of rotation. If it was at 0.1m, then you'd only have 100 degrees of rotation. Make sense?

(I should note - I didn't figure this out on my own, this is from the brilliant rigging mind of the aforementioned Skvarla :thumbsup: )

Hope the explanation makes sense. In the scene file I provided earlier I just took it a step further and have another null driving the controller null so it's easier for the animators to access.

Cheers!
-Patrick

Dodgy
09-09-2010, 10:09 PM
One thing to note is frames are discrete entities, if you get the frame value it will always be a whole number. Time on the other hand is a continuous value, and able to return fractions of a second. Hence when LW calculates the motion blur which done on a sub frame basis, it will position the object the same for each of the motion blur samples for frames, but not for times. Hence why time works, but frame doesn't.

jeric_synergy
09-09-2010, 11:15 PM
Patrick, I really appreciate your explanation, thank you. It takes a bit of shaking to get me to remember my expression lore. So, essentially, this class of expression is a throttle, and can be used on any continually increasing channel. The maximum rate of increase is defined by the keyframed value, in this case the rotation, times the maximum limit of the controller. You've defined that max as 1, but it could be any number.

xChrisx's and Dodgy's point is really good and subtle: using FRAMES is always going to quantize an expression's result, even in the subframe calculations. Nice catch, guys.

phorne_tca
09-10-2010, 10:44 AM
Dodgy, thanks for the explanation as to why that works. That makes sense, really. Things to know for future expressions! :thumbsup: