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

[Brecht Van Lommel]

Hi,

For the GSoC project I would mainly like to see native Cycles support for
rendering OpenVDB volumes. Even if the Blender side is simply a string
property on meshes to specify the OpenVDB filepath, and doing everything
else in Cycles.

The ideal solution is to have a new volume object type in Blender, and any
other implementation will be a placeholder. It's not really that useful to
spend time to try to make an OpenVDB modifier on meshes work well if it's
temporary. We probably would not accept an implementation like that in
Blender releases.

Users should not need to enable grids in the UI. Cycles (and later the
Blender viewport) can request attributes based on the shader graph, and
only load the relevant ones in that case. For example for the smoke object
in Cycles this is done create_mesh_volume_attributes.

Regards,
Brecht.




On Sat, Jun 23, 2018 at 10:01 AM Geraldine Chua <chua.gsk at gmail.com> wrote:

> This week was mostly spent going over the OpenVDB pointcache code and Luca
> Rood's work with on creating an OpenVDB importer here (
> https://github.com/tangent-animation/blender278/commits/openvdb_import).
> As I was unable to build Tangent Animation's Blender fork, I just went
> ahead and ported all relevant code over to my branch.
>
> 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.
>
> 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.
>
> For some .vdb files such as the bunny sample files, Blender would crash
> upon attempting to assign a grid (although that may be due to insufficient
> specs on my computer...). It also crashes occasionally when attempting to
> set the wrong grid e.g. set "density" grid to color. I am still tracing the
> cause and location of the crashes, as there is no error message printed
> besides "Killed" and no error log created. Probably this is because the
> error happens in the OpenVDB library.
>
> While the OpenVDB object shows perfectly fine on the viewport, only the
> domain appears when rendering both with Blender Internal and Cycles. Unless
> I have missed something, this is because the object is not accounted for in
> Cycles yet, so I will have a further look into that.
>
> 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.
>
> For questions, I would just like to know whether or not we want editable
> OpenVDB volumes and if Luca's approach with the new modifier is fine.
> --
> 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/20180625/0bc0b50b/attachment-0001.html>