The one part of the masks I don’t like is that you have to define geometry to build them. If there is a lot of mask geometry, it just adds more to the overall computation time.
The OpenVDB library requires a volume to define a mask, so the easiest way to get the feature added into the plugin was to piggyback how I was already creating volumes. I’d be curious to get everyone’s thoughts on use cases because there are other ways to generate volume data other than by points or meshes. Essentially, the volume data structure is just a grid of active/inactive voxels and you could populate that grid many different ways (if that makes sense).
What I meant for instance is a mask that is based on curvature or hard edges. This mask isolates areas with hard edges, then you can use the smooth filter to only smooth that area. Like in Maya when you add edge loops to smooth certain parts more than others. So I guess some just common use masks could be nice. In this case maybe it can determine edges at a certain angle and mask only the voxels at those hard edges to smooth. I know subD and voxel are not the same of course but the idea of what to smooth and what not to smooth is what I am getting at. Anyway the implementation you have provided is great!
One potential use case for meshes is to clean up the inside of medical scan meshes (bones in this case).
Bone meshes often end up littered with “bone marrow” inside the outermost surface(s), the residues of the point cloud. For such use cases I imagine that PointToVolume + Union could be used to “fill up” the entire “inside” of the mesh and Union away the remaning “mesh splinters”. These inside points often also results in a “inner surface” due to density differences in the bone. For my use cases I’d prefer to get rid of all such “inside crap”.
The problem with a straightforward use of PointToVolume is that the “outermost” surface vertices would “expand the mesh” with radius distance, so if one could shrink the outermost voxels with the same distance as the radius, one would end up with the initial outermost surface, while everything “inside” would be just empty (due to Union of everything).
Such a cleaning strategy would be gold for many medical scans. The general problem today is that cleaning strategies doesn’t tend to give consistent results without manual tweaking.
I aim for 100% automation of mesh cleaning, and I’m actually almost there. But as you all know, in context of automation “almost there” means “not there at all”…
Its a great plugin. Thank you for sharing. I will also play around with it this weekend. Using a proven library like openVDB will definitly find many useful applications. I‘ve also read your source code on github. Its a great example for a well written hybrid C# and C++ grasshopper plugin. And last but not least, the overall design is very consistent and well made, same as your webpage. Awesome
Thats simply the difference between fully automated mesh modelling and high end surface modelling. Its impossible to have both. You want to fully automate a modelling process of f.e. medical parts, then you dont need to care much about surface quality. Its of much lower priority. You want perfect surface quality for high end consumer product, you have to quit your expectation about automating everything.
These display artifacts are likely caused by how the vertex normals are being calculated i.e. calling ComputeNormals on the display mesh. Taking vertex normals from the gradient of the scalar field should give a smoother (looking) result without much additional effort. See below for a comparison.
Also, for cases where you don’t have access to a scalar field to get the gradient of, I made a little tool to apply some simple smoothing to the mesh normals by averaging neighbouring normals (not modifying vertex positions at all).
@ryein, this is an amazing plugin and you are raising the bar really high by enabling a multi-threaded volumetric modeling tool that runs flawlessly in GH/Rhino. I did quick tests on some really intricate and high-resolution solid models and I should say I am in awe with the performance of the tool. Kudos for developing and sharing this tool!
One quick question: can you think of any shortcut for mathematical surfaces (as meshes) to be generated through formulas in Dendro? Obviously, this can be done in many different ways using built-in components or using other plugins (and by feeding the output data into Dendro), but my main concern there would be the performance loss. I am asking for a (voxel)-bounding-box-less and multithreaded solution, as these are two of the highlighted/distinctive strengths of Dendro.
@species Thanks for the response and I am glad you are digging the plugin. I am constantly blown away by what it can do and was really excited to throw it out to everyone.
I think you could incorporate mathematical surfaces into the pipeline, but the output might not be what you’d want. Unless you supply Dendro with closed geometry (or close to closed), it will wrap the geometry and give it a thickness equivalent to the voxel size. Below is an example of this using a generic surface…
@ryein - Thank you for developing Dendro. The stability and usefulness of the plugin is really amazing!
I want to highlight some interesting news that came out today from NVIDIA, which may also be useful for further developing Dendro:
-> OpenVDB Adds GPU Support with NanoVDB; OpenVDB Version 7.1 Now Available OpenVDB is now supporting GPU acceleration through a new functionality
NanoVDB is a small yet powerful library for accelerating certain OpenVDB applications through the use of GPUs. The open source repository is available now! To download the source code, build the examples, and experience the power that the GPU-accelerated NanoVDB can offer your sparse volume workflows, see
In its current version, Dendro is using OpenVDB in the background, generates meshes from the signed distance field and the extracted meshes are then rendered using the basic Rhino viewport.
I think another more efficient path could be to directly render the distance field (and only export the mesh if you actually need it). Therefore, not the mesh is rendered - but the distance field. I am not sure if the Rhino Viewport (or another plugin) could be used to directly render *.vdb files or if there needs to be a separate window where the signed distance field is rendered. I have not yet figured out how this could be done in Rhino/Grassopper - but I guess the performance might be even faster / smoother and comparable to tools like nTopology or houdini that seem to be using such an approach …
Though I agree with you, the biggest upgrade in the Dendro workflow would be on the visualization side. If the marching cubes portions is a bit slow, it’s not so bad if you only need it for final baking. I don’t know if it would be possible to visualize the signed distance file using ghgl?
GHGL was my original intent and my first pass on the plugin I had attempted to do everything through it. Right now Dendro is re-generating a new mesh at each “Dendro” component, not just rendering it. The need to re-generate the mesh for every component execution is really intensive, and, I am guessing here, a major slowdown in the pipeline. I had read the GHGL documentation when it came out, looked over some of the examples, and felt I had a workable solution. For whatever reason I just couldn’t get the volume to render and ended up just coding it with the mesh rendering after getting frustrated.
I was planning on getting started on V2 of Dendro over the next couple of months. I was already on planning to update to the newest OpenVDB but I think getting GHGL working would be another great priority. OpenGL is not my area of expertise so I might need some help getting that up and running though. Any suggestions for new features for Dendro would be more than welcome.
