Hi all. I have noticed a lot of commits by Kévin Dietrich to do with openvdb. It seems to be in a separate branch at the moment. Does anyone know if there are plans to bring this into the master, or has anyone compiled a working version.
Any info would be appreciated. I’ve googled, but they are all ancient posts.

cheers, Bogey.

Developer discussion here –

Please dont comment on it unless you have experience in programming.

I’m the developer. Of course there are plans to get this into master! But first let’s finish the work :wink: And there’s still a lot to be done. The branch was mainly setup because Lukas Toenne was starting to collaborate on it, for instance he improved the way the openvdb node works (basically, like the OSL script node, it gets its sockets based on the content of file that it’s given). And one other external developer wants to join in (he is somewhat known from the community already, but I’ll keep his identity secret for until he starts contributing :wink: ).Other than that, it starts to get usable :slight_smile: But I can’t really provide builds at the moment.


Will Open VDB in Blender be able to do all the fancy mesh stuff it can do in Houdini?

In that case, huge thanks to you and best of luck! :slight_smile:

Im curious if openVDB for Blender will have boolean operations?

In Houdini this is one of the most powerful modeling workflows ( similar to Meshfusion ). Voxel operations (e.g A-B) provide far more stable boolean behavior (rel to 3DCoat that excells at them). Ability to stack these operations in modifier/nodes for non destructive workflow makes it extremely powerful. I understand that performance might be a problem(mesh conversion part) however with smart design user experience can be made seamless.

Interested to hear thoughts on this matter. Tnx

Thanks for the replies. It looks like it will be in the “gooseberry” branch very soon. Good work.
Cant wait to try it.

For now, this project/branch is all about using VDB as a caching system for the smoke simulator, and implementing rendering of VDB volumes in Cycles.

This is similar to the particle mesher that I used to work on, basically such features are postponed for until there is node-based modifier system. Also I re-factored the mesher recently (I’m not giving up on this :slight_smile: ), the goal is to make it more generic, so we could re-use the code to e.g. mesh a smoke simulation.

Thanks to you too!

Most likely the answer is similar to the particle mesher case, we’ll need nodes. But yes I can envision a VDB boolean node. As a matter of fact, the particle mesher is using the difference operation at some point in the code.

Yes, Lukas merged the code in the Gooseberry branch today. As a tip, when doing (and exporting) a smoke simulation, try to ensure the voxels are uniform. It’s a bit tricky to do this in the current smoke simulation where you plug the resolution, so the easiest to achieve that is by using a domain with uniform scale (like a perfect cube). You can still use adaptive domain though. The reason is because the OpenVDB volume ray intersectors only work with uniform voxels. In short, uniform voxels mean that the empty space in the domain object will be skipped -> faster rendering. Ultimately, the smoke code will be changed/improved so uniformity will always be ensured :slight_smile:

Here’s a comparison between the current ray marching and the VDB version, this is not to be considered as a general case, as every simulation is different! Also I used a very small step size to see how performant lookup is.

Very nice! Also thanks for answering my question about the mesh stuff <3

Thank you KWD. Looks extremely promising!

wow! for the goosbery inclusion, does it mean the libs are in the svn now ?

Nice speedup on the compare. I usually avoid Cycles volumes due to the high render times but that much of a time savings would make me reconsider…

Amazing work!

I can’t wait to give this a try.

TBH I dont think Cycles volumes are usable yet lol

Yeah I’d only consider using volumes when its on the GPU.

That is a weird statement IMHO. Unusable for what? I’ve used Blender volumes rendered in Cycles for TV shows and feature films. Render times are not that bad, but sure I can’t wait for the OpenVDB goodness!

Render times are horrible compared to the rest of cycles :stuck_out_tongue:

I feel like I could explain what’s going on :slight_smile:

OpenVDB offers a hierarchical data structure for the storage and manipulation of sparse volumetric data. The structure itself derives from B+trees, as used in the NTFS file system, and is basically made of a root node, followed by two intermediate levels of nodes and finally leaf nodes, which contain the voxels. Typically leaves contain 8 x 8 x 8 voxels. So when we export a smoke simulation to VDB, we end up with this (same file as the screenshots I posted above, but for the low resolution version of it):

The blue boxes are the leaves. I didn’t enable drawing for the upper node levels.

When it comes to rendering, what happens is that VDB will check if for current ray an intersection with a leaf exists. If yes, we start ray marching at the beginning of the leaf, if no, we don’t do ray marching and continue the path tracing until we hit something else. Basically, it efficiently skips empty space.

Nice, its so cool to finally see a screen shot of what OpenVDB looks like in Blender :smiley:

I have been dreaming of having OpenVDB in Blender ever sense I read BlenderDiploms interview with Ken Museth on OpenVDB, its a great read for anyone curious.

Thank you so much KWD for all of your hard work :slight_smile:

First of all, really great job! I sincerely hope you manage to get it working on windows too and that it doesn’t stay only in a soon dying gooseberry branch.
While I agree that it would be nicer to have those modifiers in a node system (I think many of us are eagerly waiting for this) it’s not even officially in any developer plan. Particles nodes are in development for more than 3 years now and now there is nobody working on this officially at least. So I think it would be good to have a “classic version” of your mesher modifier (particle instance modifier already uses particles as input to create a mesh anyway, so yours is no exception). Even nicer would be to have the option for this modifier to give a mesh or an OpenVDB tree as output to make it more memory friendly in heavy cases with more than 20Million polygons)
Anyway, you do a really great job and the whole community will be really happy if we can also get to be able to work with it.