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

[Brecht Van Lommel]

Hi,

On Wed, Jun 27, 2018 at 9:01 PM Geraldine Chua <chua.gsk at gmail.com> wrote:

> 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?
>

It's definitely useful to see it in the Blender viewport, it's just a
matter of keeping the GSoC project within a reasonable scope. The proper
way to implement it in Blender would be have a native volume object type.
Ideally we would be able to share buffers with Blender. The Blender
implementation would just use OpenVDB data structures internally, so Cycles
could get direct access to them and all the same code could be reused.

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.
>

I think it could work. Smoke objects are really just Mesh in Blender as
well at the moment. So if we would detect an OpenVDB filepath to be set, we
can treat it similar to being a smoke object, except that we read (sparse)
grids from a VDB file instead of the smoke domain.

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?
>

Probably it would be easiest to start from scratch instead of converting
existing data structures, and then convert some parts to use it. The
Blender volume object should use OpenVDB data structures internally, no
need to define our own custom sparse grid structure. That way we can use
all the useful operations implemented in the OpenVDB library and make them
available as modifiers with little effort.

Converting the smoke simulator to use sparse grids would be great, but
that's a big job too. It could be done later.


> 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.
>

Right,  it would be nice if we could reuse an existing library, but in the
end it's best to have our own implementation. There isn't one library that
we can use on all platforms, and for maintenance it's important we have a
single code based that works on C++ / OpenCL / CUDA and whatever other
backends we added in the future.

Converting OpenVDB files into the sparse data structures you implemented in
the first parse of the GSoC project should be a good fit.

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