Show the Working

COLLADA to STL

Your model never leaves your browser, and nothing is downloaded to make this work. A mesh is a list of points and a list of triangles; reading one and writing the other is arithmetic your browser can already do.

…or drop one anywhere on this page.

Into the format every slicer opens, and the one with the most to say about what it loses: no materials, no colour, no names, and no way to share a corner between triangles, so the file grows.

COLLADA is XML and older than the rest, and it is still what SketchUp and a good deal of older tooling writes. Its index stream is shared between several inputs at different offsets, which is the one thing a reader has to get right and the one thing that produces a plausible wrong answer if it does not.

None of these formats has units

This is the single most common reason a model comes out wrong, and no converter can fix it, because there is nothing in the file to read. Both of these formats are lists of numbers. Whether 10 means ten millimetres, ten inches or ten of something else is a convention between whoever exported the file and whatever opens it next — it is not written down. That is why models arrive at twenty-five times their intended size, or a twenty-fifth.

So the dimensions are shown above as three bare numbers. If your object is meant to be about 60 long and it says 2.36, somebody wrote it in inches and something else is about to read it as millimetres. The numbers are yours to recognise; nothing here can do it for you. If you want the size recorded in the file, convert it to 3MF instead — that is the one format here that stores it.

COLLADA's index stream is interleaved

A COLLADA <triangles> element holds one list of numbers and several <input> elements each claiming a slot in it — vertex at offset 0, normal at offset 1, and so on. The numbers are therefore groups, one value per input per corner, and the stride is the highest offset plus one.

A reader taking every number as a vertex index reads thirty-six corners as seventy-two, runs off the end of the vertex list and builds a different shape. Nothing says the stride but the offsets. And not every face is a triangle: <polylist> carries a <vcount> saying how many corners each face has, which a great many exporters use for quads.

An STL repeats every corner

An STL has no way to say that two triangles share a corner. There is no vertex list and no index; each triangle carries its own three points. So a corner where six triangles meet is written out six times, to full precision, every time.

A cube is eight corners, and an STL stores thirty-six. That is the whole reason the file gets bigger on this page, and it is the format doing it rather than the conversion: the box that trimesh writes is 433 bytes as an OBJ and 684 as a binary STL, and its 320-triangle sphere is 9,807 bytes against 16,084. On a scan of a few million triangles the difference is not small.

Nothing is lost by it — the shape is identical, and the corners weld back together coming the other way. It is just larger, and now you know why.

What does not come across

Everything except the triangles. An STL has no colour, no materials, no texture coordinates, no object or group names and no scene — it is geometry and nothing else, which is exactly why every slicer reads it. Faces with four or more corners are split into triangles. Face normals are recalculated from the three corners rather than copied, because a stored normal that disagrees with the geometry is worse than none and a great many files have them wrong.

Whether it is watertight is reported above, because that is what a slicer is about to ask: a closed solid has every edge shared by exactly two triangles, and one that does not leaves the slicer guessing what is inside. This is measured after welding — straight off an STL no two triangles share a corner by index, so every model on earth would look full of holes. Nothing here repairs a mesh; it tells you, and repairing is a different job.

Nothing is rotated. glTF is Y-up by its specification, COLLADA records an up axis of its own, and STL, OBJ and PLY say nothing at all — in practice arriving Z-up from CAD tools. What a file declares is reported rather than acted on, because a silent rotation is far worse than a model you can turn yourself. If your object arrives lying on its side, that is why, and it is one rotation in whatever opens it next.

Where to go next