How Game Engines Handle 3D File Imports

No game engine renders your FBX, OBJ, or glTF file directly. Every engine converts the source file into an internal representation that is optimized for its renderer, its material system, and its target platform.

In Unity, the source file stays untouched in your Assets folder while the engine writes a converted version to the Library directory. Unreal compiles everything into .uasset files in the Content Browser. Godot generates resources in the .godot/imported/ directory. In all three cases, you never work with the raw source file at runtime.

During this conversion, the engine reads the mesh geometry, triangulates any quads or n-gons, extracts or generates materials, loads textures, and parses animation data. Each of these steps has format-specific behavior, which is why the same model can look correct in one engine and broken in another.

Unity's entire import chain is built around FBX. The engine can also read OBJ, DAE (Collada), and proprietary formats from Maya, Blender, and 3ds Max, but under the hood it funnels everything through its FBX processing pipeline. Unity's own documentation recommends using FBX whenever possible.

The .meta file system

Every asset and folder in a Unity project gets a .meta file. This file stores a unique ID (GUID) that Unity uses to track references, plus all the import settings you configure in the Inspector: scale factor, mesh compression, material mode, animation compression, and more. If you move or rename a file outside the Unity Editor, the .meta link breaks and every reference to that asset disconnects. Always move assets through the Editor.

Material handling

Unity offers three material import modes: None (uses a default shader), Standard Legacy, and Import via MaterialDescription. The last option reads embedded material data from FBX files and maps it to Unity shaders. However, FBX has a critical limitation: it only reliably transfers diffuse texture data. Metallic, roughness, and normal maps often get lost or approximated because FBX has no standard PBR material definition.

For full PBR material transfer, Unity supports glTF through the official glTFast package (com.unity.cloud.gltfast). This package maps glTF's metallic-roughness materials to proper PBR shaders in URP, HDRP, and the Built-in Render Pipeline. The alternative is UnityGLTF from the Khronos Group, which supports advanced material extensions like transmission, sheen, and clearcoat.

Scale and units

Unity uses 1 unit = 1 meter with a Y-up, left-handed coordinate system. FBX files from Blender often arrive with a 0.01 scale factor because Blender defaults to centimeters in FBX exports. The Model Import Settings panel provides a Scale Factor field and a Convert Units toggle to handle this automatically.

Unreal Engine also treats FBX as its primary import format. On import, the engine compiles source files into .uasset binaries that live in the Content Browser. The FBX SDK handles triangulation, skeleton extraction, and material stub generation. For large files with multiple meshes, the engine processes each part sequentially, which can be slow on complex scenes.

Nanite: rethinking polygon budgets

Unreal Engine 5 introduced Nanite, a virtualized geometry system that streams and renders pixel-scale detail from meshes containing billions of triangles. With Nanite enabled, you can import film-quality assets directly without creating manual LODs (Level of Detail).

There is a major constraint: Nanite only works with static geometry. Characters, cloth simulations, and anything that deforms at runtime still requires traditional polygon budgets. Translucent materials also cannot use Nanite. So while environment art and props benefit enormously, animated assets still need the same optimization work as before.

The Interchange Framework

Starting with UE 5.4, the Interchange Framework became the default import pipeline, replacing the legacy FBX Importer. Interchange is format-agnostic: it handles FBX, glTF, and OBJ through a single asynchronous pipeline. You can customize the pipeline through Blueprint, Python, or C++, and it supports runtime asset loading.

Material handling

Unreal generates Material Instances from imported material data. Like Unity, it struggles with PBR transfer from FBX because FBX lacks a standardized PBR material definition. The recommended workflow in most studios is to import textures separately and build materials manually using Unreal's node-based material editor. Naming conventions matter: textures named with suffixes like _BaseColor, _Roughness, _Normal, and _Metallic help automated tools map them correctly.

Scale and units

Unreal uses 1 unit = 1 centimeter with a Z-up, left-handed coordinate system. A 100cm box in your DCC tool matches a 100-unit box in Unreal. This is different from Unity and Godot, which both default to meters.

Godot takes a different approach from Unity and Unreal. The engine officially recommends glTF 2.0 as the primary import format. glTF materials map directly to Godot's StandardMaterial3D, which means PBR properties like metallic, roughness, normal maps, and ambient occlusion transfer without manual intervention.

FBX support via ufbx

Before Godot 4.3, FBX import required an external tool called FBX2glTF that converted FBX to glTF behind the scenes. This was unreliable and unavailable on all platforms. Starting with Godot 4.3 (August 2024), the engine includes native FBX parsing through the ufbx library, a free, open-source FBX loader. ufbx applies unit conversion directly to mesh geometry rather than adding scale transforms to nodes, producing cleaner scene hierarchies. It also handles Mixamo and ReadyPlayerMe bone conventions out of the box.

Direct Blender import

Godot 4 can import .blend files directly. You configure the path to your Blender installation in Project Settings, and from that point you can drop .blend files into the project folder. Godot calls Blender in the background to convert the file. This skips the manual export step entirely, though complex rigs and linked blend files can cause issues.

Scale and units

Godot uses 1 unit = 1 meter with a Y-up, right-handed coordinate system. This matches the glTF specification exactly, which is another reason glTF imports tend to work cleanly in Godot.

All three engines support FBX and glTF, but the depth of support varies. This table covers the formats most relevant to asset pipelines as of early 2026.

All three engines use PBR with the metallic-roughness workflow. In theory, this means a material authored once should look consistent everywhere. In practice, the file format you use to deliver that material determines how much data survives.

The FBX material problem

FBX was designed before PBR became standard. The format stores Phong and Lambert shading parameters (diffuse, specular, glossiness) but has no official metallic-roughness definition. When you export PBR materials through FBX, only the diffuse/base color texture transfers reliably. Metallic, roughness, and normal maps either get dropped or require the receiving engine to guess at the mapping.

This is the single biggest source of "my materials look wrong after import" complaints. The fix is either to use glTF (which has a formal PBR metallic-roughness material model) or to import textures separately and assign them manually inside the engine.

glTF PBR materials

The glTF 2.0 specification defines metallic-roughness as its core material model. Base color, metallic factor, roughness factor, normal maps, occlusion, and emissive all have defined slots in the format. This maps cleanly to Unity (via glTFast), Unreal (via Interchange), and Godot (natively).

Texture compression per platform

Each engine compresses textures to GPU-specific formats during the build process. Desktop builds typically use BC7 (high quality RGBA) or BC6H (HDR). Mobile builds use ASTC on modern devices or ETC2 as a fallback for older hardware. These compression settings are per-platform and configured inside the engine, not in the source file. Your export format does not affect which GPU texture format the engine ultimately produces.

Scale and orientation mismatches are the fastest way to waste an afternoon. Every engine has its own conventions, and every DCC tool has its own defaults.

Why models end up the wrong size

Blender exports FBX files with a scale factor of 0.01 by default because it internally works in meters but the FBX convention is centimeters. Unity reads this scale metadata and usually adjusts automatically, but older versions or custom export settings can produce models that are 100x too large or too small. In Unreal, where 1 unit equals 1 centimeter, a model built at meter scale in Blender matches correctly without any conversion.

Why models appear rotated

When you export from a Z-up tool (Blender, 3ds Max) into a Y-up engine (Unity, Godot), the importer applies a 90 degree rotation on the X axis. Most engines handle this transparently, but it can create problems when you parent objects or apply additional rotations at runtime. If your model appears to be lying on its back or facing the wrong direction, the coordinate system conversion is the most likely cause.

FBX is the standard for animation exchange between DCC tools and game engines. It handles skeletal animation (bone transforms over time), morph targets (blend shapes for facial animation), and basic keyframed object transforms. All three engines can import these animation types from FBX.

What transfers cleanly

• Skeletal animations with bone hierarchies and skin weights
• Simple keyframed translations, rotations, and scale
• Morph targets / blend shapes (exported with the "Deformations" option enabled)

What does not transfer

• Inverse kinematics (IK) constraints must be baked to per-frame keyframes before export
• Procedural animations driven by physics or scripts
• Engine-specific state machines: Unity's Animator Controllers, Unreal's Animation Blueprints, and Godot's AnimationTree are all built inside the engine and cannot be exported
• Complex blend shape setups driven by bone transforms need baking in your DCC tool

Animation in Godot via glTF

Godot imports glTF animations into its AnimationPlayer node. Skeletal animations and morph target animations both work through glTF, making it a viable alternative to FBX for delivering animation data to Godot. For complex character animation, Godot's AnimationTree provides state machine logic and blend trees similar to what Unity and Unreal offer.

Animation compression

Each engine applies its own animation compression after import. Unity offers keyframe reduction with a configurable error threshold (0.5% by default). Unreal provides multiple compression codecs optimized for different animation types. Godot compresses animation data during resource import. In all cases, the compression is engine-side and does not depend on the source format.

There is no single format that works perfectly in every engine. The right choice depends on what kind of asset you are delivering and which engine you are targeting.

Many professional studios use a dual-format approach: FBX for delivering animation and rig data, glTF or GLB for delivering static props and materials. Some teams maintain their assets in Blender's native format and export to the target engine's preferred format as part of an automated build step.

If you need to convert between formats before importing into your engine, Polyforge's converter handles FBX, GLB, glTF, OBJ, STL, USDZ, and more directly in the browser with no file upload to a server.