[Soc-2018-dev] Weekly Report #10 - Further Development for Cycles' Volume Rendering

[Brecht Van Lommel]

Hi,

On Fri, Jul 20, 2018 at 6:01 PM Geraldine Chua <chua.gsk at gmail.com> wrote:

> There appears to be a bug where VDB textures are rendered with artifacts
> and solid shadows, but only if a volume mesh is created. I have attempted
> to debug the issue but cannot figure out the reason so far. In addition to
> this, generating a mesh takes a considerable amount of time compared to
> built-in smoke. A simple fix to these issues would be disabling volume mesh
> construction for VDB grids, but it would be nice to figure out the cause of
> this bug. Here is a comparison image of a VDB texture of an imported
> bunny_cloud:
>
> Without volume mesh: https://i.imgur.com/ispyeGF.png
> With volume mesh: https://i.imgur.com/6hbJUYp.png
>

I'm not sure what the cause could be. Did you try setting all the Light
Paths values and volume max steps to the maximum? You can visualize the
volume mesh by adding a surface shader.

It's not clear to me why generating the mesh should take so much time, is
it really slower with a comparable grid resolution? If we are loading
directly from the VDB file to sparse grids in Cycles, we should be able to
build the volume mesh quicker since we don't even need to look at the
individual voxels to see which ones are empty, we can just check if there
is a sparse tile or not.


> *Volume Motion Blur*
>
> With reference to the Stephen's previous work on volume motion blur (
> https://github.com/tangent-animation/blender278/pull/103), I wrote a
> minor patch with promising results. I am uploading the diff instead of
> committing since it's pretty hacky and there may be more efficient ways of
> going about implementing it (https://developer.blender.org/P755).
>
> This patch uses the Eulerian motion blur algorithm (Eulerian Motion Blur,
> 2007, Doyub Kim and Hyeong-Seok Ko,
> https://doyub.com/research/2007/emb/emb.pdf) since the Blender smoke
> simulator readily provides velocity data. I had difficulties figuring out
> how to work the sampling into the current kernel structure, so right now
> the advected points are calculated right before the voxel is interpolated.
> The point is advected 3 times (may be made customizable by the user) across
> the shutter speed and the densities are then averaged. Motion blur for the
> smoke can be enabled by checking the Motion Blur checkbox in the Render tab.
>

I think the place of the code is ok, it's easiest to do it just in time to
ensure we don't do it when shader evaluation doesn't need it. We can cache
the velocity lookup in ShaderData so it is performed only once if multiple
volume reads are done.

It's not clear to me why there is a kernel_data.cam.motion_samples (= 3)
used here. If I understand the paper correctly, formula (7) requires two
volume lookups to compute the velocity, and then there is a third volume
lookup to get the requested attribute itself.

Request and export of the velocity grid should be disabled if the Blender
object has motion blur disabled. This is done by checking if
mesh->motion_steps > 0.

In principle the volume bounds also need padding to account for the motion
blur, but if the velocity is not too big it's difficult to notice the
difference so we could ignore that for now.


> Quick example of a high vorticity smoke, with 3 samples, 0.5 shutter
> speed, centered on frame, and the default shutter curve:
>
> Without motion blur: https://i.imgur.com/YvYN6Gu.png
> With motion blur: https://i.imgur.com/A4nBLWv.png
>

Looks good so far.


> *To-dos next week*
>
> Unless there are any major issues or recommended changes for any of the
> previous tasks, the only things left to do are cleanup and review. Brecht
> has given me his previous work on implementing a native Volume primtive in
> Blender, which I will review and see if I can work on.
>

The most important thing is to finish what's there now, and fix any bugs
and issues. I'll do a code review of the branch soon.


>
> *Questions*
>
>    - Is there a better way to implement OpenVDB import interface compared
>    to how it currently is?
>
> Not sure off hand, will look into it for the code review.

>
>    - Should I provide an option for the users to choose storage options
>    for volume texture? (Currently defaults to sparse grid) If yes, where would
>    I put it?
>
> I think we can always use sparse grids, if it's significantly slower in
some cases we can look at how to optimize it.

>
>    - Any comments on the motion blur patch?
>
> See above.

Regards,
Brecht.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.blender.org/pipermail/soc-2018-dev/attachments/20180723/334fbbe9/attachment.html>