This plugin looks very promising. I have one question which directly addresses one of my needs. I’d like to offset the Volume, but not as a radius only, but also in a specific direction (for example in the direction of, orthe inverse direction of, a mesh vertex or a nearby face Normal).
Would that be possible to do directly on the Volume, or would I have to shrink or expand (scale) the resulting mesh instead?
More specifically, I would like to be able to offset the Volume with the same distance as the Volume Radius in either direction (“inward” or “outward” which isn’t always so easy to determine on a mesh though, but…).
If you get any ideas on this, please let me know.
In any case, the functionality I’ve seen so far is really nicely adapted to the Grasshopper environment.
@Modeler3D the remeshing is out of the box from what OpenVDB provides, so you are stuck with what it can do. We have some remeshing tools we have used internally that might be something to add into the plugin at a later date. OpenVDB uses a strategy similar to this paper.
That said, as @laurent_delrieu pointed out, a lot of the inconsistencies can be addressed by tweaking the “Create Settings” parameter. Voxel size will affect the overall resolution, but tweaking the adaptivity can have an impact on the final topology. For example, increasing the adaptivity to 0.5 or so might help smooth out some of the irregularity in the final mesh output.
You could also look at the “Smooth” component as well. Using that right before you convert back into a mesh could help remove inconsistencies in the surface.
The mask feature also allows you to isolate regions and apply smoothing or offsets. For the Cell Cycle jewelry above, you could create volumes at all the nodes and smooth anything inside or outside of those nodes. Masks are not the most intuitive but I added the feature because it can really let you have much more control over operations.
@RIL There are two ways to offset the volume, either by the “Offset” component or by tweaking the IsoValue in your settings. The “Offset” component can take a positive or negative value and is pretty bulletproof. We have used it for thickening some reasonably complex geometry, and it solves for self-intersections nicely. If I understand you correctly, you should be able to adjust the direction of offset by just changing between positive and negative values.
Thanks for all the feedback. We have some pretty specific use cases for OpenVDB in our work so I am excited to see how everyone is using it and thinking about future features we can add. There is a lot more functionality in the library that could be exposed.
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…