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

Geraldine Chua gsc97531 at gmail.com
Sat Mar 24 10:41:08 CET 2018

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,

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/OpenV
>>>> DBSmokeExport). 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
> _______________________________________________
> 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/f30be9f1/attachment.html>

More information about the Bf-cycles mailing list