Blender vs OpenSCAD vs JSCad vs JSON: Choosing the best LLM-to-CAD engine

GrandpaCAD was built for my grandfather, a passionate 3D printing enthusiast who struggled with complicated CAD tools. My goal is to make 3D modeling as easy as having a conversation. Converting natural language into precise, 3D-printable geometry instantly.

I recently attempted a migration from Blender to OpenSCAD. This post follows my previous one on migrating to Blender, and it covers the different methods I've cycled through to find a solution that actually works for AI-driven 3D modeling.

If you want to see how the "brains" of the operation compare, check out my comparison of SOTA models for 3D generation.

The "JSON" approach: Why data isn't code

When I started, I thought I'd create a custom JSON schema. The idea was to have the AI output a list of unions, subtractions and other operations.

This fell short immediately. I realized the best interface for an LLM is a programming language. You need math, loops, and logic to build anything non-trivial. If I stayed with JSON, I'd be stuck re-implementing an entire CAD feature set myself, which is a massive and unnecessary undertaking.

The JSCad stage

The next obvious approach was JSCad. Since it's an open-source implementation of CAD in JavaScript, I thought it would give me a full feature set. I pushed it to its limit, but it isn't nearly as comprehensive as dedicated CAD software.

A perfect example is chamfers and fillets. JSCad essentially only supports "inflating" the model to create these. That isn't enough - I don't want to change the actual dimensions of a part just to break a sharp edge.

The Blender stage

I then tried Blender, which has the most comprehensive toolset of any open-source 3D software. This got me much further, but it introduced two major issues:

1. Manifold geometry: Blender isn't intended for real manifold meshes where the geometry is perfectly sound for 3D printing (although they are working on this!). Getting geometry to be "water-tight" is a constant battle.
2. Imperative complexity: The bpy (Blender Python API) is imperative. You're literally controlling the software: "Create cube, select cube, add bevel." This is extremely token-hungry because the AI has to manage every state change.

I also realized that modeling things like nuts and bolts that actually fit together is surprisingly hard in Blender, even with scripting.

The OpenSCAD stage

After sharing the project, people pointed out that OpenSCAD was a better fit for functional parts. I recently implemented support for it, and the results are much better and models are generated much faster.

OpenSCAD is declarative. Instead of telling a cursor where to move, you describe the final state. This is much less token-hungry than Blender's imperative approach. While OpenSCAD syntax isn't "standard" like Python or JS, that hasn't been a problem. I've built a harness that can automatically repair the code if the AI makes a syntax error.

By leveraging libraries like BOSL2, the AI can now generate industrial-grade threads, gears, and complex joints with just a few lines of code.

The path forward: A multi-engine hybrid

Ultimately, my goal is to combine these tools. OpenSCAD is the clear winner for functional parts, nuts, bolts, and anything that needs to be 3D printed with precision.

But Blender is still part of the infrastructure. Its feature set is too useful to discard. We'll be using it for rendering and eventually for "organic" modeling - like creating custom Dungeons & Dragons miniatures - where the strict precision of CAD isn't as important as the visual aesthetic.

Ready to build something functional? Try the new OpenSCAD engine now