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

[Brecht Van Lommel]

Hi,

I'm not sure if I didn't explain it clearly in the previous discussions, or
if part of this mail was written before it.

But the idea for this GSoC project was to integrate OpenVDB in _Cycles_,
not in Blender as a whole. So I really want the primary thing you implement
to be code in Cycles to convert OpenVDB files directly to the sparse grid
data structure. We don't need intermediate data structures in Blender for
this, just a simple robust implementation in Cycles.

Also note the OpenVDB interpolators are not optimized, in fact they are
quite slow. We can do much better with our own implementation, we should
not be using the OpenVDB code for interpolation.

Regards,
Brecht.



On Sat, Jun 30, 2018 at 6:07 PM Geraldine Chua <chua.gsk at gmail.com> wrote:

> *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.
>
> --
> 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/20180701/55b26fc6/attachment.html>