[Bf-cycles] [GSoC 2018] Feasibility of greater integration of OpenVDB into Cycles

Sat Mar 24 13:05:52 CET 2018

For Cycles at least export wasn't part of the proposed ideas. The main
thing is rendering VDB volumes, for which we only need to read the file.
For a volume object it would be important, but that's another project.

Tiled storage has not been implemented yet. D3038 creates a bounding mesh
so that empty parts of the grid are skipped when rendering. However we
still store the dense 3D grid which is not memory efficient. Instead what
we want is a sparse grid, that is split into tiles of e.g. 8x8x8 voxels.
And if any such tile would have values that are all zero, we would not
store that tile.

On Sat, Mar 24, 2018, 10:41 Geraldine Chua <gsc97531 at gmail.com> wrote:

> Hi Brecht,
>
> I am curious, why is export to OpenVDB not a feature that you would want?
> I am just interested to know.
>
> Thank you for the advice on how to handle voxel texturing, I will try to
> read into the Attribute node codebase for details.
>
> In regards to tiling of volumes, it seems like Kévin has already created
> an solution here: https://developer.blender.org/D3038. Or am I
> misunderstanding the task instruction? If it has already been done, I will
> focus on the other tasks instead.
>
> Best regards,
> Geraldine
>
>
> On Sat, Mar 24, 2018 at 1:17 AM, Brecht Van Lommel <
> brechtvanlommel at pandora.be> wrote:
>
>> Only reading / import of OpenVDB files would be required for Cycles, no
>> export.
>>
>> We don't need a volume texture node, OpenVDB grids can be available as
>> voxel grids as they are now. What we could have is a Volume Attribute node
>> that is easier to use than the Attribute node, with a position or
>> displacement input, and a menu for picking available volume grids. Keeping
>> them as attributes is a better fit for an eventual volume object, and for
>> optimizations like empty space skipping.
>>
>> Regards,
>> Brecht.
>>
>>
>> On Fri, Mar 23, 2018 at 1:04 PM, Geraldine Chua <gsc97531 at gmail.com>
>> wrote:
>>
>>> Hi Kévin and Brecht,
>>>
>>> Thanks a lot for your feedback! I am in the process of drafting the
>>> proposal and reseraching the Cycles architecture, previous work with
>>> Volumes, and related literature. I will have to lower my naive ambitions
>>> quite a bit. I have structured my GSoC task list as something similiar to
>>> the below list:
>>>
>>> Required:
>>> - Tiling support for Volumes in Cycles kernel (so Cycles can better
>>> support volumes in general)
>>> - Import/export of OpenVDB files to/from Cycles 3D image
>>>
>>> Optional (most likely only do 1 of these):
>>> - Textures for volumes (basically Jehuty's main project)
>>> - Volume motion blur
>>>
>>> (so it has now almost returned to the proposed idea list :P)
>>>
>>> On your advice, I do not think I should pursue Volume Primitives since,
>>> as has been said, volume rendering is itself not fully developed yet, and
>>> perhaps other rendering tasks would be better use of any remaining time
>>> e.g. motion blur. I will try to post the draft of my proposal by tomorrow
>>> or Sunday.
>>>
>>> Best regards,
>>> Geraldine
>>>
>>>
>>> On Fri, Mar 23, 2018 at 12:42 AM, Brecht Van Lommel <
>>> brechtvanlommel at pandora.be> wrote:
>>>
>>>> Hi Geraldine,
>>>>
>>>> Blender indeed supports OpenVDB as a file format for baking smoke
>>>> simulations, but nothing else.
>>>>
>>>> We indeed want to have an OpenVDB backed volume object in Blender. But
>>>> it's a big project that touches a lot of areas, and we prefer projects that
>>>> are well defined and can be finished within the GSoC timeframe. We
>>>> shouldn't have a Blender version that supports volume objects but has no
>>>> way to render them. So I think it makes most sense to add Cycles rendering
>>>> support first, because it's pretty much a required step in adding a volume
>>>> object.
>>>>
>>>> Cycles tiled 3D image storage is important to support VDB files
>>>> properly, since being able to store sparse volumes is a big feature of
>>>> OpenVDB. Basic reading of OpenVDB files into 3D images is a relatively
>>>> small project. These projects can potentially be finished much faster than
>>>> the GSoC timeframe, it depends on the experience of the student. Starting a
>>>> Blender volume object as an optional third step in the remaining time makes
>>>> sense to me.
>>>>
>>>> Regards,
>>>> Brecht.
>>>>
>>>>
>>>> On Thu, Mar 22, 2018 at 3:05 PM, Gg Cc <gsc97531 at gmail.com> wrote:
>>>>
>>>>> Hello everyone!
>>>>>
>>>>> I am Geraldine Chua, a prospective GSoC candidate, and although I am a
>>>>> little late to the game, I would really love to be able to help work on
>>>>> Cycles over the course of this summer :).
>>>>> In regards to my project, I would like to enquire about the
>>>>> feasibility of fully integrating OpenVDB into Cycles. One of the tasks
>>>>> mentioned under the Volume Rendering potential ideas list is the "Direct
>>>>> reading of OpenVDB files as a Cycles 3D image, to render volumes generated
>>>>> by other software."
>>>>>
>>>>> Right now, it seems like Blender can already read and write (but not
>>>>> edit?) smoke volumes (but not other volumes?) as OpenVDB files (
>>>>> https://wiki.blender.org/index.php/User:Kevindietrich/OpenVDBSmokeExport).
>>>>> There are also various other integrations done over the years such as one
>>>>> attempted back in GSoC 2013 (although I cannot tell how far Jehuty managed
>>>>> to finish) and the rest of Kevin Dietrich's work.
>>>>>
>>>>> However, from this forum post (
>>>>> https://blenderartists.org/forum/showthread.php?433900), as well as a
>>>>> few others, it seems like a quite a few people want much greater support
>>>>> for OpenVDB. Perhaps instead of doing these 3 unrelated (although all
>>>>> interesting!) tasks for Volume Rendering, I could focus on extending or
>>>>> even finishing the OpenVDB integration started by Kevin Dietrich. This
>>>>> would be a much more focused project, and I think one fully-fledged
>>>>> project, as opposed to a few spread out tasks, might be better for the
>>>>> community who will get a fully-fledged new tool.
>>>>>
>>>>> Some ideas of tasks that can be done:
>>>>>
>>>>>  - Revisit and complete Kevin Dietrich's unfinished projects such as
>>>>> the implementation of a Volume Object Primitive or the Particle Mesher
>>>>> Modifier (https://wiki.blender.org/index.php/User:Kevindietrich)
>>>>>
>>>>>  - Integration of other features of OpenVDB such as conversion tools,
>>>>> transforms, etc. (http://www.openvdb.org/about/)
>>>>>
>>>>>  - Refactoring of current Volumes functions in Cycles to work with the
>>>>> OpenVDB format
>>>>>
>>>>> I would like to ask from those who are much more experienced than me
>>>>> in volumes development:
>>>>>
>>>>> 1. Does this project contradict any current plans or goals set for the
>>>>> Blender architecture? Is OpenVDB integration a goal of Blender's?
>>>>>
>>>>> 2. Is this a project that is of actual benefit to the Blender
>>>>> community? Or is the original requirement of only OpenVDB import/export
>>>>> what is actually needed and  would you rather I focus on trying to also
>>>>> accomplish the other 2 volume rendering tasks?
>>>>>
>>>>> 3. Would you estimate that this project is feasible, i.e. the most
>>>>> useful features can be implemented in 12 weeks?
>>>>>
>>>>> Thank you for taking the time to read my questions and I hope you can
>>>>> provide some of your insights and feedback on this proposal :). I know that
>>>>> the Blender development community is a quite busy right now with the
>>>>> upcoming Code Quest, so thank you for taking the time to help me on this.
>>>>>
>>>>> Best regards,
>>>>> Geraldine Chua
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Bf-cycles mailing list
>>>>> Bf-cycles at blender.org
>>>>> https://lists.blender.org/mailman/listinfo/bf-cycles
>>>>>
>>>>>
>>>>
>>>> _______________________________________________
>>>> Bf-cycles mailing list
>>>> Bf-cycles at blender.org
>>>> https://lists.blender.org/mailman/listinfo/bf-cycles
>>>>
>>>>
>>>
>>> _______________________________________________
>>> Bf-cycles mailing list
>>> Bf-cycles at blender.org
>>> https://lists.blender.org/mailman/listinfo/bf-cycles
>>>
>>>
>>
>> _______________________________________________
>> Bf-cycles mailing list
>> Bf-cycles at blender.org
>> https://lists.blender.org/mailman/listinfo/bf-cycles
>>
>>
> _______________________________________________
> Bf-cycles mailing list
> Bf-cycles at blender.org
> https://lists.blender.org/mailman/listinfo/bf-cycles
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.blender.org/pipermail/bf-cycles/attachments/20180324/1365d77c/attachment.html>