algorithmic modeling for Rhino
Spatially varying fields, which associate a value (such as a number or a vector) to every point in space, have a wide range of applications.
I wanted a simple way of defining such a field in a Grasshopper script component as an equation, or a function of distance to some geometry, then passing this field to another script component, in a way that the downstream component can easily query the value of the field at any point. For speed reasons I did not want to do this by passing millions of sample values.
Various tools for fields do already exist in Grasshopper, both natively and as plugins, but of the ones I looked at, I couldn't find any that provided the flexibility and speed I wanted, so I put together a very simple library. For now this includes scalar, vector and frame fields.
With the scalar fields, I also made an implicit surface tool. These are also sometimes called isosurfaces or level sets, and they can be thought of as the equivalent of the contours of a heightfield, but in one dimension higher. A scalar field has a value everywhere in space, and the surface is where it switches from negative to positive, or crosses some given threshold value.
Probably the most popular approach to isosurfacing is an algorithm called marching cubes, which checks values of the field at the 8 corners of each cell of a cubic grid, and assigns each cell one of 256 pre-defined possible polygon topology configurations depending on how the field changes values between the corners, with some interpolation for the positions. There’s also a variant of this using tetrahedra, which I’ve played around with in the past (0,1,2).
Here I've come up with a different approach, consisting of two stages.
The first part of this is a voxelized threshold of the field. The value of the field is queried at the points of a 3d grid, and the ‘cell’ centred at each point is assigned to either in or out, then we take the faces of the cells which divide inside from outside, giving us a sort of chunky stepped approximation of the surface.
However, instead of using cubic voxels, I use truncated octahedra. This 14 sided polyhedron tessellates to fill space, and can be seen as the Voronoi tessellation of the points of a body-centred-cubic lattice (the corners of a cubic grid, plus an extra point at the centre of each cube).
image by Jim Lehman
The advantage of the truncated octahedral voxels over cubes is that the resulting threshold surface will not have any non-manifold edges. For example, 2 diagonally adjacent cubic voxels could share an edge, and that edge would then have 4 adjacent faces, which would cause problems later on. Marching cubes resolves this with its big lookup table of edge cases, but I felt like trying something a bit different.
As a Voronoi tessellation, the truncated octahedra always meet 3 around an edge, so this problem of the non-manifold edges can never occur (yes, ok – cubic voxels are also technically a Voronoi tessellation, but a nasty degenerate one where one of the 3 faces per edge disappears to nothing).
This can be illustrated with a 2d equivalent - A hexagonal tiling (which is the Voronoi diagram of points on a triangular grid) will never have the non-manifold edges that can occur with squares.
The second stage of my algorithm takes the stepped approximation of the surface from the first stage, and iteratively pulls its vertices onto the actual isosurface. Here we make use of the gradient of the field, and do a Newton-Raphson iteration, which converges quickly. Because all the vertices are pulled independently, this can be done in parallel.
The advantage of this two-stage approach is that the first stage can be carried out with a coarse grid, as it only needs to capture the essential topological features of the surface, and because it is only a binary check with no interpolation it can be fast.
Then, only after we have ruled out the vast majority of the points, we pull the remaining ones onto the surface to capture the finer details of the shape. We can also even include smoothing or subdivision steps between the 2 stages to improve the quality of the resulting mesh with little extra cost.
So here it is if you want to play with it:
(and the source is all up on GitHub here)
To try this out, put the Aether.dll in your Grasshopper libraries folder and make sure it is unblocked. Then when you open the Grasshopper definition you will be prompted to update the referenced assembly locations, and you should point it to where you just placed the dll. You'll also need Weaverbird installed if you want to do the smoothing or subdivision between steps.
This definition doesn’t do any clean-up around the edges of the grid – so you’ll probably want to either make the grid big enough to leave a gap around your geometry, or trim the result with some clipping planes.
I’ve included implementations of inverse distance weighted fields for curves and points (a.k.a. metaballs), and the mathematically defined implicit surface which approximates the gyroid.
You can find equations for many other nice surface under the Level surfaces section here:
http://www.msri.org/publications/sgp/jim/menud.html
If you want to have a go at defining your own fields, you’ll also need to include the gradient function. For this I find Wolfram Alpha comes in very handy – you can just plug in Grad(some function of xyz) and get the result. For example: grad(sin x * cos y + sin y * cos z + sin z * cos x)
Bear in mind that this is all work-in-progress - I just put it together yesterday, so there are very likely still some bugs. Any feedback welcome, or just post if you find a nice example.
Hope it is of some use/fun!
Daniel
Thanks to Dave Stasiuk, Will Pearson and Anders Deleuran for helpful conversation around this.
Comment
is this plug still working? or.. hot to install it...
unless there is another way since 2014 to create curve based mesh...
would love some advice here
thnx
I've played with this system again, here, still wondering how to rid bulges in Aether like I have finally achieved with traditional marching cubes:
http://www.grasshopper3d.com/forum/topics/bulge-free-metaballs-and-...
Oh wow, I'm not happy with the lack of simple distance field creation here instead of a force field that I can't normalize and combine together into a coherent tight object, but I have just discovered a very elegant VB component here that indeed does old school metaballs with points and lines, with very simple input of a list of points/lines and their metaball/metaline diameters:
http://www.grasshopper3d.com/profiles/blogs/marching-cubes-curve-wr...
There is also a major hassle in that I can't just set the radius of the force field around each object, and right now the number of lines or points changes the resulting radius of everything at once. The setting for points and lines interacts too, drastically.
Biggest deal killer complaint, now that I have it working without many final mesh defects:
Putting two or more metalines next to each other to widen out a hotdog into a ribbon structure, instead of combining the two original hotdogs smoothly, actually also doubles the force field height too, so I can't get a thin strip at all, but a much thicker feature too, here shown as the original space filling polyhedra before any mesh smoothing, showing how the central dual lines in the same plane as the other two curves, has thickened the bridging structure, not just widened it out into a ribbon. That removes my ability to think about what the result will be. Thus so far it's not really metaballs or metalines that have a normal smooth combination of them as a result. I'm not a C# programmer which makes it difficult to play around.
Ah, switching back to Curves+Blobs instead of just Curves fixed even the sharp inner angle open mesh defects.
Fingers crossed, ready to model away. I want any curves and points added to Rhino to just do metaballs, hopefully with some control over each layer's blob size or something. In other words I want a plug-in for normal Rhino modeling.
Changing one of the C# code parameters helped a lot but still leaves a defect here and there seemingly unrelated to the original issue:
while(Math.Abs(FValue) > Acc && counter < Iter) //accuracy and max iterations
{
FValue = SF.ValueAt(Pt[j]);
Vector3d Gradient = SF.GradientAt(Pt[j]);
Gradient *= 1 / Gradient.SquareLength;
Pt[j] = Pt[j] - FValue * Gradient;
counter++;
}
Changed to less than one works better:
Gradient *= 0.5 / Gradient.SquareLength;
Hopeful here but need help with why it usually actually fails due to defects in the surface due to the last C# module doing some remeshing step. Only a few simple 3D curves bug it out completely, seen here just before the final C# component and after:
That's with Curves+Blobs whereas with just Curves it's not so crazy but still not usable:
I can reproduce these defects by simply making a copy to duplicate in number the original sample curves and points and reassigning the items as inputs.
I'd like to translate these open source modules into Python to understand them better but I wonder if that would slow it down much?
Hi Moonbeast. Is it giving some error message? Sometimes the COFF loading causes problems when passing custom types between scripted components like this. Try switching it off in GrasshopperDeveloperSettings, then restarting Rhino.
Added by braulio gatica 0 Comments 4 Likes
Added by David Rutten 5 Comments 32 Likes
© 2017 Created by Scott Davidson. Powered by
You need to be a member of Grasshopper to add comments!
Join Grasshopper