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

[Brecht Van Lommel]

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/fo
>>> rum/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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.blender.org/pipermail/bf-cycles/attachments/20180323/29b4f9a8/attachment.html>