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

[Brecht Van Lommel]

If you like to work on adding a proper volume object datablock to Blender,
here's the skeleton code for it that I referred to on IRC:
https://developer.blender.org/diffusion/B/browse/temp-volume-object/

On Sun, Jul 15, 2018 at 7:57 PM Brecht Van Lommel <brechtvanlommel at gmail.com>
wrote:

> 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/20180717/8f88d0f0/attachment.html>