Modelcore: Sketch-Speed, Solid-First Modeling
Why I'm building a new kind of 3D tool for the browser.
Most 3D tools force you to pick a side early. Some software gives you speed and fluidity, but you can create geometry that effectively becomes downstream waste: open shells, non-manifold edges, and boolean scar tissue that requires hours of cleanup later. On the other hand, BIM and solid modeling systems are robust and expressive, but they often feel heavy. They’re great once you commit, but painful when you’re still exploring.
Modelcore is my attempt to close that gap. I want the speed and approachability of tools like SketchUp, but with a foundational bias toward valid solids and predictable results, all delivered in a modern web-native interface.
The "Solid-First" Philosophy
I'm building for that specific moment in design when you want to iterate quickly: massing, floor plans, spatial layouts, and early assemblies. But unlike traditional sketch tools, I believe you should still end up with a model that is technically usable. It should be ready for clean exports into visualization pipelines, valid for analysis, and structured enough for automation.
This requires a stance that I wish was more common in early-stage design tools: if an operation claims to output a solid, it must either produce a watertight, 2-manifold solid, or it should fail clearly and leave your model unchanged.
This isn't about demanding "perfect CAD" definition on day one. It’s about avoiding the familiar trap where speed today becomes technical debt tomorrow.
What this means in practice
Modelcore is a direct modeler at its heart. You draw, infer, add, merge, and subtract directly on the geometry. However, "direct" doesn't have to mean "anything goes."
My approach enforces a few critical rules behind the scenes:
- Boolean operations are never allowed to quietly succeed on invalid input. If a parent solid isn't watertight, the boolean simply won't run.
- Failure must be atomic. You shouldn't have to deal with partial updates or corrupted intermediate states.
- Interaction must be deterministic. If the camera and scene are the same, your clicks should hit the same thing every time.
Trust comes from predictability, not feature count.
Why the browser?
"Browser CAD" is often treated as a compromise - a plane on the runway unable to take off - but I see it differently. A web-native tool offers instant access without license servers or installation friction. It makes collaboration native, treating event streams and state diffs as first-class citizens. And perhaps most importantly, it opens the door to a modern ecosystem of JavaScript and TypeScript extensions rather than niche, proprietary scripting languages.
I am pragmatic about this choice. Browser performance is a real engineering challenge, so the architecture maintains a hard boundary between the UI and the geometry execution. This ensures the app stays responsive even while the modeling core does serious work.
Where I'm going
My goal is to build a modern, solid-first alternative for conceptual design, one that is automation-friendly and capable of growing into more complex workflows. I envision components that can evolve into "families" over time, and an extensibility layer that allows others to build deep integrations.
From a process standpoint, I'm building this now because modern AI tools have unlocked code for me. Someone who was historically a "product guy" can now make huge strides in implementation, using a decade-plus of experience in BIM tooling to apply these ideas quickly. This project is a bit of a grand experiment on my part, but I hope it both proves the power of modern tooling for our antiquated industry, and demonstrates how AI-layered development can become a better process than traditional software development.
If you're a designer or engineer who has ever hesitated to start a quick model because you knew it would be garbage later, or if you simply miss the joy of fast, solid modeling, I'm building Modelcore for you.