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

[Geraldine Chua]

​(Resending this report with links to the photos instead of embedded photos)

This week, I have finished the foundation work needed to get OpenVDB
importing working in Cycles, as well as a very simple importer for the
Blender UI. The importer now works under specific cases.

Broadly, Cycles expects an OpenVDB file to be associated with a Smoke
Domain passed to it from Blender. This Domain will be treated as the
bounding box of the vdb volume, and the volume will be scaled and
positioned appropriately. If a valid .vdb file is recieved from the Smoke
Domain, Cycles will either convert the grid into a dense texture, or save
the vdb grid(s) directly.

https://i.imgur.com/7TvPDWV.png
*New OpenVDB Import checkbox*

https://i.imgur.com/zM0Gbxt.png
​*When selected, all other settings are disabled. Can't edit external
.vdb's yet!*

For the Blender UI of the importer, in order to be able to visualize the
volume, a lot of the OpenVDB pointcache code was reused. An interesting
quirk of this is that Blender can actually pass the cached smoke data as a
texture to Cycles, rather than have Cycles load and convert the grid
itself, since the same grid to dense array conversion code is used by both
Blender and Cycles. Regardless, Cycles can do the conversion even without
the cached smoke from Blender.

*Direct Interpolation on OpenVDB Grids*

In order to be able to store OpenVDB grids rather than the usual textures,
I created a wrapper class around *device_memory* called *device_openvdb*.
*device_openvdb* has two new members: the grid pointer and a const accessor
to the grid. Everything else is kept roughly the same, and a pointer to the
grid can then in theory be saved as a *TextureInfo*.

However, for whatever reason, the vdb grid texture is not loaded / cannot
be found in the kernel. The ShaderData of the vdb texture lacks a valid
object ID, and if you try to force it past the check anyway, an invalid
texture is returned (my test returned a TextureInfo with all members set to
0, though it may just be random data). I am still trying to figure out what
may be the root cause of this.

*Other Notes*

https://i.imgur.com/HaMQTCi.png
​
Rendered smoke density is significantly lighter than expected, compared to
the viewport preview, or comparison images from other engines.

https://i.imgur.com/Mq9XweT.png
https://i.imgur.com/jju5R4k.png
https://i.imgur.com/UZaZ9g4.png
​
For some reason, if the smoke domain is too large, the volume cannot be
seen. This doesn't seem to affect the Cycles render though, so it's not too
much of a priority to fix.

*To-do next week*

   - Figure out the problem behind saving OpenVDB grids as textures.
   - Further testing, with .vdbs from other common engines e.g. Houdini,
   with color / velocity grids, etc.
   - Fix the light density issue.
   - Check compatibility with Cycles stand-alone.

*Questions*

Well, just one question... I've really been stumped on why the ShaderData /
TextureInfo for OpenVDB textures is invalid. Strictly speaking, the only
difference between saving normal textures and the OpenVDB grid texture is
the TextureInfo.data now points to the const accessor of the grid instead
of a dense array. The only obvious difference in ShaderData from normal
volume textures is that always ShaderData.prim = -1 and ShaderData.object =
0. Does anyone know what may possibly cause ShaderData to still hold its
default values?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.blender.org/pipermail/soc-2018-dev/attachments/20180707/db1b2db8/attachment.html>