We have a scenario where a camera is moving out on some geo and lights that are themselves stationary, with motion blur. We have a raytraced shadow being cast by the light, and we're getting a problem where the apparent shadow alters significantly during the camera motion to be shorter. So if you pull out it “dials out” the shadow and it reappears as the camera slows down.

We've tried this with and without ray tracing mode - raytrace is actually massively worse, with the entire side of objects going dark during the move. We tried scaling things without the behaviour changing. Turn off motion blur(xform or deform) or the raytraced shadow and everything behaves properly.

Any thoughts as to what this is related to?

Thanks

J.C.


OK, I found a partial solution. When rendering in micropoly mode, I'm trying to raytrace the shadow, and that's getting mussed up with moblur. Rendering with ‘-Q B’ addresses that so I can at least get the job done. However, this still leaves the much larger problem of a raytraced scene with a fast moving camera seriously mis-rendering the brightness value with shadows on. Still scratching my head on that one.

Sorry, running 8.1.810

Modifying the bias is tricky when you have small localized detail on your geometry. Have the bias too large and the shadows detach from your object and have it too small and you get massive self shadowing during pull backs. Stupid computers.

Just noticed this problem myself a couple of days ago.
I suspect this is happening because mantra lacks a Raytrace Motion Blur option, so it doesnt trace the shadow for each time sample (i'm sure there is a more correct explanation for what I mean), so objects end up appearing to be moving in and out of the shadow.

What we need is a Raytrace Motion blur option ala Renderman…this is a biggie coz its a show stopper for raytracing+mb. Unless its in there somewhere and I've missed it.

to see what I mean do the following:
-make a simple sphere and ground scene
-animate a light moving over the scene, notice that the shadow doesnt blur
-animate the sphere moving left to right, the sphere blurs but the shadow is sharp.
-put the light directly above the sphere and animate the ground moving left to right, the shadow is now blurred but is shifted toward the direction of the ground movement.

Tried comparing with and without -Q B and didnt see any diference, what does it actually do btw? I put it in the render command in the mantra1 rop.

Another thing sideFX could do for motion blur is to add support for multi-segment motion blur… really important for rendering anything resembling a spinning wheel.
This one has been colossal PITA in my current project (rally game fmv), where we ended up rendering a wheel pass in MentalRay, coz multi-segment is not supported in rmfm.

-btw my example above shows the same problem as yours when I turn off micro-poly rendering.

Serg
Tried comparing with and without -Q B and didnt see any diference, what does it actually do btw? I put it in the render command in the mantra1 rop.

As far as I know the -Q B only really applied to micropolygon mode.

Serg
to see what I mean do the following:
-make a simple sphere and ground scene
-animate a light moving over the scene, notice that the shadow doesnt blur

Aye, these things won't work because the shaders are only evaluated once.
In micropolygon mode P is computed at shutter open.
In raytracing mode P is computed at shutter close.

Hi Wolfwood,

Thanks for showing me that stuff is possible in houdini I finally figured out what got me totally confused after seeing your post… if my sphere and ground are inside the same model (I animated the ball at sop level) then I dont get any raytraced motion blur effect (blurred shadow on ground as in your image), all is well as soon as I split it into two… now I'm wondering if thats a bug or a limitation.

Thanks

90% Guessing
10% Assuming


When the animation occurs within SOPs its deformation motion blur and basically you are restricted to what has happened at either shutter open or shutter close.

When you animation occurs at the Object level I suspect raytracing mode can be a little bit smarter and when tracing shadows can take samples over time.

As a little test, try the infamous rotating propeller by rotating at the object level. Render with Micropolygons and compare those results to what you get with raytracing.


Images:

Box rotates 90 degrees with a shutter of .75

The problem demonstrated in Wolfwood's post should be fixed in tomorrow's build of H8. Just to clarify, the issue that's fixed involves “mantra -r” (raytracing only mode) in combination with motion blur and secondary rays such as shadows, reflections, and occlusion.

Andrew

andrewc
The problem demonstrated in Wolfwood's post should be fixed in tomorrow's build of H8. Just to clarify, the issue that's fixed involves “mantra -r” (raytracing only mode) in combination with motion blur and secondary rays such as shadows, reflections, and occlusion.

Andrew

BIG THANKS to Andrew and Mark for fixing this in record time!
…and saving our collective butts!…

*applause*

I can't get the same result as Wolfwood said.

pls see the image.

the main prob is I cant get segment MB fx,and the propeller's corner isn't round.
I searched help card and odforce for this prob,still cant get it working.
for somebody who have same prob,see
http://forums.odforce.net/index.php?/topic/8228-multi-segment-motion-blur-shading-sampling/page__pid__54881__st__0&#entry54881 [forums.odforce.net]

$F*6
Really?
And you want sub-frame motion blur?
$F is an integer!
$FF is floating point Frame and is what you need to use.

$FF*6 thank-you. Everyone listening?

I always use $T as it gives me number of rotations per second and is invariably a float.

With that taken care of, you need to increase the xform time samples on the Mantra Output Driver to 4 or 6 to get nice smooth motion blur for the propeller.

I can see that increasing xform time samples when you used the incorrect $F*4 caused horrible results.

ok I made a stupid error

Also .
The blade is running far to slow increase it to $FF*200 and lower those pixel samples . 8 x 8 will be fine

r