I’m the developer. Of course there are plans to get this into master! But first let’s finish the work 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 ).Other than that, it starts to get usable But I can’t really provide builds at the moment.
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.
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 ), 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
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.
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!
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
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.
Hi KWD,
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.
Regards