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.
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.
I've fixed that issue with the `set_default_material` problem; tyvm.
> maybe a wireframe "type" material
I have that actually; it's bound to the W key. Invaluable for debugging and inspecting stuff for sure. N switches to normal texture too
I might have to make the docs for keybinds a bit easier to find
> Change the Normal Map, Roughness Map, and Metalness Map XY scales
Yeah these are all currently controlled by a single "texture scale" param in the material editor. I could definitely see situations where adjusting them individually would be valuable; I'll add that to the TODO list
Anway, tyvm for checking out the project in such detail and for the feedback; I genuinely appreciate it very much
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...
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.
reply