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

[Brecht Van Lommel]

Hi Geraldine,

Please do not expose OpenVDB as a shader node, and stick to the existing
Cycles design. VDB volumes should be treated as geometry with attributes,
not as an image texture. For performance reasons (empty space skipping,
motion blur, ..) and integration with the future volume object this is not
the direction we want to go in.

If there are issue with the previous approach you were working on, I can
help to solve them.

Thanks,
Brecht.


On Sun, Jul 15, 2018 at 7:23 PM Geraldine Chua <chua.gsk at gmail.com> wrote:

> ​Sorry for the late report everyone, as I was hoping to be able to finish
> up the node code before this weekend was over.
>
> This week, I worked on the following tasks:
>
>    - General code clean up and bug fixing with both sparse tiles and
>    OpenVDB.
>    - Edit Cycles stand-alone build files to support OpenVDB.
>    - Move import interface into a dedicated Cycles node.
>
> In order to have a more solid integration of OpenVDB importing in Cycles,
> it would be better to not need to rely on Blender's Smoke Domain Settings.
> Cycles is a heavily node-based program, so I think creating a node for
> OpenVDB import would work well with the current architecture. The current
> state of the node:
>
>
> ​
> (Fields are filepath, grid, interpolation, and extension. Output is color,
> vector, and fac)
>
> The idea behind the OpenVDB Import node is that it will function similar
> to the Attribute node, where it will add an image using the vdb file and
> grid name provided (saved as a texture), and if the grid name is a valid
> attribute, it will also add the attribute to the object. This in theory
> means it can substitute for a voxel attribute node. The object will then be
> treated as the domain / bounding box of the vdb texture.
>
> The node structure is still tentative, as there may be better ways of
> implementing it since I am not entirely familiar with the node
> architecture. Some simple alternatives:
>
>    - Base it on the Principled Volume Node instead of Attribute, which
>    will allow being able to load all grids in one node instead of having one
>    node per grid per file. This will require forcing specific grid names,
>    which may be too inflexible.
>    - Accept an Attribute Node as an input instead of having a grid field
>    (not too important of a distinction I think).
>
> Regardless of implementation details, the image slot number and the
> attribute must be passed along to the object.
>
> *To-dos next week*
>
>    - Finish node implementation.
>    - Try to connect the current VDB previewer to the new node.
>    - Finish testing Cycles stand-alone.
>    - Figure out the strange memory measurement issue with OpenVDB grids.
>
> Hopefully, all of these could be done before the end of the week, in which
> case I will move on to my next task.
>
> *Questions*
>
> What possible improvements / changes should be done with the node?
>
> --
> 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/20180715/cf8f644d/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 20180716010944.png
Type: image/png
Size: 10363 bytes
Desc: not available
URL: <http://lists.blender.org/pipermail/soc-2018-dev/attachments/20180715/cf8f644d/attachment-0001.png>