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

Geraldine Chua gsc97531 at gmail.com
Fri Mar 23 13:04:40 CET 2018

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:

- 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,

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

More information about the Bf-cycles mailing list