Convert OBJ to glTF

Almost everything useful in the modern 3D web pipeline takes glTF as its input. gltf-transform prunes, welds, resamples and compresses it; the Khronos validator checks it; three.js and Babylon.js consume it; every asset-optimisation service assumes it. An OBJ is outside all of that, and the first step in bringing one in is a conversion that produces a document those tools accept.

The reason to target .gltf rather than .glb at this stage is that the JSON form is the one you can read and change. A GLB is the artefact you produce at the end of the pipeline, after the material is right and the compression pass has run. This page is for the beginning of that pipeline, where being able to open the file in an editor is worth more than being able to serve it in one request.

An asset block declaring version 2.0 and Quinvert as the generator, a scene index of 0, one scene listing every node, one node per mesh, one mesh per OBJ group, and per mesh a single primitive with mode 4, a POSITION attribute and an indices accessor. Then the accessors, the buffer views and one buffer.

It is pretty-printed with two-space indentation, which makes it about a third larger than minified and readable without a formatter. For a document you are about to edit that is the right default; running it through a minifier is one command and reversing an unformatted 40,000-line JSON file is not.

glTF allows three ways to store vertex data: a separate .bin file, a base64 data URI in the buffer's uri field, or the binary chunk of a GLB. A conversion produces one file, so the data URI is the only option that keeps the output self-contained, and it is what is written.

Two consequences follow. The file is roughly a third larger than the same bytes stored binary, because base64 costs four characters per three bytes — acceptable for a working document and wasteful for delivery. And every tool that reads glTF handles it: gltf-transform, the validator and three.js all resolve embedded buffers without special configuration.

The document has no materials array, because the OBJ's MTL file is not read. Adding one is four lines: a materials array containing an object with a pbrMetallicRoughness block and a baseColorFactor of four numbers, then a material property on the primitive giving its index.

That gets you a coloured, correctly lit model in any glTF viewer without touching the geometry. Textures are a larger job, because they need images, samplers, textures and — critically — TEXCOORD_0 data that this conversion did not produce. If your OBJ had UVs and you need them, the honest route is Blender rather than a hand edit.

Every o or g line starts a new group, and each group becomes a named mesh. That name is the only piece of non-geometric information that crosses the conversion, and in a document you are going to edit it is what makes the difference between finding the part you meant and counting nodes.

A group with no name in the source gets no name in the output either. The mesh is written without a name property, and the node that references it carries nothing but the mesh index, so anything downstream has to invent a label for it. If the glTF is going to be read or edited by hand afterwards, name the groups in the OBJ first — a text edit there is easier than reconciling anonymous meshes in the JSON later.

The output is written against the parts of the specification validators actually enforce. Buffer views are padded so that every accessor byte offset is a multiple of its component size, which is a requirement rather than a courtesy and a common cause of validator errors in hand-rolled writers. Every POSITION accessor carries min and max, which is required and which viewers use to frame the model.

A stride of zero is treated as tightly packed rather than as a stride equal to the element size, which is what the specification says and what several readers get wrong in the opposite direction. If you run the Khronos glTF Validator over the result, the interesting output is not errors but the info-level note that the meshes have no normals — which is true, and which the specification handles by telling viewers to compute flat ones.

Faces with four or more corners are fan-triangulated from the first corner. That is correct for convex quads and n-gons, which is what these files contain in practice, and it can produce overlapping triangles on a concave face — a limitation worth knowing if your OBJ came from a tool that emits complex polygons.

Negative face indices are resolved while reading, since they count backwards from the most recent vertex and cannot be interpreted out of order. Vertices are then welded per group at six decimal places, so a group that referenced twelve of a four-thousand-vertex file carries twelve vertices in the glTF rather than four thousand.

Base64 inflation on the buffer, plus pretty-printed JSON around it. For a geometry-only model the buffer dominates, so expect roughly a third more bytes than the same model as GLB, before any compression.

That is the correct trade at this point in a pipeline and the wrong one at the end of it. The usual shape of the work is: convert to glTF here, edit or process it, then produce the GLB as the final artefact — either by converting back or by having gltf-transform write it, which is also where Draco or meshopt compression belongs.

If nothing is going to happen to the file between conversion and delivery, go to GLB directly. It is smaller, it is one request, and the editability you are paying for with the extra bytes is worth nothing if nobody opens it.

Choose glTF when there is a next step: a material to add, a validator to satisfy, a transform pass to run, or a repository where a text file diffs and a binary one does not. Both conversions run entirely in your browser with no engine to download, so the choice costs nothing but the extension.