We currently use Maya/Vray and a Houdini/Mantra rendering pipeline and we have tools to export vray lights from maya>houdini and shader conversion tool. One thing I have noticed is that Houdini’s PBR and micropolygon PBR renderer is extremely fast at heavily motion blurred scenes with the same scene/lighting and similar shaders. I understand Mantra doesn’t use raytraced motionblur by default but beyond that I don’t really understand how it can be so much faster. I’m guessing PBR somehow drags the samples along the velocity vector( thus requiring alot less samples) instead of firing additional samples along the vector to get a clean result. Any insight would be great! Also, if there is anyway of implementiing a mantra style motion blur with Vray that would be great too! Thanks
Vray does really really accurate motion blur on displaced surfaces as they’ve aimed for quality first, the only problem with this is as you say it’s a bit slower than a faked version and it’s also quite memory intensive. Vlado’s mentioned that they’re working on it at the minute, some people had mentioned stealing vectors from the underlying non displaced surface as an example and he said that was possible.
Well this topic can get big R_Cyph, what you are talking about is something like mental ray’s rapid rasterizer blur where it samples everything once then blurs the result. But I could never get good clean image with reasonable render times in it (in mental ray). If you don’t raytrace the difference is dramatic. But vray cannot not raytrace so this situation is kind of different.
As far as I know it’s at the theory point right now. There’s other things that benefit similarly like having options to calculate light cache from the non displaced mesh so Vlado is thinking about it.
It is faster for the same reason that PRMan is faster at motion blur: a) micropolygons are projected on the screen directly rather than found by raytracing, and b) shading is static and typically computed without motion blur.
We do not plan to do any of that for V-Ray; our goal is to keep it as a pure raytracer. Instead, V-Ray 3.0 has some specific optimizations for faster tracing of camera rays. In addition, you can use shade maps to reproject the shading of a static frame onto moving geometry. These two features combined can help to reduce render times for motion blur. You can use shade maps even now, but the process is somewhat cumbersome and inconvenient.
Ah so PRman isn’t actually sampling lighting for the polygons in the space that they’d move into with proper motion blur? In other words the shading is spatially inaccurate for something like a fast moving object going through a tunnel with overhead strip lighting?
As far as I’m aware, it doesn’t (by default, at any rate). The micropolygons are shaded at one specific moment of time, with everything assumed static, and are then blurred across the image.
In other words the shading is spatially inaccurate for something like a fast moving object going through a tunnel with overhead strip lighting?It is inaccurate, yes (again, by default; there may be a way to get the correct thing).
An easy test for this is to get e.g. a rotating propeller viewed and illuminated from the front, so that the propeller blocks its own shadow. If shading is correctly motion blurred, you will never get to see the shadow itself, since it is at any one moment blocked by the propeller. However, PRMan normally computes the shading and motion blur separately, leading to an incorrect result.
Here are some tests done with 3Delight as an example where I’ve made a rotating red box with a spot light that casts blue shadows. The correct result as rendered with V-Ray is to see just the red box (since it almost completely occludes its own shadow). But 3delight calculates shading first, and then does the motion blur so you can incorrectly see the blue shadow behind the box. (It may be perfectly possible to get 3delight to render the correct image, but I don’t know it well enough to do that.)
Of course, this may or may not be an important difference (in many cases it isn’t).
@Vlado
Well, maybe you can turn on pure raytrace mode in 3delight to fix that( hider set to raytrace), but what’s the point doing that? LOL.
( good for some benchmark purpose )
The raytrace hider didn’t change anything and I didn’t expect it to - the hider is just for camera rays; it has no effect on the actual shading. Micropolygons are still shaded in exactly the same way. If there’s an option for this in 3delight, it’s something else. Below is the image…
well, they said it will change into raytrace render path.(a lot slower)
And that’s how we fix some of the too close to camera displacement problem( if not eyesplit will actually discard whole geo.)
Guess the underlying renderer is still the same.
The last time I checked a mantra PBR render the shadow were motion blurred as well. I haven’t tested this specific senario though. Also, there is an option for raytraced motionblur which is off by default.
Also, there is an option for raytraced motionblur which is off by default.Again, that doesn’t mean anything if the raytracing is for camera rays only. Also, I presume that this is a lot slower than non-raytraced moblur.
R_Cyph, what you are talking about is something like mental ray’s rapid rasterizer blur where it samples everything once then blurs the result. But I could never get good clean image with reasonable render times in it (in mental ray). If you don’t raytrace the difference is dramatic. But vray cannot not raytrace so this situation is kind of different.
