Daniel's been digging through the 3D format landscape and, honestly, I think he's describing a problem everyone hits the moment they try to do anything beyond dropping a GLB into a web viewer. He writes — and I'm going to read this nearly in full because the way he's organized it is half the value — "Everyone who touches 3D assets eventually discovers that GLB is not the only format, and the wider landscape is a mess of decades-old standards, vendor formats, and things that only exist because one company needed them. I'd like Herman and Corn to give a proper tour of the 3D file format landscape, organized by what you're actually trying to do."
He breaks it into buckets. For real-time and web work: glTF and GLB as the runtime-friendly modern default, and why it's called the JPEG of 3D. USD and USDZ and Apple's role in pushing it. What three.js, model-viewer, and Babylon actually want to be handed. For game engines and DCC interchange — and DCC here is digital content creation, Maya, Blender, that world — FBX and why it persists despite being a proprietary Autodesk format with a semi-reverse-engineered spec. OBJ with its companion MTL file and why splitting geometry from materials across two files causes so much grief. COLLADA as the standard that was meant to win and didn't. Alembic for baked animation. And engine-native asset formats in Unity and Unreal that aren't really interchange formats at all.
Then he wants the scanning and point data side: PLY, E57, LAS. And the 3D printing angle, which he says deserves real time — STL as the lowest common denominator, nothing but triangle soup with no units, no color, no material, no metadata, and why it survives anyway. Then the formats that do carry color and material: 3MF as the modern zipped XML format. AMF as the standard that tried and mostly failed. OBJ and PLY carrying color via textures or per-vertex color respectively, and how multi-material and full-color printers actually consume that data.
And then the closer: what survives a conversion and what silently gets dropped — rigs, animation, PBR maps, units, scene hierarchy — and a practical decision guide. Given what you're building, which format should you be exporting.
That is... a lot of formats.
It is, and I love this question because it's organized exactly the way you'd want someone to organize it — by what you're doing, not by what the format claims to support. And the thing that makes the 3D format landscape genuinely different from images is that a JPEG is a JPEG. You open it, you see pixels. The format's job is done. But a 3D file — depending on what you're doing — might need to carry rigging data for a character's skeleton, or material definitions that describe how light physically bounces off a surface, or the exact position of every vertex at every frame of a fluid simulation. Those are fundamentally different data structures, and no single format handles all of them well.
So the fragmentation isn't just historical accident. It's that the data requirements are actually different.
Right, but the historical accident part is real too. FBX exists because Kaydara needed a format for Filmbox, their motion capture software, in the mid-nineties. Autodesk bought them in 2006 and now FBX is the de facto interchange format for half the industry despite being... well, we'll get to that. USD exists because Pixar needed to compose scenes with millions of assets across departments. STL exists because 3D Systems needed something for their stereolithography machines in 1987. Each of these was built for one company's immediate problem, and then the industry just... grew around them.
Like cities built on old cow paths.
And the hidden cost — and this is what I think Daniel's really getting at with the conversion survival question — is that every time you convert between formats, you're crossing between different data models. It's not like converting a PNG to a JPEG where you might see some compression artifacts. When you convert FBX to glTF, you can silently lose the entire skeleton hierarchy that drives your character's animation. The file opens. It looks fine. But nothing moves. And you don't find out until you're halfway through integration.
That's the nightmare scenario. Everything looks fine in the preview.
And the preview lies constantly. So let's walk through these buckets. Real-time and web first — that's where most people enter this mess, because they export something from Blender, they want it on a website, and someone tells them to use a GLB.
Which brings us to the JPEG of 3D claim. Is that actually fair?
It's fair in a specific way. glTF — and GLB is just the binary container version of glTF, single file instead of a JSON plus separate buffers and textures — was designed by the Khronos Group, the same consortium behind Vulkan and WebGL. They looked at what a runtime engine actually needs to render a 3D scene and built a format that delivers exactly that, as efficiently as possible. PBR materials are built into the spec — metallic-roughness model, base color, normal maps, occlusion, emissive. The binary data is structured so the GPU can basically ingest it directly without a heavy parsing step. That's the JPEG analogy: it's lossy in the sense that it doesn't carry authoring data, but it's optimized for delivery.
What does it not carry?
Scene composition, for one. glTF has a node hierarchy — you can parent objects — but it doesn't have the concept of layers or variants or assembly that USD has. It doesn't carry construction history. It doesn't carry NURBS surfaces or any of the parametric modeling data you'd have in a CAD file. It supports skinned animation — vertex weights and joint hierarchies — but many exporters, especially older ones, will strip constraints, IK targets, and blend shapes. So you get a character that moves, but the animator's carefully tuned rig is gone.
And for the web frameworks Daniel mentioned — three.js, model-viewer, Babylon — glTF is what they actually want?
It's what they're built around. three.js has a GLTFLoader that's essentially the first thing you reach for. model-viewer is a web component from Google that wraps a glTF file in a viewer with controls, annotations, AR — it's glTF-native. Babylon.js has excellent glTF support including extensions for things like KHR materials transmission for glass and thin-film effects. You can feed other formats to these engines — three.js has an FBXLoader, an OBJLoader — but you're going through a JavaScript parser that's reconstructing the scene graph, and it's slower and lossier than handing them the format they were designed to consume.
So for web delivery, glTF is the answer. But then Apple shows up with USDZ.
And this is where it gets confusing, because USD and USDZ are not the same thing, and neither is really a web format. USD — Universal Scene Description — was developed by Pixar for their film pipeline. It's a scene composition framework. You can reference other files, override properties, layer variations on top of a base model without duplicating data. It's incredibly powerful for managing the complexity of a feature film where thousands of artists are touching the same assets. Apple adopted USDZ — which is a zip of USD files — as the format for AR Quick Look on iOS, starting in 2018.
So Apple took a film pipeline format and made it the AR format.
And the result is that a lot of tools export USDZ as a single mesh with a texture, which completely misses the point of USD's scene composition capabilities. It's like taking a database and exporting it as a screenshot. The file extension is the same, but what's inside bears no resemblance to what USD was designed to do. For actual web AR, glTF with the right extensions is catching up fast — three.js and model-viewer both support WebXR. USDZ matters if you're targeting iOS AR Quick Look specifically. Otherwise, it's overkill at best and misleading at worst.
So glTF for web delivery, USD for film pipeline assembly, and the USDZ thing is mostly Apple's AR play. That's the real-time bucket. Now the game engine and DCC interchange bucket, which is where the pain really lives.
FBX. The format everyone loves to hate and nobody can stop using. It's proprietary — Autodesk owns it — and for years the spec was not publicly documented. The community reverse-engineered it. Autodesk finally released documentation in 2013, but they've changed the spec without warning multiple times, and if you're using an older version of an FBX SDK, your files might just... not open.
So why does it persist?
Because it's the only format that Maya, Blender, and 3ds Max all read and write with reasonable fidelity for rigs, animation, and scene hierarchy. If you're moving a character from Maya to Unreal Engine, FBX carries the skeleton, the skin weights, the animation curves, the blend shapes — most of them, anyway. It carries the material assignments, though PBR support is limited and inconsistent across implementations. It's not great at anything, but it's adequate at the things that break if they're missing.
The lowest common denominator that actually works.
For a certain definition of works. A Blender-to-Unreal pipeline using FBX will typically lose IK targets and constraints. The bones are there, the animation plays, but the control rig the animator built is gone, so if you need to modify the animation in Unreal, you're working with raw joint transforms instead of the intuitive controls. And if you go FBX to glTF for a web viewer, you might lose the skeleton entirely depending on the exporter.
And then there's OBJ, which is somehow still everywhere.
OBJ is the ASCII workhorse. It's human-readable — you can open it in a text editor and see vertex positions, normals, texture coordinates, face definitions. It's universally supported. And it does almost nothing. No rigs. No animation. No scene hierarchy — everything is one flat list of objects. Materials go in a separate MTL file that references texture maps, but it's the old diffuse-specular model, not PBR. The two-file split means OBJ and MTL get separated constantly — you download a model, import the OBJ, and everything is gray because the MTL file is in a different folder or referenced with an absolute path from someone else's machine.
I've lived that exact gray-model moment.
Everyone has. And yet OBJ survives because for static geometry interchange, it's good enough, and good enough with zero friction beats excellent with setup overhead. You can email someone an OBJ and they can open it. That's its superpower.
COLLADA was supposed to fix all of this.
COLLADA was the Khronos Group's first attempt at a universal interchange format, released in 2004. XML-based, supported rigs, animation, physics, shaders — it was ambitious. But the spec was enormous, implementations were inconsistent, and the XML verbosity meant files were huge and slow to parse. By the time the ecosystem stabilized, glTF had emerged as the simpler, binary, runtime-focused successor. COLLADA isn't dead — it's still used in some CAD and GIS workflows — but for real-time and game engine work, it lost.
And Alembic is a different beast entirely.
Alembic is not an interchange format in the way FBX is. It was developed by Sony Pictures Imageworks and Industrial Light & Magic, released in 2011, and it does one thing: it bakes animation. Every vertex position for every frame is stored. No rigs, no constraints, no expressions — just the final deformed geometry over time. It's essential for VFX pipelines where you're passing fluid simulations from Houdini to Maya, or cloth simulations between departments. The data is immutable — you can't edit the animation, you can only play it back. But for caching, it's incredibly efficient, and it supports things like velocity vectors for motion blur.
So Alembic is the answer when you don't need to modify the animation, just render it.
And then there are the engine-native formats — Unity's dot asset and dot prefab, Unreal's dot uasset. These are not interchange formats at all. They serialize the entire engine object model — physics bodies, blueprint graphs, material instances, scripting references. Exporting from Unity to FBX strips all of that. The FBX that comes out is just the mesh and the animation. Everything that made it work in Unity is gone.
Which is why you never go engine-native to engine-native. You always go back to the source.
Always. And that's a rule we'll come back to.
Let's shift to the scanning and point data bucket, because this is a world I think fewer people touch but it's got its own format wars.
And it's a fundamentally different kind of data. These aren't meshes in the traditional sense — they're point clouds, millions or billions of individual points in space, each with attributes like color, intensity, classification. PLY is the oldest of these, developed at Stanford's graphics lab in the mid-nineties. It supports both ASCII and binary, stores vertex positions, colors, normals, and optionally faces if you've reconstructed a mesh. Per-vertex color is native — each point can have an RGB value. It's used heavily in 3D scanning because it's simple and widely supported.
But it doesn't carry the metadata that LIDAR scanners produce.
Right. That's where E57 and LAS come in. E57 is an ASTM standard — E2807, released in 2011 — designed specifically for 3D imaging data exchange. It stores point clouds with per-point attributes in a compressed binary format. You get intensity, color, time stamps, and crucially, it can store multiple scans in a single file with coordinate system metadata. So if you've done a LIDAR survey of a building with twenty scan positions, all twenty are in one E57 file with their relative positions preserved.
And LAS?
LAS is the ASPRS standard — the American Society for Photogrammetry and Remote Sensing. It's older than E57, originally designed for aerial LIDAR surveying. The key thing LAS adds is classification. Each point gets a class label — ground, low vegetation, medium vegetation, high vegetation, building, water, and so on. Version 1.4, from 2011, supports fifteen classification types. It also stores return number and scan angle, which matter for aerial surveys where a single laser pulse might hit a tree branch, then the ground, and you need to distinguish those returns.
So PLY is for scanned meshes, E57 is for terrestrial LIDAR with multiple setups, LAS is for aerial surveying with classification.
None of them convert well to each other. Converting PLY to E57 loses face information if the PLY had mesh data — E57 doesn't store faces. Converting E57 to PLY loses the multiple-scan organization and classification. And none of these formats carry color or material in a way that survives conversion to game engine formats. You can get the points into a game engine, but they're just points — no PBR materials, no textures.
Which brings us to 3D printing, where the format question gets even stranger because the requirements are almost the inverse of real-time rendering.
STL. 1987. 3D Systems needed a format for their stereolithography machines, and they created something that is simultaneously the most successful and most limited 3D format in history. It's triangle soup. A list of triangles defined by three vertices and a face normal. That's it. No units. No color. No material. No metadata. No way to specify infill, support structure, print temperature, nothing.
It's still the default for almost every consumer 3D printer.
Because every slicer reads it, every printer accepts it, and for single-material FDM printing — which is most of what people do — that's all you need. The slicer figures out infill and supports. The material is whatever filament you loaded. But the unit problem is insidious. STL has no concept of scale. A model exported in millimeters will be interpreted as meters by a different slicer, and suddenly your twenty-millimeter calibration cube is twenty meters wide. Or worse, it's a thousandth the size and looks like it didn't print.
That's the thousand-X scale error you mentioned.
It happens constantly. Someone downloads a model from Thingiverse, slices it, and the printer either chokes on a microscopic object or tries to print something the size of a car. The only fix is knowing what units the original modeler used and scaling manually.
What should people use instead?
3MF. The 3D Manufacturing Format, developed by Microsoft and the 3MF Consortium, released in 2015. It's a zipped XML format — so it's compact, and you can inspect it with standard tools. It carries materials, colors, units, print metadata, and supports multiple models in a single file. It supports PBR materials and texture mapping. The killer feature is extensibility — you can add custom metadata without breaking existing readers, so printer manufacturers can include their own settings. It's what industrial printers expect.
There was a format before 3MF that tried to do this.
AMF. Additive Manufacturing File Format, standardized as ASTM F2915 in 2011. XML-based, and technically more ambitious than 3MF in some ways — it supports curved triangles, graded materials that transition from one material to another, multiple materials in a single object. But the spec was complex, adoption was low, and when Microsoft threw its weight behind 3MF, the industry followed. AMF isn't dead, but it lost.
The format that tried and mostly failed, as Daniel put it.
The distinction matters because if you're doing multi-material or full-color printing, the format is the difference between getting what you designed and getting a single-color lump. Full-color printers like the Stratasys J850 or the Mimaki 3DUJ-553 consume 3MF or VRML with embedded texture maps. They need the color data per voxel or per surface region, and they need it in a format that maps textures to geometry. Per-vertex color from PLY doesn't cut it for these machines — they need texture coordinates and image maps.
If you export a full-color model as STL, you get one color. If you export as PLY with vertex colors, you get... maybe something, but not what the printer is designed to consume.
Right. PLY vertex color is fine for visualization — you can see the colors in a point cloud viewer — but a full-color printer's workflow expects texture-mapped 3MF. OBJ with MTL can carry texture maps, and some multi-material printers use that — the MTL file assigns different materials to different face groups, and the printer maps those to different extruders or resins. But it's fragile, and the MTL file has to be structured exactly the way the printer's software expects.
That's the landscape. Now the question Daniel really wants answered: when you convert between these formats, what silently dies?
Let's go through it systematically. Rigs — the skeleton, constraints, IK handles, control curves. Only FBX and COLLADA preserve these with any reliability, and even FBX drops constraints in many exporter implementations. glTF supports skinned animation — joint weights and transforms — but the control rig is gone. Alembic bakes everything to vertex positions, so the rig is irrelevant. STL, OBJ, PLY — no rig concept at all. If you need to modify animation after export, you need FBX or the source file.
Animation itself?
FBX, glTF, and Alembic all preserve animation, but differently. FBX preserves the curves and keyframes. glTF preserves joint transforms over time — it's baked but at the joint level, not the vertex level. Alembic bakes to vertices — every frame, every vertex position is stored. That's lossless for the final look but useless for editing. COLLADA preserves animation curves but the implementation inconsistencies mean it might not play back the same in different tools.
PBR materials.
glTF and 3MF preserve them natively — metallic-roughness workflow, base color, normal maps, occlusion, emissive. FBX has limited PBR support and it varies by SDK version. OBJ and MTL only handle diffuse, specular, and ambient — the old Blinn-Phong model. STL has nothing. If you go from a glTF with full PBR materials to OBJ, you lose everything that makes the surface look physically realistic. You get a flat diffuse color and maybe a specular highlight.
Units.
3MF and USD preserve units. glTF specifies meters as the default unit but doesn't enforce it — the exporter is supposed to set the scale. STL and OBJ have no unit concept at all. A millimeter is just a number. This is the source of the thousand-X error, and it's the most common catastrophic failure in 3D printing pipelines.
And scene hierarchy.
FBX and USD preserve it — parent-child relationships, groups, layers. glTF has a node hierarchy but no grouping or layering in the USD sense. OBJ flattens everything — every object is a separate named group but there's no hierarchy. STL flattens everything into one triangle soup. If you've organized a scene with fifty objects in a logical hierarchy and you export to STL, you get one undifferentiated blob.
The practical decision guide. You're building something. What do you export?
For real-time web delivery: glTF or GLB with PBR materials. Verify your animation export settings — test that blend shapes and skinned animation come through. If you're using model-viewer, GLB is the native format and everything else is a workaround. For AR on iOS specifically, USDZ is still the path of least resistance for Quick Look, but glTF is catching up.
For game engine import?
FBX is still the default for most pipelines, but test your rig and constraint fidelity before committing. Unreal Engine 5 has native glTF import now, and for static meshes with PBR materials, glTF is often cleaner. For characters with complex rigs, FBX is still the safer bet, but expect to lose IK targets and constraints. Always keep your source file.
For VFX and film pipelines?
Alembic for baked simulation and animation caches — fluids, cloth, anything where the final vertex positions are what matter. FBX for rigged characters that need to be modified downstream. USD for scene assembly when you're composing thousands of assets with overrides and variants.
For scanning and point clouds?
E57 or LAS for LIDAR data with classification and multiple scan positions. PLY for scanned meshes with vertex color. And accept that converting between these will lose the metadata that makes each one valuable — classification, scan organization, face data.
For 3D printing?
3MF if your printer supports it — and if you're doing anything with color, multi-material, or need reliable units, this is the answer. STL only for single-material FDM where you just need geometry and the slicer handles everything else. OBJ with MTL for multi-material printers that consume it, but verify the MTL structure matches what your printer's software expects. PLY vertex color for visualization, not for printing on full-color machines.
And the universal rule?
Always export from your source format. Never re-export from an intermediate. Maya to FBX to glTF loses more than Maya to glTF directly. Every conversion is a lossy process, and the losses compound. Test your pipeline with a known-good model that has rigs, animation, PBR maps, and hierarchy before you commit to it. The file will probably open. Whether it opens with everything intact is a different question.
There's no universal format because there's no universal 3D workflow. The format is a contract between the creator and the consumer.
Most of the pain comes from assuming the contract covers things it doesn't. STL doesn't promise units. OBJ doesn't promise animation. glTF doesn't promise scene composition. Pick the format that delivers what your downstream consumer actually needs, not what's easiest to export.
Which makes me wonder where this is all heading. We've got Gaussian Splatting and NeRF emerging as 3D representations that aren't meshes at all — they're neural representations. They need entirely new file formats. Is glTF going to absorb FBX and USD use cases, or are we just going to keep adding formats as new capture and rendering techniques appear?
I think the fragmentation is probably permanent, because the use cases keep diverging. GlTF is excellent at what it does — runtime delivery of PBR assets — but it's not trying to be a scene composition framework, and it shouldn't be. USD is excellent at scene assembly but it's not a runtime format. And NeRFs and Gaussian Splats are a different thing — they're not geometry, they're learned radiance fields. The formats for those are being invented right now, and they'll probably look nothing like what we've been discussing.
Which means the skill isn't knowing every format. It's knowing what data matters for what you're building, and verifying that it survived the trip.
That's the whole thing. The preview lies. Test the pipeline.
Thanks to our producer Hilbert Flumingtop for making this episode happen. This has been My Weird Prompts. If you've got a weird prompt you want us to tackle, email the show at show at my weird prompts dot com. We read every one.
We'll be back soon.
