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

Geraldine Chua chua.gsk at gmail.com
Tue Jul 17 17:38:33 CEST 2018


Hi Brecht,

Thanks for posting the code! It's definitely a good base to work off for
Volume in Blender.

Best regards,
Geraldine

On Tue, Jul 17, 2018 at 7:47 AM, Brecht Van Lommel <
brechtvanlommel at gmail.com> wrote:

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


More information about the Soc-2018-dev mailing list