exoform

opensaft

opensaft is the related fork of Embark Studios' Saft library for compiling, interpreting, discretising, and meshing signed distance fields. The fork makes the source more accessible and replaces macaw with glam.

A Hypothetical exoform2

exoform wasn't particularly fun to model with, and the server made it difficult to quickly get a session going with someone else. Revisiting this, I think I'd go for a Lua-based DSL for construction (where functions generate SDFs that can be composed), with the ability to insert gizmos that can then be tweaked in the interactive view (mapping these within a complex transform chain would be another problem, of course).

Taking this further, I'd want an ecosystem of functions that could be composed to build scenes - being able to assemble a town through procedural instantiations of buildings, which procedurally instantiate their own features, etc. - and to have this facilitated by a public library. Perhaps something like Unison, but with as little infrastructure involved as possible. A fun idea I've been noodling around with would be to host functions on ATProto, but that may be problematic in its own way:

philpax@philpax.me

let's say you've built a wonderfully crosslinked and interdependent ecosystem across atproto. what's to stop a left-pad incident from happening (i.e. an author pulling their deeply-interwoven content, or their PDS going down)? how does the network recover from that?

Not sure! I started sketching the DSL out, but did not take it any further. (For reference, it would look something like the Lua graph DSL in rucomfyui, but with concessions for interactive/procedural use.)

That said, I'm quite interested in Matt Keeter's Halfspace, which has been exploring the compositional DSL-based geometry design space for much longer.