Common 3D Conversion Errors and How to Fix Them
Every 3D format stores data differently. When you convert between formats, something will eventually go wrong. This guide covers the errors that actually happen in production, explains why each one occurs, and walks through the fix.
Why Conversions Break
You uploaded a perfectly good FBX file, hit convert, and the result came out wrong. The textures vanished. The model is enormous. The character is lying on its side. The skeleton fell apart. Sound familiar?
These problems are not random. Each one traces back to a specific mismatch between how two file formats represent 3D data. Once you understand the mismatch, the fix is usually straightforward.
Missing Textures After Conversion
This is the single most common conversion error. You convert a file and the result is plain gray or white geometry with no textures. The shape is correct, but all the surface detail is gone.
Why it happens
3D formats handle texture references in fundamentally different ways. OBJ files store texture paths in a separate MTL file. FBX files can either embed texture bytes directly in the file or reference them by file system path. glTF JSON files reference textures by relative URI, while GLB files embed everything in a single binary.
When a converter reads texture paths, it tries to locate
the image files on disk. If the MTL file points to
C:\Users\artist\Desktop\textures\diffuse.png,
that path only works on the original author's machine.
On your machine, the file does not exist, so the
converter silently drops the texture.
FBX files exported from 3ds Max and Maya often use absolute paths. FBX files exported with the "Embed Media" option enabled store the texture bytes inside the file itself, which avoids the path problem entirely. However, not every FBX exporter enables embedding by default.
How to fix it
- OBJ files: Place the .obj file, the
.mtl file, and all referenced texture images in the
same folder. Open the MTL file in a text editor and
verify that the
map_Kd,map_Ks, andmap_Bumplines use filenames only, not full paths. ReplaceC:\Users\...\diffuse.pngwith justdiffuse.png. - FBX files: Re-export from your authoring tool with the "Embed Media" checkbox enabled. In Blender, this option is in the FBX export dialog. In 3ds Max, it is under "Embed Media" in the FBX exporter settings.
- When uploading multiple files: Bundle the model file and its textures in a ZIP archive. Most converters, including Polyforge, can read ZIP archives and resolve texture paths within them.
- GLB as a target format: Converting to GLB embeds all textures in a single binary file. Once you have a valid GLB, textures can never go missing because they are part of the file itself.
map_Kd. If
those lines contain backslashes or drive letters, the
paths are absolute and need to be fixed.
Materials That Convert Wrong
Textures are present but the surface looks completely different from the original. Metals appear flat. Glass turns opaque. The whole model looks too dark or washed out.
PBR workflow mismatch
Modern 3D rendering uses Physically Based Rendering (PBR). There are two PBR workflows that are not directly interchangeable: metallic/roughness and specular/glossiness.
The glTF 2.0 specification uses metallic/roughness as its core material model. FBX files from older tools often use the Phong or Lambert shading models, which have no concept of metalness or roughness at all. When you convert a Phong material to glTF's PBR model, the converter has to approximate values that did not exist in the original. Specular highlights, glossiness maps, and ambient colors do not map one to one onto metallic and roughness parameters.
For specular/glossiness materials, the mathematical relationship is: glossiness = 1 minus roughness. Inverting the glossiness map gives you a roughness map, though you may need to adjust values by 10 to 20 percent because gamma correction affects the perceived brightness.
Blender's export requirement
Blender's glTF exporter only recognizes materials built with the Principled BSDF shader node. If your material uses a Diffuse BSDF, a Glossy BSDF, or a custom node group, the exporter will either skip the material entirely or export it as a plain white surface. The fix is to rebuild the material using a Principled BSDF node before exporting. Connect your base color, metallic, roughness, and normal map textures to the corresponding inputs on the Principled BSDF node.
FBX PBR limitations
The FBX format has no standard PBR material definition. When converting FBX to glTF using tools like FBX2glTF, the converter currently supports only the Stingray PBS material format. FBX files using other material types (Standard, Physical, Arnold) may lose metallic and roughness data. If your FBX materials are not converting correctly, import the FBX into Blender first, rebuild the materials with Principled BSDF, then export to glTF.
OBJ material limitations
The OBJ/MTL material format predates PBR entirely.
MTL files define diffuse color (Kd),
specular color (Ks), specular exponent
(Ns), and opacity (d).
There are no roughness or metallic fields. Converters
must approximate: the specular exponent gets mapped
to a roughness value, and metalness is typically set
to zero. The result will always look different from
a PBR original. For accurate PBR material transfer,
use glTF or GLB as your interchange format.
Model Is the Wrong Size
You open the converted file and the model is either microscopic or fills the entire viewport. The geometry is correct, the proportions look right, but the overall scale is off by a factor of 100 or 1000.
Why it happens
The glTF specification defines all distances in meters. FBX files can use centimeters, millimeters, inches, or any other unit, stored as metadata in the file header. If a converter does not read or does not apply that unit metadata, a model authored in centimeters will appear 100 times too large in any glTF viewer.
Blender adds another layer of complexity. By default, Blender's FBX exporter applies a scale factor of 100 to match the fact that Blender works in meters internally while FBX traditionally uses centimeters. If the receiving application also applies its own unit conversion, the model gets scaled twice and ends up at 10,000 percent of the intended size.
The FBX2glTF command line tool has a documented behavior where it creates a root node and scales the first children down to 0.01 to compensate for the centimeter to meter conversion. If you did not expect this, your model appears tiny.
How to fix it
- Check your export settings. In Blender, open the FBX export dialog and look at the "Scale" field. For glTF conversion, set it to 1.0 and make sure "Apply Unit" is enabled. For glTF export directly from Blender, the built in glTF exporter handles units automatically.
- Verify units in your source file. Open the file in your authoring tool and check what unit system is set. In 3ds Max, go to Customize > Units Setup. In Maya, go to Window > Settings > Preferences > Settings and check the Working Units section.
- Apply scale in your authoring tool. If the model is already at the wrong scale, apply the scale transform so it becomes part of the geometry. In Blender: select the object, press Ctrl+A, and choose "Scale." This resets the scale to 1.0 while keeping the geometry at its current visual size.
Model Is Rotated or Flipped
The model loads but it is lying on its back, facing the wrong direction, or rotated 90 degrees. This is one of the most frustrating conversion issues because the geometry and materials look fine, but the orientation is completely wrong.
Why it happens
3D applications disagree on which direction is "up." There are two common conventions:
- Y-up: Used by glTF, Unity, Maya, and most web 3D renderers including three.js. The Y axis points upward, Z points toward the viewer.
- Z-up: Used by Blender, 3ds Max, and many CAD tools. The Z axis points upward, Y points away from the viewer.
When converting between these systems, a 90 degree rotation on the X axis is required. Most converters handle this automatically. But some tools apply the rotation at the wrong level in the scene hierarchy, leaving individual objects or bones at the wrong angle even though the root node looks correct.
FBX files complicate this further because the format stores its own axis metadata. A single FBX file can claim to be Y-up or Z-up regardless of which tool created it. If the converter reads the metadata and applies a correction, but the metadata was wrong in the first place, you get a double rotation.
How to fix it
- Before export: Apply all rotations in your authoring tool. In Blender, select everything, press Ctrl+A, and choose "Rotation." Export with the correct axis settings: for glTF, Blender's exporter defaults to Y-up, which is correct. For FBX destined for glTF conversion, use "Y Forward, Z Up" in the export dialog.
- After conversion: If the model is
rotated exactly 90 degrees on one axis, apply a
counter-rotation. In three.js, this is
model.rotation.x = -Math.PI / 2. In Unity, set the X rotation to -90 in the import settings. - DAE/COLLADA files: The COLLADA
format stores an
<up_axis>tag in the header. If the model imports wrong, check this tag. It should read<up_axis>Y_UP</up_axis>for Y-up tools or<up_axis>Z_UP</up_axis>for Z-up tools.
Faces Are Inside Out
Parts of the model appear black, invisible, or show strange lighting. When you orbit around the model, the missing faces become visible from the back side. The surface normals are pointing inward instead of outward.
Why it happens
Every triangle in a 3D mesh has a front face and a back face, determined by the order of its vertices. The OBJ specification defines vertices in counterclockwise order when viewed from outside the object. glTF uses the same counterclockwise convention. But not every exporter follows the rules precisely.
Applying a negative scale in any axis (such as mirroring an object by scaling X to -1) reverses the vertex winding order. The geometry looks correct in tools that render both sides, but after export, faces that were flipped by the negative scale appear inside out.
Some converters also struggle with meshes that have inconsistent normals, where some faces point outward and others point inward on the same object. This typically happens when Boolean operations or mesh merges leave behind conflicting face directions.
How to fix it
- Before export: In Blender, enter Edit Mode, select all faces (A), then go to Mesh > Normals > Recalculate Outside (Shift+N). This unifies all normals to point outward based on the mesh topology.
- Apply transforms: If you used a negative scale to mirror an object, apply the scale before exporting (Ctrl+A > Scale in Blender). This bakes the negative scale into the vertices and fixes the winding order.
- In the viewer: As a temporary
workaround, you can disable backface culling in
your renderer. In three.js, set
material.side = THREE.DoubleSide. This renders both faces of every triangle, hiding the normal issue at the cost of double the draw calls.
Animation or Skeleton Breaks
The static mesh converts fine, but the animation is missing, distorted, or the bones are in the wrong position. The character may appear in a T-pose, have limbs bending the wrong direction, or have a skeleton that is scaled differently from the mesh.
Why it happens
Animation data is the most fragile part of any 3D conversion. FBX stores animation using a rich set of features: constraint chains, inverse kinematics (IK) solvers, animation layers, and driver expressions. The glTF format supports only basic keyframed transforms (translation, rotation, scale) and morph target weights.
When a converter encounters IK chains or constraint driven animation, it has two choices: skip the data entirely, or "bake" it by evaluating the animation at every frame and recording the resulting transforms. Baking preserves the visual result but produces much larger files and loses the ability to edit the animation afterward.
Bone rotation issues are another frequent problem. FBX, glTF, and each 3D tool have their own conventions for bone rest poses and rotation orders. A bone that is oriented correctly in Maya may appear rotated 90 degrees in a glTF viewer because the two systems define the bone's local axis differently.
How to fix it
- Bake all animations before export. In Blender's glTF export dialog, enable "Always Sample Animations." In Maya, use the "Bake Animation" option in the FBX exporter. This converts all constraints, IK, and expressions into per-frame keyframes.
- Simplify the rig. Remove any bones that are not directly deforming the mesh before export. Helper bones, IK targets, and control bones that drive other bones through constraints do not translate to glTF. Delete them and bake their effects into the deform bones.
- Check bone orientations. If bones are rotated wrong after conversion, try enabling "Force Connect Children" and "Automatic Bone Orientation" in Blender's FBX import settings. Then re-export to glTF.
- Morph targets: glTF supports morph targets (blend shapes) directly. FBX also supports them. But the conversion between the two can fail if the morph targets reference different vertex counts or use sparse storage that the converter does not handle. Verify the vertex count of each morph target matches the base mesh.
resample function to remove redundant
keyframes after baking.
Geometry Errors and Broken Meshes
The model has visible holes, missing faces, overlapping triangles, or the mesh breaks apart at seams. This category includes structural problems in the mesh geometry itself, not just rendering issues.
Non-manifold geometry
A manifold mesh is one where every edge is shared by exactly two faces and every vertex connects to a closed ring of faces. Non-manifold geometry violates these rules: edges shared by three or more faces, single edges with only one face, vertices connecting otherwise separate mesh regions, or zero-area faces.
Many 3D tools tolerate non-manifold geometry during editing. But conversion tools and renderers often do not. STL files for 3D printing require watertight (fully manifold) meshes because the slicer needs to determine inside from outside at every point. Converting a non-manifold mesh to STL or 3MF will produce holes in the print, failed slicing, or garbage geometry.
Overlapping vertices and degenerate triangles
Some exporters create duplicate vertices at the exact same position, or triangles where two or more vertices share the same location (zero-area triangles). The glTF specification explicitly forbids accessors with NaN or infinity values. Some validators will flag degenerate triangles as errors. In practice, these are usually harmless for rendering but can cause issues with physics engines, raycasting, and mesh decimation algorithms.
How to fix it
- Clean up before converting. In Blender: Edit Mode > Mesh > Clean Up > "Merge by Distance" to remove duplicate vertices. Then "Degenerate Dissolve" to remove zero-area faces.
- Fix non-manifold edges. In Blender: Edit Mode, Select > All by Trait > Non-Manifold. This highlights every non-manifold element. Fix them by filling holes (F key), removing internal faces, or merging stray vertices.
- For 3D printing specifically: Run
the mesh through a repair tool before conversion.
Meshmixer's "Inspector" tool automatically detects
and patches holes. Microsoft's free 3D Builder
application repairs STL files on import. For
programmatic repair, the Trimesh Python library
has a
fill_holes()function.
Format Limitations That Cause Silent Data Loss
Some conversions are inherently lossy because the target format cannot represent everything the source format contains. No amount of converter quality can fix this. Understanding what each format cannot store helps you choose the right conversion path and set realistic expectations.
| Feature | GLB/glTF | FBX | OBJ | STL |
|---|---|---|---|---|
| PBR materials | Yes (metallic/roughness) | Partial (no standard PBR) | No (Phong only) | No |
| Embedded textures | Yes (GLB) | Yes (binary with embed) | No (external only) | No |
| Skeletal animation | Yes | Yes | No | No |
| Morph targets | Yes | Yes | No | No |
| Vertex colors | Yes | Yes | Non-standard extension | No (binary STL: partial) |
| Multiple UV sets | Yes | Yes | Yes | No |
| Scene hierarchy | Yes | Yes | Groups only | No |
| Cameras and lights | Cameras: core spec; lights: extension (KHR_lights_punctual) | Yes | No | No |
Converting to STL always loses materials, textures, and animation. STL stores only triangle geometry. This is by design: the format exists for 3D printing, where material rendering is irrelevant. If you need to preserve color for 3D printing, use 3MF instead.
Converting to OBJ loses animation and PBR materials. OBJ is a static geometry format with a material system from the 1990s. It works well for archival and for tools that do not support modern formats, but it should not be your first choice for web or game use.
Converting FBX to glTF can lose IK chains, constraints, and material fidelity. FBX is the richest format in this table, but its material system is poorly standardized. Converting from FBX through Blender (import FBX, fix materials, export glTF) tends to produce better results than direct FBX to glTF converters.
USDZ has specific requirements for Apple AR.
AR Quick Look on iOS requires models under 200,000
polygons with no more than one set of UV coordinates
per material (though iOS 16 and later support multiple UV
sets). Exceeding these limits causes the model to fail
silently in Safari. The file also must be
served with the correct MIME type
(model/vnd.usdz+zip) and the
.usdz file extension must be present in
the URL.
How to Validate After Converting
Never assume a conversion succeeded just because the tool did not show an error. Many conversion issues are silent: the file is valid but the data is wrong. Build a validation habit into your workflow.
Visual inspection
Open the converted file in at least one viewer that is not your authoring tool. For GLB and glTF files, the Babylon.js Sandbox and the three.js editor both render PBR materials accurately. Compare textures, material properties, scale, and orientation against the original.
Specification validation
The Khronos glTF Validator checks converted glTF and GLB files against the full specification. It catches issues that viewers might silently ignore: accessor alignment errors, out of bounds buffer references, missing required extensions, and invalid texture formats. Run it on every converted file before distributing.
What to check
- Polygon count: Compare the triangle count of the source and result. If they differ significantly, faces may have been lost or duplicated during conversion.
- Material count: Verify the number of materials matches. Missing materials indicate failed texture resolution or unsupported material types.
- Bounding box size: Check the model's dimensions. If the bounding box is wildly different from expected, you have a scale or unit issue.
- Animation playback: Play back every animation clip. Check for jittering (precision loss), missing keyframes, and bones that do not move when they should.
Quick Reference by Format Pair
This table lists the most common conversion paths and the specific errors you should watch for on each one.
| Conversion | Watch for | Recommended fix |
|---|---|---|
| FBX to GLB | Scale 100x off, missing PBR materials, lost IK | Check export units, use Principled BSDF, bake animations |
| OBJ to GLB | Missing textures, no PBR, flat shading | Bundle MTL + textures in ZIP, fix absolute paths |
| GLB to OBJ | Loses animation, PBR degrades to Phong | Accept material loss, export static geometry only |
| STL to GLB | No materials or textures in result | Add materials after conversion; use 3MF for color |
| GLB to USDZ | AR Quick Look rejects model, dark materials | Stay under 200K polys, correct MIME type, single UV set |
| glTF to GLB | Broken texture references if files were moved | Keep glTF + bin + textures together, or bundle as GLB |
| DAE to GLB | Axis flip, duplicate IDs, schema errors | Check up_axis tag, fix duplicate mesh IDs in XML |
For any conversion not listed here, Polyforge's converter handles the most common format pairs directly in your browser. Upload your file, select the target format, and download the result. No installation, no file uploads to a server, no waiting.
Frequently Asked Questions
Why are my textures missing after converting OBJ to GLB?
OBJ files reference textures through a separate MTL file, which points to image files by path. If the MTL file is missing, the paths inside it are wrong, or the texture images are not in the expected location, the converter cannot find them. The fix is to place the OBJ, MTL, and all texture files in the same folder, or bundle them in a ZIP before converting. GLB embeds textures in the binary, so once the conversion succeeds, the textures stay with the file.
Why is my converted model 100 times too large or too small?
This is a unit mismatch. FBX files can store scene units in centimeters, millimeters, or inches, while glTF defines all distances in meters. If the converter does not account for the original unit, a model authored in centimeters will appear 100 times too large in a glTF viewer. Check the export settings in your authoring tool and make sure units are set correctly before converting.
Why does my model appear rotated 90 degrees after conversion?
Different formats and tools use different coordinate systems. Blender and 3ds Max use Z-up, while glTF and Unity use Y-up. When converting between these systems, the model can end up rotated 90 degrees on the X axis. Apply all rotations in your authoring tool before exporting, and verify the axis settings in the export dialog match the target format's expectations.
Can I recover animations when converting FBX to glTF?
Simple skeletal animations and keyframed transforms convert reliably. However, FBX supports features that glTF does not: constraint-driven animation, IK chains, and blend shape animations driven by bone transforms. These must be baked to per-frame keyframes before export. In Blender, enable the bake animation option in the export dialog.
Why does STL conversion lose all colors and materials?
The STL format stores only triangle geometry. It has no support for materials, textures, vertex colors, or UV coordinates. Any visual information from the source model is permanently lost during conversion to STL. If you need to keep materials, convert to GLB, glTF, or FBX instead. For 3D printing with color, use 3MF.
How do I validate a glTF or GLB file after conversion?
Use the official Khronos glTF Validator to check for specification compliance. It catches accessor alignment errors, buffer bounds issues, missing required extensions, and invalid texture formats. For visual verification, open the file in the Babylon.js Sandbox or the three.js editor and compare against the original.