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

Kévin Dietrich kevin.dietrich at mailoo.org
Thu Mar 22 16:25:55 CET 2018

Hi Geraldine, 

A few notes from me. First of all, better integration of OpenVDB is
indeed a goal in Blender, at least for interoperability with other
software. But ain't nobody got time fo' dat. 

The way I see OpenVDB implemented in Cycles is something like what
jehuty did. My attempt was a bit complicated, as it required
implementing OpenVDB's ray tracing utilities in Cycles' kernel. However,
we recently did an optimisation of volume rendering that somewhat mimics
the OpenVDB data structure to skip empty space in the volume, so I would
stay away from using OpenVDB's ray tracing utilities in Cycles like I
tried to do. 

Jehuty's work was creating a texture system, like OIIO's, where OpenVDB
files would be opened and read on demand based on ray intersection and
shader evaluation. I think this should be persued as it doesn't require
messing with BVH traversal code or ray marching (like my attempt). His
implementation would only work in OSL and implementation in SVM would be
necessary, and appears to be the trickiest part. 

For an SVM implementation of Jehuty's work, we would need to pass the
filenames of the VDB files as well as the grid names used to the kernel
for each shader, so special attention needs to be taken here. I guess we
can pass the hash of the filenames to the kernel, instead of a string,
and maybe this can be put in the attribute node somehow. This would be
CPU only though. For GPU, the only solution would be to copy the OpenVDB
grid data to a Cycles 3D texture. 

The particle mesher modifier is not to be finished as long as the
current modifier system is in place, so I would drop the idea of working
on that. Also, I wouldn't bother implementing other OpenVDB features
without a volume object in place first. 

Finishing (or rewriting) my implementation of the volume object
primitive in Blender and working on implementing OpenVDB in Cycles at
the same time might be too much for a GSOC. But then it depends on how
we approach the Cycles part: texture system vs reading as 3D texture,
where the latter is the easiest and would allow more time to work on the
volume primitive. 

That's it from me at the moment, 


Le 2018-03-22 15:05, Gg Cc a écrit :

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

More information about the Bf-cycles mailing list