We Let AI Build SketchUp Models With Nothing But an API

OpenSKP's writer API has no Chair class. No Table builder, no furniture module, nothing that knows what a chair is. It exposes materials, layers, groups, component definitions, and faces — the same primitives SketchUp itself is built from — and nothing above that. Which raised an obvious question once the writer shipped: could an AI coding agent, given only that low-level API and a plain-English description of an object, produce a real, correctly-structured .skp file?

We ran the experiment with two different AI coding agents, independently, with no shared prompt engineering between the runs. Both were pointed at the same generic API and asked to build furniture. Neither was given examples of chair geometry or table dimensions to crib from.

Chair, table, and an armchair

Output from an AI agent's own generated Python script, loaded straight into the OpenSKP web viewer with no manual cleanup.

The first run produced a scene with a dining chair, a side table, and an armchair — nine component definitions, thirty-eight geometry primitives in total, organized across three layers with four distinct materials. That structure wasn't hand-specified; the agent decided the layer and material breakdown itself, deriving it from how it reasoned about the objects (seat vs. legs vs. backrest as separate faces sharing a wood material, for instance).

Here's a representative excerpt of what the agent actually wrote, generating a chair leg as an extruded rectangular profile:

def add_leg(group, x, y, z, width, height, material):
    """Add a single tapered leg as a box primitive."""
    pts = [
        (x, y, z),
        (x + width, y, z),
        (x + width, y + width, z),
        (x, y + width, z),
    ]
    top = [(px, py, z + height) for px, py, _ in pts]
    face_bottom = group.add_face(pts, material=material)
    face_top = group.add_face(top, material=material)
    for i in range(4):
        side = [pts[i], pts[(i + 1) % 4], top[(i + 1) % 4], top[i]]
        group.add_face(side, material=material)
    return face_bottom, face_top

Nothing in that function is chair-specific — it's a general box-extrusion routine, the kind of primitive-geometry reasoning you'd expect from someone who understands 3D coordinate systems, not someone who was handed a chair template. The agent built its own mental model of "chair" out of boxes and faces, the same way a human modeler would work from scratch in SketchUp's own polygon tools.

An executive desk

A more complex single object: a desk with a drawer unit, modeled as nested component groups.

The second test pushed further into nested structure: a desk with an attached drawer unit, modeled as a component group nested inside the desk's top-level group — mirroring how a careful human SketchUp modeler would organize the same object, with the drawer as its own reusable component rather than geometry welded directly into the desktop.

A phone, viewed from both sides

Front and back views of the same AI-generated phone model — face winding and normals came out correct on the first attempt.

The third object, from the second independent agent run, was a simplified phone: a thin rounded body, a screen face, and a camera module. What's notable here isn't the object's complexity — it's the simplest of the three — but that face winding order came out correct without being told about it explicitly. Get winding backward and a face renders as invisible or inside-out from the "wrong" side; the model shown above renders correctly from both front and back, which means the agent's geometry reasoning implicitly respected consistent counter-clockwise winding, not just "some points that happen to form a face."

What this does and doesn't prove

This isn't a claim that AI agents can replace a SketchUp modeler for genuinely complex or organic geometry — everything shown here is bounded, rectilinear furniture-and-electronics geometry, well within what an LLM can reason about symbolically in coordinates and box-extrusions. What it does show is that OpenSKP's writer API is low-level enough, and clean enough, that an agent with no domain-specific tooling can drive it correctly: valid component hierarchies, sane material and layer organization, and geometry SketchUp itself opens without complaint.

That's the actual target for the API design — not "convenient for humans typing by hand," but "reasonable for a coding agent to drive from a plain description," since increasingly, that's who's calling it.

---

Try it yourself: github.com/iamahsanmehmood/openskp — MIT licensed, available for Python, TypeScript, .NET, Dart, and C++.