Hi. I was getting frustrated that I was not seeing motion blur on a rotating propeller using Redshift. My setup was previously motion-blurring fine using Mantra.

I trouble-shot this by creating a simple cube and animating a rotation on the Z-axis (like my propeller) and it produced motion blur. I then copied my propeller setup into that cube's geometry node and it now also blurred perfectly.

I soon realized what the difference was between the two:

The geometry node that would not produce motion blur was being rotated with an expression to animate it. Specifically: $F*321 Again, this worked just fine when rendering in Mantra. Why would Redshift motion blur fail with an expression but work just fine with keyframed rotations?

I obviously already have my solution, but I'd like to know why this fails so I don't run into this problem again with expressions for other things that might fail using Redshift.

Redshift version 3.5.13
Houdini version 19.5.493

Thank you.

hmmm... I actually just tried $FF*321 and $T*321 and both of those expressions produced motion blur in Redshift. It is only $F*321 that seems to be failing (but again, $F*321 works when using Mantra.

<scratching my head>

Using $F will create a constant value during the whole duration of the frame. If Redshift calculates the velocity by sampling the position at, let's say, frame 1001 and 1001.5, it won't see any difference and won't generate motion blur. Using $FF or $T will create a value that actually progresses during the frame, so won't create this problem.

Thanks for the explanation, Tanto. I was originally going to ask why it would still render fine in Mantra if I use only $F instead of $FF but realized "well, that's probably just a difference in how Redshift calculates things vs. Mantra. Deal with it."

I might still post this to a Redshift forum in case it's actually a bug but I always assume people who are more of a "power user" than me will have already flagged it.