JC Eberdt

There was a question on Bluesky how the import works, so here’s a bit of an explanation. But if you’re going to do this, have Claude Code or the like set it up for you. It will save you a good portion of your life.

So far, every vehicle in the tool starts life as a parametric OpenSCAD model.

• Each vehicle has a JSON manifest in the game’s pack. It names the source file and its includes, the units (the CAD is in millimetres or centimetres, the game in metres) and which way is up and forward. Then it lists the parts: the hull, the ramp, turrets, wheels, etc.A part is a SCAD expression the source’s own modules draw, rearramp() or turret(), plus a colour group and, for anything that moves, a joint: the pivot, the axis, the range, and named states like down and stowed. Where a number is needed, a pivot or an angle, it’s written as an expression in the source’s own variables.
• The importer pulls the source over the network from the manuscript’s mirror.
• Export part by part. OpenSCAD’s CGAL unions are slow: a whole model takes close to a minute, its individual parts seconds. So the tool generates a driver per part that uses the source, repeats its top-level assignments so expressions can name them, and exports each part on its own. A part placed by a transform (the turrets’ translate/rotate/mirror) has that transform measured off four marker cubes exported through it, so pivots and axes can be given in the module’s own frame.
• Proof. This is the step where Claude Code earns its keep. Every joint state that has its own SCAD, e.g. the ramp drawn “down”, is checked against the rest mesh turned about the pivot by the state’s angle. A wrong pivot or a wrong sign fails the import. Then the parts, posed as the composition poses them, are compared against the model exported whole.
• Clean up in Blender. The same script runs headless in Blender: the CGAL facets are welded into a mesh with its normals checked outward, the frame turned to glTF’s conventions, the scale set to metres, smooth shading split at 30 degrees. UVs are a box projection in metres across the whole vehicle at rest, so a texture, or a camouflage pattern, lands at true scale and continues across parts. Each colour group becomes a material; each part becomes a named node, a moving part’s origin on its pivot.
• Write the asset and its sidecar. Out comes a .glb and a sidecar JSON: every node, its joint in the glTF frame, the named states, the materials and their roles, markers such as where the EM drives sit, the gun mounts with their limits, the proofs’ numbers and the source’s hash. Plus a provenance entry in the pack, so a check can later tell whether the asset still matches its source. The whole thing is deterministic: the same source and manifest write the same bytes, and a –check mode rebuilds to scratch and compares.
• Godot reads the sidecar. On the engine side there is one class for every imported vehicle. It never names the barge or the Droopy; what a model has, what moves, about what and how far, is all its sidecar’s. Each part becomes a mesh at its place; a joint becomes a node on its pivot that hinges, steers or spins. A material whose role is “paint” gets the hull shader, which paints camouflage in the asset’s own frame at true scale, and a moving part carries its paint with it. Each part’s own triangles become collision, on a body that moves with the joint, so a lowered ramp can be walked up and a hold stood in. Gun mounts become turrets that traverse and elevate within the set limits that were computed from the CAD so a gun never passes through its own hull and its bullets can’t hit itself.
• A physics stand-in takes the parts as convex hulls, with the mass, centre of mass and inertia the vehicle’s record gives. That way a laden truck settles on its springs and the barge flies like a dead elephant.

Obviously, this one hasn’t had much detail work done on the OpenSCAD, but you get the idea.