Creating Custom Fields in Grasshopper 2

Serengeti (Rhino WIP) Grasshopper2
,
1

One of the key advancements in Grasshopper 2 is the introduction of new high-level types: Function, Distribution, Gradient, and Field. These types increase the level of abstraction and enable more declarative definitions. (declarative vs imperative)

Focusing on Field, Grasshopper 2 provides various Field creation components, all inheriting from the Field abstract class. In its most minimal form, a Field follows this structure:

public abstract class Field
{
    public abstract FieldType Type { get; }
    public abstract string Name { get; }
    public abstract double ScalarAt(Point3d point);
    public abstract Vector3d VectorAt(Point3d point);
}

Every Field is required to implement ScalarAt or VectorAt (or both), defining how it evaluates scalar or vector values at any given point in space.

By default, creating a custom Field requires coding, which can be limiting. To address this, I developed the Field Start and Field End components.


CustomFields.ghz (270.5 KB)

Here, I created two simple fields inspired by Isopod’s Sphere and Curve Pipe SDF. Notice how these custom fields can seamlessly integrate and interact with other fields.

With this setup, users can add desired inputs and define how scalar or vector values are computed using simple Grasshopper components. The Field End component then creates a new Field type that inherits from the Field abstract class, allowing it to function like any other built-in Field in Grasshopper 2.

I’d love to hear @DavidRutten 's take on how this fits into Grasshopper 2 and @DanielPiker’s thoughts on its potential for implicit surface modeling.

You can download Kampecaris from here.

P.S. This is just a proof of concept, and currently, it is significantly slower than creating fields through coding.

10 Likes
2

Nice! I was actually talking to David a while back about whether this would be possible - like implementing an Interface in code, but as a sort of cluster on the GH canvas. Great to see you’ve made it work.
I think the general principle allowing to define functions without code could also be applied to several other types of functions beyond Fields. For example, defining custom Goals for Kangaroo, the mathematical Functions in GH2, root finding…
I guess performance will always be an issue to some degree, but the advantages for accessibility and quick prototyping could outweigh that.

3 Likes
4

This will always be true, as a Grasshopper file just takes a lot longer to evaluate than pure code. There’s a lot of overhead involved, especially if the underlying operations are super fast. If running a GH file adds 5 milliseconds of overhead, then it doesn’t matter at all if you’re performing a bunch of solid booleans which take seconds anyway, but it does very much matter if you’re performing some additions and multiplications which only take 30 nanoseconds.

I can think of four ways in which custom fields can me made faster:

  1. Straight up programming. This will require either an external IDE and compiling a plug-in, or using the scripting components once those come out. Clearly not a solution for all.
  2. Expressions. Still textual coding, but without any of the fluff you have to deal with when writing C# from scratch. Could be a decent halfway house, but still excludes people who are not comfortable writing expressions. There are already components for this, but we can come up with a nicer UI for it.
  3. Automatic reverse engineering of a Grasshopper network into clean code. We can make this work for simple cases, we can possibly even make it work for complex cases by investing loads of time, we’ll never be able to make it work for all cases. So as long as you’re creating your GH file using a small subset of components, and not doing anything strange, this will sometimes work. Sounds like maybe something we can focus on for GH3.
  4. Cache the results of a file like this, probably using some sort of custom discretisation accuracy. Then interpolate values in between samples or add more samples if needed.
3 Likes
5

Hello
My 2 cents on field domain. I think such common Object could be in RhinoCommon.
At the moment I see
GH_Field in grasshopper that is Vector Field in grasshopper.dll (usable in Rh 6, 7 …)
Field in IsoPod that is a scalar field in isopod.dll (just R8…)
Field in Grasshopper2 that is a scalar and/or vector field (just R8…)

Unification of a Field like the one of GH2 in Rhino 8 could be awesome. GH2 could use it, Isopod also and it will be more simple for plugins.

2 Likes