A Unique Performance Optimization for a 3D Geometry Language

This is pretty similar to the caching used by the Grasshopper3d visual programming environment, which also deals with 3d geometry: https://www.grasshopper3d.com/

It's a crucial optimization to enable the kind of live programming environment you're talking about here, especially since some nodes ("components") are much more expensive to execute than others. The DAG of the program is laid out in the workspace, and it means users can smoothly drag sliders downstream even if re-executing the whole program from scratch would be prohibitively expensive. It's a lovely way to iterate on creative visual programs.

Like the Geotoy site at https://3d.ameo.design/geotoy

The Rusty Maze example https://3d.ameo.design/geotoy/edit/18 seems to be broken with the setting an initial default material "set_default_material" and even with it removed does not seem to build.

The rest are pretty neat, and a quick syntax for generating 3D geometry. Surprising how short the script needed for something as complicated as the pyramid example was https://3d.ameo.design/geotoy/edit/39 Also, relatively quick to edit and change, moving materials around and such.

Nice to haves: Looking at the resultant mesh, maybe a wireframe "type" material? Is there a way to change the initial light? (Eventually figured out how to toggle the light locations, and add a light. Maybe click the light helpers?) Change the Normal Map, Roughness Map, and Metalness Map XY scales? Link to a texture? (maybe don't want to allow uploads)

Far as a geometry descriptive goes though, the language seems cool, and very concise. Nice that it dumps to something generic like the obj format.

FWIW Wadge and Ashcroft tried a similar cache the world approach and ran into issues, but that was half a century ago, when storage was way more expensive...

https://en.wikipedia.org/wiki/Lucid_(programming_language)

https://billwadge.com/2022/07/17/we-demand-data-the-story-of...