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

[Geraldine Chua]

Hi Brecht,

I originally thought to work on the Blender-side because several Cycles
files that included the OpenVDB library would not compile. I have since
moved most of the code into their own dedicated files (still in Cycles) and
that seemed to solve the compiling / linking issue. The only part that
still cannot compile is kernel_cpu_image.h when using the OpenVDB accessors
and interpolators, so for now I just set it to force convert all grids to
textures.

There still needs to be some work on Blender though, to handle
transformations and positioning at least. Right now, my build can already
read and render OpenVDB smokes, but the scaling and transformation is very
off so that needs to be worked on.

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

Thanks for the tip! Then the code for CPU interpolation can just be reused
with just the lookups substituted.

Best regards,
Geraldine


On Mon, Jul 2, 2018 at 2:47 AM, Brecht Van Lommel <brechtvanlommel at gmail.com
> wrote:

> 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
>>
>
> --
> 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/20180702/9f8639ae/attachment.html>