Photo Scan for Game Assets: Unity and Unreal Workflows

Photogrammetry has become a standard part of AAA asset pipelines. Game Science used it to recreate traditional Chinese monuments in Black Myth: Wukong with a level of detail that would have taken far longer to hand-model from reference photos alone. (More on that: How AAA Games Build Realism with Photogrammetry)

This guide picks up after you've got a scan and covers what's specific to shipping that asset in a game engine, not the general cleanup process. If you haven't cleaned up your mesh yet, start with Photogrammetry to Blender: Cleanup, Retopo, and Export first. Everything below assumes you're starting from a clean, retopo'd mesh with UVs.

What This Guide Covers

Before Importing Into Unity or Unreal

Unity accepts FBX and glTF/GLB for static meshes. Unreal production pipelines most commonly use FBX for static meshes, LODs, collision, and skeletal data. If your asset needs LOD groups, custom collision, or rigging bundled in the same file, FBX is usually the safer choice.

Check scale and units before import. Unity uses meters by default; Unreal uses centimeters. A mesh that looks correctly scaled in Blender can import at the wrong size in either engine if the unit conversion during export doesn't match what the engine expects. Check a known real-world dimension against the imported asset immediately, before you build anything else on top of it.

Where KIRI Engine Fits Into the Workflow

KIRI Engine can handle topology cleanup, material generation, optimization, rigging, and export preparation before assets reach Unity or Unreal.

Before the asset reaches Unity or Unreal, KIRI Engine can handle several parts of the preparation stage:

• Quad-Mesh Retopology gives Photo Scan exports cleaner topology for static props, environment pieces, and downstream editing.

• PBR Material Generation creates material maps that are easier to connect to Unity and Unreal shaders than a single baked color texture.

• Auto-Rig Generation can help with scanned characters or creatures that have clear limb and joint structure.

• Featureless Object Scan is the better starting point for reflective, transparent, glossy, or low-texture objects that standard photogrammetry struggles with.

The rest of this guide explains what still needs to happen inside Blender, Unity, or Unreal after those export choices.

LOD Generation

Start from your clean retopo'd mesh (not the raw scan) and generate 3-4 LOD levels by progressively reducing polygon count, either through Blender's Decimate modifier before export, or your engine's built-in LOD tools.

Practical target: LOD0 (hero, close-up) at full retopo'd resolution, LOD1 at roughly 50%, LOD2 at 25%, LOD3 for distant or background use. Exact distances depend on the object's physical size, typical camera distance in your scene, and your performance budget; a hand-held prop and a building need very different LOD distance thresholds.

In Unity: if you export LOD meshes from Blender with the naming convention MeshName_LOD0, MeshName_LOD1, and so on, Unity's FBX importer automatically creates a LOD Group component with those levels assigned. You can also build one manually: create an empty GameObject, add a LOD Group component (Add Component > Rendering > LOD Group), and assign each LOD level's renderer.

In Unreal: the FBX pipeline imports LOD meshes the same way, or you can generate LODs directly inside the Static Mesh Editor after import. If your target is a static prop or environment piece rather than a skeletal mesh, consider Nanite instead of manual LODs entirely, covered below.

Collision Meshes

Avoid using the full visual mesh as your collision mesh unless you have a specific reason to do so; a high-poly scan mesh is expensive to run collision checks against and provides more precision than gameplay usually needs. Build a simplified collision proxy: for most props, a convex hull or a handful of primitive shapes (boxes, cylinders, capsules) covering the object's rough silhouette is enough. Reserve complex concave collision for cases where gameplay actually needs it, since it's significantly more expensive to compute.

In Unity: use primitive colliders (Box, Sphere, Capsule Collider) for simple shapes, or a Mesh Collider with Convex enabled for irregular props. Non-convex Mesh Colliders work for static, non-moving geometry but can't be used on anything with a Rigidbody unless marked convex.

In Unreal: the Static Mesh Editor can auto-generate simple collision (box, sphere, capsule, or convex hull) directly from your mesh. For custom collision authored in your DCC tool, name the collision object UCX_MeshName (matching your render mesh's name) before exporting to FBX; Unreal's importer recognizes that naming convention, strips the collision geometry out of the render mesh, and assigns it as the mesh's custom collision automatically.

PBR Texture Setup for Unity and Unreal

If you used PBR Material Generation (Pro only) in KIRI Engine, you're exporting a fuller material map set such as albedo, normal, roughness, and metallic maps. This makes the export easier to connect to standard PBR material workflows in Unity, Unreal, and other real-time engines, instead of working from a single flat texture.

Unreal typically expects roughness and metallic packed into a single ORM texture (Occlusion in the Red channel, Roughness in Green, Metallic in Blue), which reduces the number of texture samples the material needs at render time. If your maps come out as separate files, pack them into ORM using Substance Painter, Photoshop, or Blender's compositor before import.

Unity handles this differently depending on your render pipeline. In URP, the Metallic map's alpha channel is read as Smoothness by default, not Roughness, so you'll need to invert your roughness map (smoothness = 1 − roughness) before packing it into that alpha channel. In HDRP, materials use a dedicated Mask Map with a fixed channel layout (Metallic in Red, Ambient Occlusion in Green, Detail Mask in Blue, Smoothness in Alpha), which you'll need to assemble to that exact spec rather than relying on the engine to auto-detect separate maps.

Rigging with Auto-Rig Generation

Auto-Rig Generation (Pro only) is available on both Photo Scan and Featureless Object Scan exports, and it generates a skeleton directly on the scanned model based on the shape of the mesh.

This works well specifically for subjects that already have a skeleton to infer, humans, quadrupeds, anything built around joints and limbs. It's not built for arbitrary objects: applying it to inanimate objects (props, vehicles, architecture) can produce unpredictable results rather than a usable rig. Use it for characters and creatures. For everything else, skip it.

After generating the rig in KIRI Engine, export with the skeleton included (FBX is the most reliable format for skeletal data across both Unity and Unreal) and verify bone naming conventions match what your animation pipeline expects. If you're planning to retarget existing animations onto the scanned rig, check bone hierarchy compatibility before investing time in weight painting fixes.

A Note on Nanite (Unreal Only)

If your target is Unreal and the asset is a static prop, piece of environment art, or anything else that doesn't deform, Nanite changes the calculus above. Epic's own documentation describes Nanite as built to accept high-poly source geometry like photogrammetry scans and ZBrush sculpts directly, handling LOD automatically without a manual LOD pass. For static environment assets, this can mean skipping much of the manual retopology and LOD generation work described above entirely. You still need clean materials, sensible scale, and collision setup; Nanite mainly changes the mesh density and LOD part of the workflow.

Nanite does not apply to skeletal meshes with deformation in the same way. Characters and anything that needs to bend, rig, or animate still go through the traditional retopo and manual LOD workflow covered earlier in this guide. If you're unsure whether your asset qualifies, the practical test is simple: if it doesn't move or deform, Nanite is worth evaluating; if it does, treat it like any other rigged asset.

When to Switch to Featureless Object Scan Instead

If the asset you're scanning is reflective, transparent, or has very uniform, low-texture surfaces (metal armor pieces, glass, glossy plastic props), standard Photo Scan photogrammetry will produce holes, warping, or soft geometry. Featureless Object Scan (Pro only) uses a different reconstruction method built specifically for these materials, and it also supports Auto-Rig Generation, so switching modes doesn't mean losing access to rigging if your subject needs both.

If you're building a full character loadout and some pieces are metal or glass while others are cloth or skin, you may need to scan different pieces with different modes and assemble the final asset from both.

Unity vs Unreal: Quick Comparison

Frequently Asked Questions

Can a photogrammetry scan be used directly in Unity or Unreal?

Sometimes, but a raw scan is rarely ideal for production use. Most assets still need scale checks, topology cleanup, material setup, collision, and either LODs or Nanite before they are ready for a real-time project.

Should I export my scanned asset as FBX or GLB?

GLB can be convenient for simple static meshes with connected materials. FBX is usually the safer option when the asset includes skeletal data, LODs, or custom collision, especially in established Unity and Unreal pipelines.

Do I need LODs for every scanned asset?

Not always. Small assets that remain close to the camera may need fewer LOD levels, while large scenes or repeated props benefit more from aggressive optimization. In Unreal, suitable static meshes may use Nanite instead of a traditional manually authored LOD chain.

Can I use Nanite for photogrammetry scans?

Yes, Nanite is particularly useful for dense static assets such as scanned props, rocks, monuments, and environment pieces. It does not replace the traditional retopology and LOD workflow for deforming skeletal meshes.

Why do my roughness maps look wrong in Unity?

Unity commonly works with smoothness rather than roughness. In URP, smoothness is often stored in the alpha channel of the Metallic map, so a roughness map must be inverted before use. HDRP uses a dedicated Mask Map with its own channel layout.

Can scanned objects be automatically rigged?

Automatic rigging works best on subjects that naturally have a skeleton structure, such as humans and quadrupedal animals. Props, vehicles, buildings, and other inanimate objects usually require manual rigging or custom skeleton setup. KIRI Engine's Auto-Rig Generation follows the same principle: it's designed for humans and quadrupedal animals, and applying it to inanimate objects can produce unpredictable results, since the rig is generated by compressing the mesh surface rather than recognizing anatomy in a general sense.

Quick Reference: What Each Pro Feature Gets You for Game Assets

Mesh-Inclusive 3DGS output support for Quad-Mesh Retopology, PBR Material Generation, and Auto-Rig confirmed via KIRI Engine Basic vs Pro.

Related Reading

• General cleanup before this stage: Photogrammetry to Blender: Cleanup, Retopo, and Export

• Choosing between capture methods for your asset: 3D Gaussian Splatting vs Photogrammetry vs LiDAR

• What's included in Basic vs Pro: KIRI Engine Basic vs Pro