no representation is king

different geometric constructions have different efficient representations and different sets of operations one will wish to perform on them. there is no single best representation. any paradigm you don't support is the paradigm the user needs today.

okay but meshes are king

for applied computational geometry, eventually you'll want to do something with your geometry: pathfind around your geometry, rasterize to render to a screen, slice for 3d printing, motion plan for cam, etc. meshes are often best for these. this does not mean you should convert to mesh representations early, but rather that you should expect to convert to tris (or tets) eventually, and should plan to carry through sufficient representation of intention to properly guide that conversion.

intention matters

we don't commit minified code. STLs are an output derived from a geometric entity not much different than a rendered image. good formats preserve design intentions and allow those intentions to be parameterized and then inform and parameterize downstream actions, such as export into consumable output formats. you must be able to represent intentions of arbitrary complexity, you must support a full general purpose language.

you are gonna need it

any limitation in your system will block someone at some point. the only out is, again, to support a general purpose programming language. a scripting system does in a pinch, but a real solution needs not to feel bolted on, it needs to be a core feature with total control and it needs to be high performance. if I need to do something weird, something only supported by a general purpose language, there's a good chance I'm doing something truly weird and that it's going to be complex and computationally expensive.

epsilon is an evil kludge

an epsilon tolerance is a kludge hiding inconsistent computations, it will go wrong and it will break your geometry eventually. such a mechanism should only ever be tolerated in explicit mesh simplification code. even when an epsilon does not fully break your geometry, if it's ever active, it means your geometry was already wrong. there are other levers to pull to avoid epsilons, such as admitting that most numeric geometric operations are not commutative.

perf matters

fast preview is required to allow the user to iterate virtually. fast full quality export is required to allow the user to iterate physically. neither can be neglected, if your full quality generation is fast enough, you don't need a preview mode. here's my pet project deriving geometry and pushing it to the screen at 1.4GB/s.

designs change

plan for version control, ideally don't reinvent the wheel, use a textual format and standard version control tools such as git.

a GUI is an interface

GUIs are useful, but the human readable textual representation remains canonical, GUIs must be a bidirectional update mechanism for the underlying source.

don't crash

outside of getting OOM killed, there's no excuse for software crashes on functioning hardware. write total functions, if something can't be total, make it a Maybe/Optional type. don't lose a user's work. that said, if your user writes something non-terminating because you gave them a full general purpose language, that's on them, a timeout might be nice.

concretely

this all points at the CAD topology I've settled on: the core representation is source code in a general purpose programming language. there is no privileged kernel, what would normally be the kernel is just library code imported by the user's module, infinitely extensible. the primary input UI is the user's preferred text editor, while the primary interactive output is a wire format, a socket connection, and a lightweight renderer/viewer.