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:

Aether.dll

Aether_Examples.gh

(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

or in the forums of K3dsurf

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.