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
Problem solved!
I've been playing with his example with text as curves (a word) and has broken down the laptop four times :( .But with simpler curves worked very well, fast.
Thanks, that's awesome :)
Thanks. @David - I'm thinking of frame fields for specifying orientations and anisotropic material properties. Great to hear fields will be improved in GH2, and agreed that modifiers could be an important part of that.
incredible!
Interesting stuff. I want to improve the field data type in GH2 (support for both scalar and vector fields, haven't considered frame fields yet; what are they for?) and make it a far more fundamental data type. A lot of number/vector input parameter could be converted to fields as the component has a locality (for example the Radius input for the Circle component should be a field instead of a number, the Length and Direction inputs of Line SDL should be fields instead of vectors and numbers, etc.).
A big part of fields in my opinion needs to be modifiers and operators. Basically types of field which take one or more subfields and tweak the values, just like a Photoshop filter.
I'd love to hear any insights about how to make fields useful and performant.
Hi Daniel,
Can you try downloading the latest service release(in Rhino under Help>Check for updates)?
Version 5 SR8 64-bit.
Is there a rhinocommon.dll 5.1.30000.13 to download or how to do?
Nice!!! Thanks Daniel!!!!
Thanks Daniel, looks very funny.
But it gives me error...
1. Error (CS1705): The assembly 'Aether, Version = 1.0.0.0, Culture = neutral, PublicKeyToken = null' used 'RhinoCommon, Version = 5.1.30000.13, Culture = neutral, PublicKeyToken = 552281e97c755530' having a higher version the assembly 'RhinoCommon, Version = 5.1.30000.12, Culture = neutral, PublicKeyToken = 552281e97c755530' referred to.
I have to update Rhinoceros or...?
Nice! Thank you Daniel
Welcome to
Grasshopper
Added by Parametric House 0 Comments 0 Likes
Added by Parametric House 0 Comments 0 Likes
Added by Parametric House 0 Comments 0 Likes
© 2024 Created by Scott Davidson. Powered by
You need to be a member of Grasshopper to add comments!