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

[Geraldine Chua]

*OpenVDB Importing in Cycles*

This week I worked mostly on integrating OpenVDB into Cycles with some
limited work on the Blender side. The current state of Cycles is that it
should in theory now be able to successfully load float/vec3s grids from a
provided OpenVDB file, and in the case of CPU rendering, use the library's
optimized interpolators.

However, thanks to incompatibility of OpenVDB in OpenCL and CUDA, when most
Cycles code must be compatible with both as well as C++, direct use of the
OpenVDB library (outside of some of the device and kernel code, which are
partially implemented per device) will cause compilation errors. Luckily,
kernel sampling is unaffected, but file loading, grid modification (e.g.
transforms), and conversion of grids to Blender textures (for GPU
rendering) must all happen in Blender rather than Cycles. Thus, it seems
like the bulk of the work of OpenVDB integration will be in Blender.

In the case of CPU rendering, to solve the incompatibility, I set all
OpenVDB objects required for interpolation (probably just the grid
accessors) as void pointers before transferring to Cycles, then recast them
back appropriately in the kernel. There may be a better solution than this.

*OpenVDB Smoke Importing in Blender*

Creating a dedicated Volume primitive based on OpenVDB may take significant
amounts of time, so it may be better to create a simpler but immediately
functional OpenVDB smoke importer. Here I will outline some considerations
for a basic but hopefully feasible importer. For now I will only try to
consider the case of rendering an individual frame. A lot of work in terms
of viewport display, transforms, importing and manipulating OpenVDB files
has already been done by Luca and Kevin, and I will try to copy / reuse as
much code as possible.

   - Modelled on the OpenVDB pointcache, the importer should create a new
   Smoke Domain object and render the data in the viewport similar to how
   baked smoke is displayed.
   - Since editing is outside the scope of this project, all other modifier
   settings that affect how the smoke looks will be ignored or disabled.
   - On first import, the new domain should have attribute nodes
   automatically set based on the existence of grids with corresponding names
   in the file, e.g. if there is a grid with name beginning with "density",
   set a density attribute node. Grids that do not have a name corresponding
   to a smoke attribute are ignored. Files without any grids with attribute
   names will just result in an empty smoke domain.
   - Users can add / remove attribute nodes to add / remove grids.
   - Domain dimensions are set as the combined bounding boxes of the
   attribute grids. Object orientation can probably be done manually by the
   user using the usual transform tools.

Smoke Domains will have some new settings similar to this:

typedef struct OpenVDBSettings {
    char filepath[1024];

    FloatGrid::Ptr density_grid;
    FloatGrid::Ptr flame_grid;
    FloatGrid::Ptr temperature_grid;
    Vec3SGrid::Ptr color_grid;
    Vec3SGrid::Ptr velocity_grid;

    /* This is so that Cycles can get the accessors via
SmokeDomainSettings. */
    FloatGrid::ConstAccessor *density_accessor;
    FloatGrid::ConstAccessor *flame_accessor;
    FloatGrid::ConstAccessor *temperature_accessor;
    Vec3SGrid::ConstAccessor *color_accessor;
    Vec3SGrid::ConstAccessor *velocity_accessor;
} OpenVDBSettings;

typedef struct SmokeDomainSettings {
    // ...
    void *vdbs; // cast to OpenVDBSettings if openvdb exists
} SmokeDomainSettings;

Multiple color and velocity float grids can be changed to vec3s grids,
though I will have to see what how these attributes are generally saved.

There may be many other considerations not yet mentioned above.
Implementing OpenVDB smoke importing in Blender, integrating it with
Cycles, and testing it out with sample smoke .vdbs will probably take the
rest of next week. Please let me know if there are any issues with anything
mentioned above.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.blender.org/pipermail/soc-2018-dev/attachments/20180701/d6f59b5a/attachment.html>