Are Open VDBs Rhinos new geometry type? vdb to native machine tool paths

Hello McNeel

After attending the Rhino event hosted in Poland a few months ago @MathiasFuchs_McN gave a short overview on developments for GH2, answering some questions relating to the new rhino8 function being applied to GH2 ie: shrinkwrap.

In the coffee break we both were speaking about shrinkwrap the function and personally I had some inclinations that it was using some sort of signed distance function to make it work also that the openvdbs.dll is in rhino version 8.

With companies like Blender, houdini, Dassault and Autodesk all supporting I/O for open vdbs and interesting uses of way you can manipulatie designs and simulations using this geo type, rhino is tailing behind in this respect. I was wondering if Shrinkwrap the start of a whole new set of tools that mcneel will introduce like the sub-d modeling in previous versions.

I know of plugins such as Dendro/axolotl/jellyfish but these reach their limits pretty quickly, a good example of this is the version of vdbs that dendro is on is way behind the lastest. Automatically missing out on functionality and having to wait for plugin devs to update.

This I feel would be a great addition to Rhino, especially how shrink wrap is marketed as a tool to repair kinda for 3d printing.
.3mf consortium are pushing the boundaries with integrating this into their file format and seeing export vdbs in 3mf in rhino would be great.
I tend to use my own code to make Openvdbs in rhino create native tool paths like gcode (FDM) sli or cli (SLS) and image stacks (DLP) on vdb 11. Happily share this with Mcneel (as mentioned to mathias)
Companies like Ntop / Hyperganic have seen and upsurge in interest in the recent years, really i think this is based on the naivety of the market, most CAD engineers not knowing of these operations or being stunted on how to manipulate back into other geo types that they are used to eg: vdbs to nurbs. Shifting between softwares to make this happen is always annoying.
Democratizing these operations for users who don’t want to fiddle around in gh or want to get close to the kernel and in combination with rhino legacy tools could expand the design space for so many people.

… so are there plans for this in McNeel?

3 Likes

in regards to dendro, i recently switched the code to use vcpkg. this should allow people to build with the latest versions of openvdb quite easily. if you are comfortable coding than it would allow you “inject” your own code into the plug-in. i know this was not the point of your post but thought i would mention that.

years ago, i had put some thought into tweaking the design of the API to allow users the ability to access more openvdb functions/classes within the c# script component. i thought it would be great to allow you to create custom workflows using openvdb functions. i gave up on it because it just seemed like there are too many use cases to make something work. that said, you can call current dendro functions within the c# component, but you are limited to the functions in the dendro c# class.

1 Like

Peter, thank you for your post. I agree 100%.

I think a better intergration for OpenVDB would very valuable for many workflows in Rhino and Grasshopper. Ideally, there would be a direct way to render OpenVDB files. I am not sure if this is possible at the moment with Rhino 8.

Please have a look at my comment here:

And the following thread:

Especially in the growing field of digital fabrication / additive manufacturing / 3D printing, this would be a super valueable feature and open up many new possibilities.

1 Like

Would you be willing to share your code to directly create sli/cli files ?