Announcement

Collapse
No announcement yet.

An option to use underlying geometry to calculate motion blur of displaced meshes?

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • An option to use underlying geometry to calculate motion blur of displaced meshes?

    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

  • #2
    Originally posted by joconnell View Post
    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?
    This is correct, yes. It might make more sense to enable more geometry samples only for the objects that really need them though, rather than for the entire scene.

    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!
    It is somewhere on the "to do" list to add an option that reduces displacement detail depending on the speed of an object, though we haven't gotten round to implementing this yet.

    Best regards,
    Vlado
    I only act like I know everything, Rogers.

    Comment


    • #3
      Thank you so much for the reply. The scene itself only really has the digi double model, a very simple environment to provide some bounce from the included vray lights but it's a very good point. I'm going to have to write some kind of check list for myself so that I set up my scenes as responsibly as possible.

      That speed option sounds great too and nice to have some really elegant internal solutions to stop lazy people like me from hurting themselves with bad render settings

      Cheers again Vlado.

      Comment


      • #4
        Err, i know some OTHER renderer has a nifty option, typically on the shader, light or as a global setting, to "raytrace displacements", or in other words, to take their contribution into account for that specific effect.
        Say we have a slight displacement on a surface, up close, mostly in shadow, but with glossy highlight.
        The shadowing itself COULD conceivably be calculated on the base mesh, while the shader would calculate the highlights on the displaced one, as in this case highlights would be what define the shape (hence i'd turn the shadowing for the light, either on the object, shader or light to "not trace displacements" for the shadow rays.)

        Conversely, should the object be mostly shaped by diffuse shading, and sharp lighting, the GI could skip the displacements for sample placement and gathering, as the variance between the base and displaced meshes wouldn't lead to appreciable differences, any of which would be drowned by the contrasty, direct lighting (which would indeed take displacements into account to cast the shadows).

        It's likely to lead to one more layer of switches pretty much everywhere, and more TDs crying in a corner to debug shots, but i have seen it in action and i have to say that when set up properly it's a huge timesaver with very negligible differences.

        Would you think this possible at all, Vlado?
        Lele
        Trouble Stirrer in RnD @ Chaos
        ----------------------
        emanuele.lecchi@chaos.com

        Disclaimer:
        The views and opinions expressed here are my own and do not represent those of Chaos Group, unless otherwise stated.

        Comment


        • #5
          Reading this thread, i was thinking the exact same thing lele said.
          Back in my prman days i remember having the possibility to disable/enable displacement within certain conditions had a huge boost in productivity in a lot of situations.
          KCTOO - Directors

          Comment


          • #6
            Why did you have to name the OTHER renderer, now? I was trying to forget it... XD
            Lele
            Trouble Stirrer in RnD @ Chaos
            ----------------------
            emanuele.lecchi@chaos.com

            Disclaimer:
            The views and opinions expressed here are my own and do not represent those of Chaos Group, unless otherwise stated.

            Comment

            Working...
            X