Every factory already has the 3D data. It's just not usable.

Walk into almost any manufacturer, and you'll find decades of CAD data sitting in a file server somewhere. Every part, fixture, and assembly they've ever designed, modeled in painstaking detail.

It's tempting to assume this is a shortcut for physical AI. The 3D data already exists. Why not just point a robot's training pipeline at it?

Because that data was built for a completely different job. It was made so a human engineer could look at a part, check its dimensions, and send it to a machinist. Nobody was thinking about whether a physics engine could simulate it.

What "usable for training" actually requires

A CAD engine, and the files it produces, is judged on drawing accuracy. Does the part match the blueprint. Simulation asks a different question entirely. Does the part behave the way the real object would if a robot pushed it, gripped it, or dropped it.

That gap shows up in very concrete ways. Legacy CAD files are often riddled with geometry that's technically valid for design purposes but breaks a physics engine, like gaps between surfaces that a human eye never notices, or parts modeled as a single rigid shell when the real object has moving components. None of them carry the two things simulation actually needs: collision geometry that matches the true shape, and joint structure describing how parts move relative to each other.

None of this is a data quality complaint. The files are exactly as good as they were designed to be. They were just designed for a different reader.

The tempting shortcuts, and why they don't hold up

Faced with a warehouse of legacy files, there are a few obvious ways to try to close the gap.

One is to re-model everything by hand for simulation. It works, part by part. It does not scale to an industrial parts catalog that can run into the tens of thousands of unique components.

Another is to run a generic geometry cleanup pass and apply default physical properties across the board. This keeps the pipeline fast, but it throws away the one thing the legacy data was actually good at: precise, part-specific geometry. You end up with something that runs in a simulator but no longer represents the real object closely enough to be useful.

Neither path holds onto both things at once: the engineering precision already locked inside the file, and the physical behavior a training pipeline needs on top of it.

Our approach: read the engineering intent, not just the geometry

TRINIX, our CAD engine, is built to treat legacy CAD data as a starting point to reconstruct from, not a shape to blindly convert. It reads native and standard CAD formats directly, repairs the geometry issues that break physics engines, and infers the collision meshes, articulation structure, and material properties that were never part of the original file, all without discarding the precision the design data already had.

The goal isn't to replace the original engineering work. It's to give it a second life, this time as data a robot can actually learn from.

What we've learned so far

A few things worth being honest about:

• Format fragmentation is a bigger problem than geometry itself. Getting consistent results across the many CAD formats industry has produced over decades takes as much engineering effort as the physics inference does.

• Rigid, single-body parts are largely a solved problem for us today. Multi-part mechanical assemblies and deformable materials are still an active area of work.

• The value compounds. Every legacy file we can automatically revive is one less asset that has to be modeled from scratch, and that adds up fast at industrial scale.