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

[Stefan Werner]

Hi!

> On 23. Jun 2018, at 10:01, Geraldine Chua <chua.gsk at gmail.com> wrote:
> 
> Having gone over Luca's importer, instead of generating a smoke domain from the OpenVDB file as I originally expected it would work, it creates a new OpenVDB modifier which allows manual grid assignment and orientation of the volume. Aside from basic transformations like scaling, OpenVDB volumes as far as I can tell cannot be modified. Depending on what the goal of the importer is (just importing vs editing), it may be better to convert OpenVDB files into Smoke modifiers instead.

It’s not too useful to import OpenVDB into the smoke simulator as is. The whole point of OpenVDB is that it’s a sparse data format, where the current smoke code isn’t. A 1000^3 grid can be just a few MB in a sparse format, but will inflate to tens of GBs of memory when expanded into the smoke code.

> A minor improvement that could be made is to attempt to auto-assign grids using default names e.g. set grid called "density" as the density grid of the object. As it currently stands, the OpenVDB object at first does not appear in the viewport since all grids are unset (I actually initially thought the function was not working because of this, so this is more for user-friendliness). Another improvement can be mass importing of vdbs since they are usually saved one frame per file.

Luca’s code was written for a very specific use case, it’s not expected to be ready for anyone.

> To-dos next week are further investigating / implementing the above mentioned changes / issues. I will also try to have a look into how other external files are imported and rendered in Blender such as Collada and Alembic as a reference point for what to do with the OpenVDB importer.


I agree with what Brecht wrote - just getting OpenVDB directly into Cycles would be a good start, the Blender side of the integration can be a second step. From having worked a bit with OpenVDB and Cycles, here are a few points from the top of my head:

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.

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!

-Stefan