Can we build mechanical 3D models like compiling a codebase?
- Most mainstream tools (SolidWorks, NX, Creo, Fusion 360, CATIA, Inventor, etc) store models in opaque, undocumented binary blobs — unreadable to humans and incompatible with Git
- Even small changes produce noisy diffs, making version control, collaboration, and peer review difficult or impossible
- PDM systems are heavyweight, locked-in, and fundamentally hostile to the Git-based workflows used in modern software and hardware development
- Some systems (e.g. OpenSCAD, FreeCAD’s zipped .FCStd, or DXF) offer technically readable formats
- But they mix modeling intent (sketches, constraints, feature parameters) with geometry results (BREP, mesh, solver data, caches, etc.)
- Without strict source/result separation, even text formats remain noisy and unreliable in Git — diffs are polluted, changes misleading, and true modeling logic gets buried
- Systems like NX or Creo provide powerful parametric tools — but compared to code, they still lack modularity, reuse, and transparent dependency management
- Cross-part references often rely on absolute paths, measurement links, or external references that break easily
- There’s no way to define scoped variables, reusable functions, or modular logic blocks across parts
- Logic is encoded via GUI interactions, with no textual diff, audit trail, or reuse
- Failures from circular dependencies or bad rebuild order are hard to diagnose — there’s no dependency graph or logs
SplitCAD is built on two core ideas:
| Concept | Software Project | SplitCAD |
|---|---|---|
| Source | .cpp, .h |
.yaml, .json |
| Build Artifact | .o, .obj |
.cache.cad |
| Final Output | .exe, .wasm, .a |
.step, .stl, .png |
| Compiler | gcc, clang |
kernel (e.g. Open Cascade) |
| CI/CD | GitHub Actions, etc. | Model checks + preview builds |
- Git tracks what matters: modeling intent
- CI can rebuild geometry from clean source
- Exported formats like
.stepare final outputs, not modeling state - Intermediate files (like
.cache.cad) store geometry to speed up GUI preview or CI teasting, similar to.ofiles in software builds - Build speed is not critical: geometry generation can be slower as long as results are cached, just like compilation in code projects
- GitHub diffs show
length: 10 -> 12, not hex dumps - AI-friendly: With human-readable source files instead of opaque binaries, it's possible to train LLMs to analyze, repair, or generate CAD logic — similar to AI-assisted programming.
- Tools like CadQuery already adopt a source/result separation model — but they are code-first, not GUI-first, which makes them less accessible to most mechanical engineers
- Visual modeling is inherently spatial and interactive; requiring users to write code for every action breaks this intuitive workflow
- In contrast, our approach is GUI-first: users work visually, while every feature (sketch, extrude, pattern, etc) maps to an explicit source entry
- No hidden state — everything is tracked and reproducible
These ideas are not hypothetical. Tools like KiCad have already proven the value of GUI-first, Git-native workflows in hardware design. KiCad stores structured text files (.kicad_pcb, .sch), enables readable diffs and reviewable PRs, and integrates cleanly with CI pipelines (e.g. KiBot). SplitCAD extends this proven paradigm to the domain of 3D mechanical CAD.
Onshape proves that a fully Git-compatible modeling paradigm is possible — with real branching, merging, and per-feature diffs built into the modeling workflow. However, it’s a proprietary, cloud-only platform. You can’t download or self-host your models, nor access the source in an open format. SplitCAD aims to offer the same structured clarity and Git-native workflows — but with local control, offline editing, and fully open source.
Everything above focuses on the front-end. But CAD ultimately depends on the geometry kernel — the engine that computes BREP, intersections, booleans, and parametric updates.
Open-source options like Open Cascade exist, but still fall short of industrial-grade engines like Parasolid or ACIS in robustness, precision, and performance.
This backend limitation constrains how far even the best front-end design can go.
Like compilers before GCC or LLVM, CAD tools have long been opaque, closed, and expensive. Once compilers became open and standardized, the ecosystem flourished — from static analysis to AI tooling.
CAD may be next. Open geometry kernels like Open Cascade could fill the role LLVM played for compilers — providing a foundation for analysis, AI tooling, and new user paradigms.
This is a proposal for a better CAD workflow paradigm.
I do not plan to build this myself — but I hope it can inspire discussion or implementation by others. Feel free to fork, share, or reuse the ideas for as long as your project is either open source or non-commercial.