Show the Working

COLLADA to PLY

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 scanning and research format, which stores each corner once. You choose binary or text.

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.

Both of these store a corner once

Both formats keep a list of points and refer to them by number, so a corner where six triangles meet is stored once and pointed at six times. That is what an STL cannot do, and it is why these conversions do not change the size of a file very much.

Duplicate corners are still welded on the way through, in case the model passed through an STL earlier in its life — but only bit-for-bit identical ones. Welding within a tolerance, which most tools do, quietly fuses surfaces somebody meant to keep apart. The number actually welded is reported above.

What does not come across

Colours and extra per-vertex properties. What is written is the geometry: three coordinates per point, three points per face. Anything extra in the file you started with is read past correctly, so the coordinates land in the right place, and then not carried.

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