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

Geraldine Chua chua.gsk at gmail.com
Wed Jun 27 21:00:56 CEST 2018


Hi everyone, sorry for not asking around too much about this task first, as
I admittedly don't know too much about the background.

I originally interpreted the task as converting OpenVDB grids into dense
Cycles volumes instead of changing Cycles to store volumes in OpenVDB
format. If what is expected is the former, we can trivially load the
OpenVDB file, retrieve and transform the grids, then generate a dense
texture from it, which now that I've typed it out looks pretty
inefficient...

A quick naive implementation of the latter for native volumes would
probably involve loading the voxel values into OpenVDB grids, saving the
grid pointer in TextureInfo.data, and in the kernel use the provided
OpenVDB methods for interpolation (probably by creating
kernel_tex_volume_interp_3d() which calls the OpenVDB interpolation methods
instead + editing whichever files call kernel_tex_image_interp_3d() to use
OpenVDB's world to index space converters). Extending this to imported
OpenVDB grids would be very easy as well.

For the GSoC project I would mainly like to see native Cycles support for
> rendering OpenVDB volumes. Even if the Blender side is simply a string
> property on meshes to specify the OpenVDB filepath, and doing everything
> else in Cycles.
>

Thank you for clarifying :) Luca's code is very useful though for providing
the UI for importing + positioning and transforming the imported volume
(and it let me have an easy way to put the volume in front of the camera
for Cycles testing :P). If all we need to worry about right now is the
Cycles side, all the Blender side needs to do is pass the file path and the
(linear) transformation matrix of each grid, then let Cycles load the grids
itself (although this isn't very efficient since the file gets loaded twice
and the first time, the volume is basically converted into a dense array).
May I ask how do you think would be a good way of implementing Blender-side
importing?

Users should not need to enable grids in the UI. Cycles (and later the
> Blender viewport) can request attributes based on the shader graph, and
> only load the relevant ones in that case. For example for the smoke object
> in Cycles this is done create_mesh_volume_attributes.
>

Unless the volume is imported as a Smoke object, I don't think the
attribute nodes can be assigned. Maybe for now we can just check if a grid
with a corresponding name for each attribute exists and load it if it does?
How this will be handled depends on the how the importing on the Blender
side will be implemented.

The ideal solution is to have a new volume object type in Blender, and any
> other implementation will be a placeholder.
>

It would be nice to have a Volume primitive working for smoke simulation at
the very least. Broadly, my interpretation of this task is converting
structs / classes in Blender that currently use large but sparsely
populated arrays to use OpenVDB trees instead. Based on an initial look
through, voxel values for smoke are stored in FLUID_3D (?), but it looks
like an external library so I don't think this is the struct to convert?

First, if we want this to work on the GPU, you’d need to import OpenVDB
> data into your sparse 3D texture data structures. The OpenVDB library
> itself has lookup calls, but those won’t be available in OpenCL or CUDA.
>

I'm really surprised that OpenVDB is not officially compatible with GPU
rendering. An easy patch is as you say, converting trees into arrays. From
a quick google search there are some libraries for OpenVDB compatibility
with OpenCL (https://github.com/matthew-reid/Graphtane) and CUDA (
https://developer.nvidia.com/gvdb) though I haven't looked too deeply into
these.

Coordinates in OpenVDB are a bit tricky and unfortunately, some programs
> odd conventions. If you skim Luca’s code, you can see that he has
> workarounds based on the metadata of the file.  The grids in a file also
> don’t need to have the same bounding box. When mapping normalized
> coordinates to VDB’s index space, make sure your conversion is consistent
> across all grids.
>
> Also, I recently ‘discovered’ that a VDB file can happily store several
> grids with the same name. Be careful when referring to grid by their name
> instead of their index. The name iterator of OpenVDB will append numbers to
> the names, but if you query a grid’s name directly, those numbers are
> omitted!
>

Thanks for the heads up on these issues :) I will try to look into them
some more. Importing from other programs without very strict standards for
the file type is always bound to be a little messy.

Best regards,
Geraldine

On Wed, Jun 27, 2018 at 1:21 AM, Brecht Van Lommel <
brechtvanlommel at gmail.com> wrote:

> On Tue, Jun 26, 2018 at 4:42 PM Stefan Werner <stewreo at gmail.com> wrote:
>
>> Also, I recently ‘discovered’ that a VDB file can happily store several
>> grids with the same name. Be careful when referring to grid by their name
>> instead of their index. The name iterator of OpenVDB will append numbers to
>> the names, but if you query a grid’s name directly, those numbers are
>> omitted!
>>
>
> If I remember correctly this can happen when writing clustered grids from
> Houdini?
> http://www.sidefx.com/docs/houdini/pyro/clustering.html
>
> The correct way to interpret those would be to merge grids with the same
> name, or at least render them as if they were merged. I wouldn't expect us
> to support this immediately though, it's a bit of an advanced case which
> can be worked around by the user. There's also things like perspective
> grids for camera adaptive resolution, but we should also ignore that for
> now.
>
>
> --
> Soc-2018-dev mailing list
> Soc-2018-dev at blender.org
> https://lists.blender.org/mailman/listinfo/soc-2018-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.blender.org/pipermail/soc-2018-dev/attachments/20180628/04160c7b/attachment.html>


More information about the Soc-2018-dev mailing list