Heya Folks,
I was doing some renders of a digital double recently which used displacement maps from mudbox for most of the detail. When I rendered this with 3d motion blur the difference in render speed was pretty big and also as you'd expect, the memory overheads jumped hugely. The motion blur admittedly had 4 steps as our lovely director wasn't happy with the vector blur we used in nuke originally, so I used 4 steps in 3d to get nicer arcs that were clearly fully rendered 3d blur.
I don't know exactly how vray calculates motion blur but I'd imagine it does something like look at where every vertex in a mesh is at frame N, then where it is at frame N + 1 and work out the path to blur along between these two places, so in effect it's almost doubling the geometry in the scene to work this out (in the case of deforming geometry). If you have 3 motion blur steps, then vray has to create a starting mesh, middle mesh and an end mesh to work out an arc, again causing higher memory overheads. Is this a correct way of thinking about how motion blur is calculated internally?
If the above assumptions are true, then if you try to motion blur meshes that use displacement, then you could be looking into serious memory overheads if vray is tracing each vertex all the way along! Just wondering if there would be anything to be said for a less accurate option for motion blur in the case of displacement such as making all of the vector calculations from the underlying, simpler mesh and then interpolating this for all of the newly created verts? In some ways it'd almost be like all of the various material overrides that we have to allow much simpler materials be used for GI or light calculations to make sampling quicker?
In hindsight what I really should have done is taken into account that my mesh would be pretty heavily blurred at the start of the shot anyway and use less fine displacement settings!
Either way I'd love to know what type of method vray actually uses to sample its blur!
Cheers,
John
I was doing some renders of a digital double recently which used displacement maps from mudbox for most of the detail. When I rendered this with 3d motion blur the difference in render speed was pretty big and also as you'd expect, the memory overheads jumped hugely. The motion blur admittedly had 4 steps as our lovely director wasn't happy with the vector blur we used in nuke originally, so I used 4 steps in 3d to get nicer arcs that were clearly fully rendered 3d blur.
I don't know exactly how vray calculates motion blur but I'd imagine it does something like look at where every vertex in a mesh is at frame N, then where it is at frame N + 1 and work out the path to blur along between these two places, so in effect it's almost doubling the geometry in the scene to work this out (in the case of deforming geometry). If you have 3 motion blur steps, then vray has to create a starting mesh, middle mesh and an end mesh to work out an arc, again causing higher memory overheads. Is this a correct way of thinking about how motion blur is calculated internally?
If the above assumptions are true, then if you try to motion blur meshes that use displacement, then you could be looking into serious memory overheads if vray is tracing each vertex all the way along! Just wondering if there would be anything to be said for a less accurate option for motion blur in the case of displacement such as making all of the vector calculations from the underlying, simpler mesh and then interpolating this for all of the newly created verts? In some ways it'd almost be like all of the various material overrides that we have to allow much simpler materials be used for GI or light calculations to make sampling quicker?
In hindsight what I really should have done is taken into account that my mesh would be pretty heavily blurred at the start of the shot anyway and use less fine displacement settings!
Either way I'd love to know what type of method vray actually uses to sample its blur!
Cheers,
John
Comment