What Happens When You Convert FBX to GLB?

Understanding the conversion starts with understanding what each format actually looks like on disk.

FBX binary structure. An FBX file starts with a 27 byte header containing the magic string "Kaydara FBX Binary", an endianness marker, and a version number (for example, 7400 for version 7.4). After the header, data is organized as a tree of node records. Each node has a name, a list of typed properties (integers, floats, strings, raw binary blobs), and nested child nodes. The entire scene graph, every mesh, material, texture, bone, and animation curve, lives somewhere in this tree. Array data like vertex positions can optionally be deflate compressed within the binary.

GLB binary structure. A GLB file has a 12 byte header followed by exactly two chunks. The first chunk is JSON and describes the entire scene: nodes, meshes, materials, animations, cameras, and how they reference each other. The second chunk is a raw binary buffer containing vertex positions, normals, UV coordinates, animation keyframes, and optionally embedded texture images. The JSON references specific byte ranges in the binary buffer through accessor and bufferView objects that specify data type, component count, stride, and offset.

This structural difference matters because GLB's binary buffer is designed to be uploaded directly to the GPU without parsing. A WebGL renderer can take a vertex position accessor and create a GPU buffer from it with minimal processing. FBX's nested node tree requires substantially more parsing before the data reaches the GPU.

This is the single biggest transformation in the conversion and the most common source of visual differences.

What FBX stores. FBX materials use the Phong or Lambert shading models. Phong materials have a diffuse color, a specular color, a shininess exponent (controlling the tightness of specular highlights), an emissive color, and an ambient color. Lambert materials are similar but without the specular component. Lambert's cosine law dates to 1760, Phong shading to the 1970s, and both describe how light bounces off a surface using empirical approximations rather than physical properties.

What GLB stores. GLB materials use glTF 2.0's PBR metallic roughness model. Each material has a base color, a metallic value (0 for non metals like plastic, 1 for metals like steel), a roughness value (0 for mirror smooth, 1 for completely matte), an optional normal map, an occlusion map, and an emissive map. This model describes the actual physical properties of a surface, which is why PBR materials look consistent under different lighting conditions.

How the conversion works. The converter must estimate PBR values from Phong parameters. A typical mapping looks like this:

• Roughness is derived from the shininess exponent. Higher shininess produces lower roughness. A common formula is roughness = sqrt(2 / (shininess * specularIntensity + 2)).
• Metallic is estimated by comparing specular and diffuse luminance. If the specular color is brighter than the diffuse color, the surface is likely metallic. Otherwise it is treated as a dielectric (non metal).
• Base color comes from the diffuse color for non metals or the specular color for metals.
• Emissive maps directly from FBX emissive to glTF emissive.

This mapping is an approximation. A chrome material in FBX with carefully tuned specular values will not look identical after conversion because the underlying lighting math is different. In practice, most materials look close enough for web delivery, but assets created for film or broadcast may need manual adjustment after conversion.

Textures transfer well between FBX and GLB, but two details catch people off guard: where the textures come from and which direction they face.

Texture sources. FBX files handle textures in two ways. They can embed texture image data directly inside the binary file, or they can store file path references pointing to external image files on disk. Embedded textures always survive conversion because the data is right there in the file. External references only work if the image files are accessible at those paths during conversion. If the converter cannot find the referenced files, the resulting GLB will have materials with missing textures.

GLB always embeds. A GLB file stores texture images as binary data inside the file's second chunk. This is one of GLB's key advantages for web delivery: a single file contains everything needed to render the model, with no external dependencies. The trade off is that embedding textures increases file size, especially if the original images are large or uncompressed.

The UV flip. FBX and glTF use different UV coordinate conventions. FBX places the texture origin (0, 0) at the bottom left corner of the image. glTF places it at the top left. Without correction, every texture in the converted file will appear vertically flipped. Most converters handle this automatically by transforming the V coordinate: v_out = 1.0 - v_in. If you see upside down textures after conversion, the UV flip was either skipped or applied twice.

Image formats. FBX commonly references PNG, JPEG, TGA, and BMP textures. GLB supports PNG and JPEG natively in the core specification, with WebP and KTX2 (Basis Universal) available through extensions. TGA and BMP textures are typically converted to PNG during the FBX to GLB process.

3D applications disagree about which direction is "up" and how big a unit is. FBX and glTF are no exception.

Axis conventions. Both FBX and glTF use right handed coordinate systems, but FBX allows each file to declare its own up axis. Files exported from Maya typically use Y up. Files from 3ds Max or some CAD tools use Z up. The FBX header stores this choice in its GlobalSettings node. glTF, by contrast, always uses Y up with +Z pointing toward the viewer and +X pointing right. The converter reads the FBX axis setting and applies a rotation matrix to align everything to glTF's Y up convention.

Unit scale. FBX defaults to centimeters as its base unit. glTF uses meters. A model that is 180 units tall in FBX (representing 180 centimeters) should be 1.8 units tall in GLB (representing 1.8 meters). The converter applies a scale factor of 0.01 to handle this. If your converted model appears 100 times too small or too large, the unit conversion was either skipped or applied incorrectly.

Why this matters for your scene. If you are loading the GLB into a three.js scene, a Babylon.js viewer, or a game engine, the coordinate and scale corrections mean the model should appear at the correct size and orientation without manual adjustment. Problems arise when the original FBX has non standard axis settings or when the exporting application wrote incorrect unit metadata.

Animation is where the two formats diverge most dramatically in how they represent the same motion.

FBX animation model. FBX stores animations as a hierarchy of stacks, layers, and curves. At the bottom level, each animated property (say, the X rotation of a bone) has its own animation curve: a mathematical function defined by keyframes with time, value, and tangent data. FBX supports constant, linear, and cubic interpolation, with cubic curves using a tension/continuity/bias (TCB) tangent system that gives animators fine control over the shape of the motion between keyframes. A five second walk cycle might need only 20 to 30 keyframes per channel because the curves fill in the motion between them.

glTF animation model. glTF uses a sampler/channel architecture. Each channel binds a sampler to a node property (translation, rotation, scale, or morph weights). The sampler stores input timestamps and output values as typed arrays. glTF supports three interpolation modes: STEP (no interpolation), LINEAR (straight line between keyframes, with spherical linear interpolation for rotations), and CUBICSPLINE (cubic polynomial with explicit in/out tangents stored alongside each keyframe value).

What happens during conversion. Most converters, including three.js and FBX2glTF, "bake" FBX animation curves by sampling them at a fixed rate, typically 30 frames per second. This means a 5 second animation that had 25 compact curve keyframes in FBX becomes 150 sampled keyframes per channel in GLB. The motion looks the same when played back, but the data is fundamentally different: you get a dense list of values instead of a compact mathematical description.

The file size impact. Baked animations can increase the animation portion of the file by 10 to 50 times compared to the original curves. A character with 50 bones, each with translation, rotation, and scale channels, produces 150 channels. At 30 samples per second over 10 seconds, that is 45,000 keyframes for rotation alone (stored as quaternions: 4 floats each). This is the primary reason why GLB files with animations are often larger than their FBX sources.

Rotation handling. FBX stores rotations as Euler angles (separate X, Y, Z rotation curves), which can suffer from gimbal lock. glTF stores rotations as quaternions, which avoid gimbal lock entirely. The converter samples the FBX Euler rotations, converts each sample to a quaternion, and writes quaternion keyframes to the glTF. This is actually an improvement in mathematical representation, even though it comes at the cost of denser data.

Skeletal data. FBX represents bones as nodes with FbxSkeleton attributes arranged in a parent/child hierarchy. Each vertex in a skinned mesh has a list of bone influences (which bones affect it) and corresponding weights (how strongly each bone pulls the vertex). glTF represents this identically in concept: bones become nodes referenced by a skin object, and vertex weights and joint indices are stored in WEIGHTS_0 and JOINTS_0 accessors. This part of the conversion is straightforward, and skeletal data transfers reliably.

Blend shapes (morph targets). FBX supports blend shapes, which are alternate vertex positions that can be blended with the base mesh to create deformations like facial expressions. glTF also supports these as morph targets, stored as position (and optionally normal and tangent) deltas per vertex. The weight animations that drive blend shapes are converted the same way as other animations: sampled and written as keyframes.

Limitations. Some conversion tools, including the three.js FBXLoader, do not transfer blend shape normals (morph normals). Only vertex position deltas are preserved. This can cause subtle lighting artifacts on morph targets because the renderer has to recalculate normals on the fly instead of using the authored normals. For most web use cases, the visual difference is minor, but it matters for close up facial animation.

Not everything in an FBX file has a counterpart in glTF. Here is what does not survive conversion:

• Lights. FBX can contain point lights, spot lights, and directional lights. The glTF 2.0 core specification does not include lights. The KHR_lights_punctual extension adds basic light support, but most converters do not output it by default.
• Cameras. FBX camera data can be exported to glTF (the spec supports cameras), but many converters skip cameras because web viewers typically define their own camera setup.
• Custom properties. FBX supports arbitrary user defined properties on nodes and objects. These are application specific metadata (game engine flags, render layer tags, physics properties) that have no standard representation in glTF. They are silently dropped during conversion.
• NURBS and curves. FBX can store NURBS surfaces and curve data. glTF only supports triangle mesh geometry. NURBS must be tessellated (converted to triangles) before export, which most converters handle automatically, but the original parametric surface data is gone.
• Displacement maps. FBX materials can reference displacement maps that modify geometry at render time. glTF does not support displacement mapping. Only normal maps are carried over for surface detail.
• Ambient color. FBX's ambient material color has no equivalent in PBR materials. PBR lighting handles ambient contribution through environment maps and image based lighting, not through a per material ambient term. This value is simply discarded.
• Animation curve shape. As described in the animation section, the original mathematical curves with their tangent controls are replaced by sampled keyframes. The motion looks the same, but the original curve data is not recoverable from the GLB.

It is counterintuitive, but a GLB converted from FBX is often 2 to 5 times larger than the original. There are three main reasons.

1. Animation baking. As covered above, sampling curves into dense keyframe lists dramatically increases animation data volume. A character animation that was 50 KB of curve data in FBX can become 500 KB to 2 MB of sampled keyframes in GLB.

2. Texture embedding. If the original FBX referenced external texture files rather than embedding them, the FBX file itself was small because it only stored file paths. The GLB must embed those texture images, adding their full file size to the output.

3. No default compression. Raw GLB files do not use geometry compression by default. The vertex positions, normals, and UV coordinates are stored as uncompressed float arrays. FBX's binary format can use deflate compression on array data, so its geometry section may already be somewhat compressed.

How to bring the size down. Apply post conversion optimization:

• Draco compression reduces geometry data by 70% to 95%. It quantizes vertex attributes and applies entropy encoding. Read the Draco vs Meshopt comparison for details on when to use each.
• Texture compression. Convert PNG textures to WebP (50% to 80% smaller) or KTX2 with Basis Universal (75%+ smaller with GPU friendly block compression). Reduce resolution from 4K to 2K or 2K to 1K where possible.
• Keyframe reduction. Remove redundant animation samples. If three consecutive keyframes have nearly identical values, the middle one can be removed without visible change.

After these optimizations, the GLB is typically 30% to 80% smaller than the original FBX, not larger. Polyforge's optimizer handles Draco compression and texture optimization directly in your browser.

Textures appear upside down. The UV V coordinate was not flipped during conversion. Most tools handle this automatically. If yours did not, check for a "flip UV" or "flip V" option. In Polyforge, this is handled for you.

Model appears tiny or enormous. The FBX unit scale was not applied correctly. FBX defaults to centimeters; glTF uses meters. If the model appears 100 times too small, the converter skipped the 0.01 scale factor. If it is 100 times too large, the factor was applied twice. Check your converter's scale settings.

Materials look flat or too shiny. The Phong to PBR conversion estimated roughness and metallic values that do not match the original intent. This is especially common with materials that used non standard shininess values or relied on ambient lighting baked into the FBX scene. You may need to adjust material values in a 3D editor after conversion.

Missing textures (blank white or magenta materials). The FBX referenced external texture files that were not available during conversion. Make sure all referenced image files are in the same directory as the FBX file, or use an FBX with embedded textures.

GLB file is much larger than expected. Check for baked animations (especially on rigged characters) and embedded high resolution textures. See the file size reduction guide for a step by step optimization workflow.

Model faces the wrong direction. The FBX had a Z up coordinate system (common in 3ds Max exports) and the axis conversion did not apply correctly. Verify that your converter reads the FBX axis settings from the file's GlobalSettings rather than assuming Y up.

Animations play at the wrong speed. FBX animation timestamps can be stored in different time modes (frames, seconds, film, PAL). If the converter misinterprets the time mode, animations play too fast or too slow. Exporting the FBX with explicit "seconds" time mode from your 3D application avoids this ambiguity.

FBX to GLB conversion is the right choice when your source assets are in FBX and your target platform expects glTF/GLB. The most common scenarios:

• Web 3D. Every major web 3D library (three.js, Babylon.js, PlayCanvas, A-Frame) has first class GLB/glTF support. While most can also load FBX, the glTF loader is typically faster, more reliable, and better maintained because glTF is the open standard for web 3D.
• E-commerce. Shopify, Amazon 3D View, and Google Merchant Center all require GLB. If your product models were created in Maya, 3ds Max, or any tool that exports FBX, converting to GLB is a required step. See the e-commerce format guide for platform specific requirements.
• AR experiences. Android AR (Google Scene Viewer) uses GLB. iOS AR Quick Look uses USDZ, but GLB is the common starting point for both because you can convert GLB to USDZ as a second step.
• File distribution. GLB's single file packaging makes it ideal for sharing. No missing textures, no "where's the .mtl file" problems. One file, everything included.

When to keep FBX instead. If your pipeline stays within game engines (Unity, Unreal) that have mature FBX importers, converting to GLB adds a step without clear benefit. FBX also preserves more data (lights, cameras, custom properties) that game engines can use. Keep FBX as your source of truth and convert to GLB only for web delivery and distribution.