Thought Experiment: Rebuilding Grasshopper from Scratch

[nikodellic]

tldr; made a grasshopper-like node based editor prototype (WIP), seeking advice on what would make grasshopper like programs better for you.

Ok so as an exercise I built a very rough and very WIP node based programming language for 3JS.

Three-nodes - Visual Programming for Three.js

I did this exercise as a way to reflect on some of my perceived challenges I find using grasshopper over the past 8 years:

1. UX: Inspecting Data: Dropping a text node and then connecting the output of any node is the only way to inspect data structure and schema. Instead, I’ve created a properties window that can automatically show the input and output data, as well as the source code for the component:

   

2. Objects {} > trees. everything is structured as an object instead of a tree, which is more aligned with programming languages like javascript and python.

   

3. Frame updates (WIP): any component can be registered to update on every frame, making animations and looping easier out of the box.

   

4. Source code: all of the code that makes each component is visible in the properties pane.

   

5. graph + 3D connectivity (WIP): you can interact with the previewed 3D objects in the scene, applying transformations, which then show up on the graph:

   

6. Faster context switching: pressing tab switches between graph and 3D very quick.

   

7. Custom nodes: any node can be modified or duplicated:

   

8. AI can write new components for you (WIP) and Model Context Protocol (MCP) for AI assistance in creating new graphs (TBD).

   

The list goes on. Everything is buggy, and while it is open source, it is not stable enough to invite other contributors until the codebase is more stable and well documented.

The reason why I am here posting on the grasshopper forums is I am curious as to what ideas you’ve had to improve grasshopper, and what you think would totally make our lives better. For example, I think some of the best things in this prototype is the really banal stuff, like the faster context switching and data preview pane.

Node based editors have proven to co-exist well with traditional programming, and have found their place in Rhino, Blender, Unity, and Houdini, as well as a recent explosion of apps connecting API related workflows, such as n8n and other ways to interact with AI agents. I think its worthwhile to have a more rigorous conversation around what makes node based editors great, and where they can improve.

The grasshopper community is a super mature community based around a super innovative node based editor (in my favorite program of all time), and captures a wide array of industries, so I thought it would be a fruitful discussion to share here.

thanks for the read,
Niko

[Birk_Binnard]

Very interesting post - and software. I was surprised your test worked as well as it did. It looks to me like the Vector3 component has Y & Z values reversed, but everything else seems OK. I agree that node-based programming is (thankfully) becoming more widespread as an alternative for classical code, so here’s hoping your efforts will continue.

[nikodellic]

Thanks for taking a look Birk. Y and Z axis are swapped in 3JS by default, meaning y is up/down and z is forward/backward. I have a 3DM loader component that will optionally update the rhino model to work with swapped y and z axis.

Thank you for the motivating response!

Niko

[Birk_Binnard]

Aha! That explains it - thanks. I use GH for 3D printer designs so I only know about FDM printers. Plus my printer is a delta style which means (0,0,0) is in the center of the printable area, which is a circle. Here’s hoping you’ll be showing more progress soon.