I’m developing a custom Grasshopper C# plugin and exploring the Dendro volumetric meshing library (by Ryan Ewing) for robust mesh union / repair.
From what I understand, Dendro sits on top of OpenVDB (sparse voxel / SDF engine widely used in film/VFX), with a native C++ layer (DendroAPI) and a managed C# layer (Dendro.dll). On Windows, building this stack seems to require compiling OpenVDB and its dependencies (TBB, Boost, Blosc, etc.), which is a fairly heavy setup.
My questions:
Has anyone here successfully built Dendro (Dendro.dll) on Windows for use in a Grasshopper C# plugin?
In practice, how do plugin developers handle this dependency – build OpenVDB once internally, integrate Dendro source directly, or use another approach?
Are there any forum threads or docs describing real-world workflows around Dendro in Rhino/Grasshopper?
I’m not asking for redistributed binaries – just trying to understand what others have done in practice before committing to this path.
There is no real difficulties using Dendro inside a C#, I use it like that and it is faster than using Component from Dendro as the “vizualisation via mesh” is taking time.
Thanks sir for the replies so far — this already clarified a lot.
To make sure I understand the intended workflow correctly, I’d like to confirm a few advanced points:
When referencing Dendro from a custom Grasshopper C# plugin, is it considered safe and supported to reference the DendroGH .gha assembly directly (as a .NET dependency), rather than building Dendro/OpenVDB from source?
Are there any stability, versioning, or deployment caveats when another plugin depends on DendroGH at runtime (e.g. plugin load order, Grasshopper updates, Rhino version changes)?
Is Dendro’s API inside DendroGH considered stable enough for programmatic use (Volume / Boolean ops), or is it primarily intended for internal use by the GH components?
From a best-practice perspective, is this approach (depending on DendroGH) what experienced GH plugin developers actually do in production, or are there cases where building Dendro independently is preferred?
I’m not asking for redistributed binaries — just trying to align with the intended and proven workflow before moving further.
Safe I don’t know, you can use both ways, but Ryein @ryein has done a wonderful job so I prefer to use it rather than redevelop an interface.
2 ) Yes I think you must use Grasshopper/rhino version superior or equal.
Dendro/OpenVdB is the best tool I know for mesh boolean. Rhino Team has done a wonderful job with ShrinkWrap but it is limited to Boolean Union and Rhino >=8.
I think there are some forks that are a bit faster (no meshing for vizualization)
From my experience doing tools for companies that 3d print I can say that reliable tools are
Thanks a lot @laurent_delrieu for the clarification, really helpful.
Just to be clear: my intention is not to use Dendro components on the Grasshopper canvas, but to reference DendroGH as a compiled assembly and call the Dendro API directly from my own C# plugin. This seems like the right balance between reliability and avoiding rebuilding the OpenVDB stack.
I’ll also make sure to handle Rhino/Grasshopper version dependencies properly. Thanks again for sharing your production experience.
I’m developing a Grasshopper C# plugin and want to call the API of another GH plugin (Dendro), not use its canvas components.
Visual Studio does not allow adding a .gha file directly as a reference. What is the recommended way to depend on another Grasshopper plugin programmatically at compile time?
sorry to have mislead you. I didn’t inspect what I did. Indeed I took the Github repository of dendro and (surely) recompile it in order to have the dll.
I believe the Dendro dll is in the download folder when you get the component, no?
The heavy lifting is done by the dll. It handles all the mapping of the pinvokes to idisposable classes. Hats off to Ryein for developing such a useful tool.
I’ve done I think a very similar thing to what you’ve asked. I have the dll in bin, and I have the classes in my plugin.. I’m more or less forking it, integrating the source directly. Then in whatever logic you want you can reference the classes and methods of Dendro. For example I have a component where the input is curves and the output is a mesh. I do various voxel operations behind the scenes so the settings can never change, and some other logic can get integrated for diameters, etc. It’s more straightforward than you might think. Let me know if you are still looking for help and I can give some more info.
