Heliox's 5-Step Checklist for Polishing Game Art Before Final Export

You've finished the sculpt, baked the maps, and placed every decal. The model looks stunning in your viewport. But when it lands in the game engine, the seams glow, the normal map flips, and the specular reads like wet plastic. That gap between 'looks done' and 'actually ready for runtime' is where polishing lives. This guide walks through a five-step checklist designed to catch the common failure points before you hit export. We'll keep the theory short and the fixes concrete.

1. Who Needs This Checklist and What Goes Wrong Without It

This checklist is for anyone who exports game art—whether you're a solo developer wearing all hats, a junior artist on a team, or a veteran who still occasionally forgets to check the UV overlap. The problems we're targeting are the ones that waste hours in re-import and rebuild cycles: texture seams that only appear in-engine, normal maps that flip on mirrored geometry, LODs that pop too early, and file formats that strip your alpha channel without warning.

Without a structured polish pass, these issues compound. A single texture with wrong compression settings can bloat your build by tens of megabytes. A normal map exported in the wrong color space can make an entire character look like it's made of rubber. We've seen teams spend days debugging a specular highlight that turned out to be a forgotten sRGB flag on a roughness map. The cost isn't just time—it's the creative momentum lost when you have to backtrack instead of moving forward.

The five steps here are ordered by how often they cause problems in real projects. Step one covers texture resolution and compression, because that's where the most common export errors hide. Step two validates normal maps and material consistency—the source of most 'why does it look weird' questions. Step three cleans up geometry and UVs, catching the overlaps and flipped normals that engines hate. Step four is the in-engine test, where lighting and post-processing reveal what your viewport hid. Step five is the final file audit: naming, pivots, scale, and format checks that prevent embarrassing import failures.

This isn't a theoretical framework. Every item on the list comes from real export failures we've debugged or read about in production postmortems. Use it as a template—add your project-specific checks, remove what doesn't apply, but run the full sequence at least once per asset before you call it final.

Who Should Skip This Checklist

If you're making art for a single platform with a fixed pipeline and you've never had an export issue, you might not need every step. But if you're shipping to multiple platforms, working with a team, or using a new engine version, run it. The cost of skipping is a late-night Slack message that starts with 'Hey, the asset looks broken in build.'

2. Prerequisites: What to Settle Before You Start Polishing

Before you run through the five steps, make sure your environment is set up correctly. Polishing an asset that's built on wrong assumptions just means polishing mistakes faster. Here's what we recommend checking first.

Confirm your target platform specs. A texture that looks fine on a PC with 16 GB of VRAM might crash a mobile build. Know your texture budget, poly count limits, and supported compression formats before you start. Write them down next to your monitor. If you're targeting both high-end and low-end, decide whether you'll author separate assets or rely on automatic LOD and mipmap generation. Each choice affects how you validate in step four.

Set up your export preset once and test it. Most 3D software lets you save export settings as presets. Create one for each target platform—FBX with embedded media for Unity, glTF for web, OBJ for legacy pipelines. Export a simple test mesh (a cube with a checker texture) and import it into your engine. Verify that the scale matches, the UVs are intact, and the texture looks the same. If the cube looks wrong, fix the preset now, not after you've exported 50 assets.

Standardize your naming and folder structure. This sounds like housekeeping, but it's the number one cause of 'I can't find the file' delays. Agree on conventions: no spaces in filenames, use underscores or hyphens, include a version number or date, and keep texture names aligned with mesh names. If your team uses a naming schema, follow it. If you're solo, create one and stick to it. A file called 'final_character_v3_export.fbx' is easier to debug than 'newest_character.fbx'.

Check your color space settings. This is a common tripwire. Most engines expect albedo (base color) maps in sRGB, while roughness, metallic, and normal maps should be linear. If you export everything as sRGB, your roughness map will look flat and your normal map will produce incorrect lighting. Confirm your software's color space handling before you start the checklist. In Substance Painter, for example, the 'sRGB (color)' and 'Linear (data)' distinction is critical. If you're unsure, export a test material with known values and check them in the engine.

Back up your working file. The polish process may involve re-exporting multiple times. Keep your source file (Blend, Maya scene, ZBrush project) untouched, and work from copies. If a step requires destructive changes—like merging UV islands or rebaking normals—do it on a duplicate. You don't want to lose the ability to tweak the original because you optimized away the flexibility.

When You Can Skip Prerequisites

If you're exporting a single asset for personal use and you're familiar with the pipeline, you can jump straight to step one. But for any project that involves other people, a build system, or a deadline, take the 15 minutes to set up these foundations. It pays back tenfold in avoided confusion.

3. The 5-Step Polish Workflow

Here's the core workflow. Each step includes a mini-checklist you can run mentally or paste into a project management tool. We'll walk through them in order, but you can reorder based on your asset type—just don't skip any.

Step 1: Texture Resolution and Compression Check

Open your texture files in a viewer that shows mipmaps and compression artifacts. Check that the base resolution matches your target: 2K for hero props, 1K for secondary, 512 for background. If you're using power-of-two textures (2048x2048, 1024x1024), verify that both dimensions are powers of two—non-power-of-two textures can cause mipmap issues on some platforms.

Look for compression artifacts, especially in gradient areas like skyboxes or skin. If you see banding, consider using a higher bit depth or a different compression format (BC7 for high quality, ETC2 for mobile). Check that alpha channels are preserved if you need transparency—some compression formats discard alpha. Also verify that the texture's color space is correct: sRGB for albedo, linear for data maps.

Mini-checklist: Resolution matches target? Power of two? Compression artifacts acceptable? Alpha channel present (if needed)? Color space correct?

Step 2: Normal Map and Material Consistency

Load your normal map into a tool like xNormal or even Photoshop's 3D viewer. Check for seams where the map doesn't match the mesh. A common issue is a normal map baked from a high-poly that didn't align with the low-poly—you'll see soft edges or inverted areas. Also verify that the normal map uses the correct convention: DirectX (green channel inverted) or OpenGL (green channel standard). Most engines expect DirectX, but check your target.

Material consistency means that all maps for a single material share the same UV layout and resolution. If your albedo is 2K but your roughness is 512, the engine may scale them differently, causing misalignment. Also check that your material parameters (metallic, roughness, ambient occlusion) are within expected ranges—metallic values should be 0 or 1 for most PBR workflows, not 0.5.

Mini-checklist: Normal map seams visible? Convention correct (DirectX/OpenGL)? All maps same resolution? Metallic values binary? Roughness range 0–1?

Step 3: Geometry and UV Cleanup

In your 3D software, run a geometry check. Look for zero-area faces, overlapping vertices, and inverted normals. These cause shading artifacts and physics glitches. Use the 'select non-manifold' option if your software has it—non-manifold geometry can break mesh colliders and lightmap UVs.

For UVs, check for overlapping islands (unless you're using them intentionally for tiling textures). Overlapping UVs cause identical texel data on different parts of the mesh, which looks wrong if the parts have different lighting. Also check that UV shells have reasonable padding—too little padding causes bleeding between textures, too much wastes resolution. A 2-pixel padding is standard for 2K textures.

Mini-checklist: Zero-area faces? Overlapping vertices? Inverted normals? UV islands overlapping? Padding adequate? Non-manifold geometry?

Step 4: In-Engine Lighting and Post-Processing Test

Import your asset into the target engine. Place it under the same lighting conditions it will face in the game—day, night, dynamic, baked. Check for shading seams, specular artifacts, and normal map flipping. Rotate the camera around the asset; sometimes a seam only appears at certain angles.

Test with your game's post-processing stack enabled. Bloom can wash out bright textures, color grading can shift hues, and ambient occlusion can darken crevices too much. If your asset looks good in the default viewport but weird with post-processing, adjust the material or texture rather than disabling the effect. Also test at different LOD levels if you have them—the transition should be smooth, not a pop.

Mini-checklist: Shading seams visible? Normal map correct under dynamic light? Post-processing artifacts? LOD transitions smooth? Specular highlights reasonable?

Step 5: Final File Sanity Check

Before you commit the file, run a final audit. Check the filename matches the naming convention. Verify the file format: FBX for Unity, glTF for web, OBJ for legacy. Confirm the scale is correct—a unit in your software should equal a unit in the engine. Check that the pivot point is where you expect it (center of mass, bottom of feet, or origin). Also verify that the file size is reasonable for the asset's complexity; a 500 MB texture is a red flag.

Open the exported file in a text editor (if it's a text-based format like glTF) or a viewer to confirm it's not corrupted. For FBX, you can use Autodesk's FBX Review tool. For glTF, use the online glTF validator. This step catches format-specific issues like missing references or broken binary buffers.

Mini-checklist: Filename correct? Format correct? Scale matches engine? Pivot point correct? File size reasonable? File not corrupted?

4. Tools, Setup, and Environment Realities

The checklist works across tools, but the specifics vary. Here's how to adapt it for common pipelines.

For Unity users: Use the 'Asset Store' tools like 'Texture Importer' to check compression presets. The 'Mesh Renderer' debug mode can show UV overlaps. The 'Frame Debugger' helps identify if a material is causing draw call spikes. Set up a test scene with a directional light and post-processing volume to run step four.

For Unreal Engine users: The 'Mesh Editor' has a 'UV Overlap' visualization. Use the 'Material Editor' to check normal map settings—ensure 'Compression Settings' is set to 'Normalmap'. The 'Level Viewport' with 'Lit' mode is your step four environment. For step five, use the 'File' -> 'Validate' option if available, or check the output log for import warnings.

For Blender to engine pipelines: Blender's '3D Print Toolbox' add-on can check for non-manifold geometry and zero-area faces. Use the 'UV Squares' add-on to clean up UV islands. Export as FBX with 'Apply Scalings' set to 'FBX Units Scale' to match most engines. For step five, open the FBX in a free viewer like 'FBX Review' or import it into a fresh Blender scene to verify.

For Substance Painter users: The 'Export' dialog lets you set output size and compression per map. Use the 'sRGB' and 'Linear' toggles correctly. After export, open the textures in a tool like 'GIMP' or 'Photoshop' to check for banding. Substance's 'Viewport' can simulate engine lighting, but it's not a substitute for step four—always test in the real engine.

Environment realities: Not all teams have dedicated QA for art. If you're on a small team, you are the QA. Build the checklist into your export routine—treat it like saving the file. If you're on a larger team, consider automating parts of step one and five with scripts. Tools like 'Python' in Blender or 'Asset Checker' for Unity can flag resolution mismatches or naming violations before human review.

When Tools Aren't Enough

Automation catches obvious errors, but visual judgment still matters. A normal map might pass all technical checks but still look wrong because the high-poly detail didn't translate. Trust your eyes in step four. If something feels off, investigate—even if the checklist says pass.

5. Variations for Different Constraints

Not every project has the luxury of a full polish pass. Here's how to trim the checklist for common constraints without breaking the essential checks.

For mobile or low-end targets: Prioritize texture compression and resolution. Step one is critical—use ETC2 or ASTC, and keep textures at 1024 or below. Skip step three's UV padding check if you're using lightmaps, because mobile often uses vertex lighting. In step four, test on the actual device, not just the editor, because mobile GPUs handle post-processing differently. Step five's file size check is more important than pivot accuracy for most mobile assets.

For VR or real-time cinematics: Normal map and material consistency (step two) become the highest priority. VR magnifies shading errors, and cinematics require perfect specular response. Spend extra time on step four with HDR lighting. Step three's geometry check is also critical—VR users will notice polygon edges on curved surfaces. Consider using subdivision or tessellation instead of high-poly assets to keep performance.

For web-based exports (WebGL, glTF): Step five's format validation is non-negotiable. glTF has strict requirements—missing extensions or incorrect accessor types will break the model. Use the official glTF validator. Step one's compression check should focus on JPEG vs PNG vs KTX2—JPEG for small files, KTX2 for GPU-friendly compression. Step four must be tested in multiple browsers, because WebGL implementations vary.

For one-off personal projects: You can skip step three's UV cleanup if you're not sharing the asset. Focus on step two (normal maps) and step four (in-engine test) because those are the most visible. Step five's naming convention can be relaxed, but still check the file format—exporting as OBJ when you need glTF will waste time.

For team projects with tight deadlines: Run the full checklist on hero assets only. For background props, run steps one, two, and five. Use automated scripts for step three's geometry check. Step four can be a batch import test—load all props into a test scene and walk through them quickly. The goal is to catch showstoppers, not every minor UV seam.

When to Add Steps

If your asset uses vertex colors, add a check for color bleed. If it uses skeletal animation, verify that the rig is bound correctly and the skin weights are clean. The five-step checklist is a core—extend it for your asset type.

6. Pitfalls, Debugging, and What to Check When It Fails

Even with a checklist, things go wrong. Here are the most common failure modes and how to diagnose them.

Problem: The asset looks fine in the viewport but wrong in the engine. The most likely cause is a color space mismatch. Check that your normal map is imported as linear (not sRGB) and that your roughness/metallic maps are also linear. Second most likely: the material's shader settings don't match your texture channels. For example, Unity's Standard shader expects metallic in the blue channel of a packed map, but you exported it in red. Open the material in the engine and verify channel assignments.

Problem: Seams appear on the mesh where the UVs split. This is usually a normal map baking issue. The high-poly and low-poly meshes didn't align during baking, or the cage was too tight. Re-bake with a 1–2 pixel dilation to spread edge data. Also check that your UV islands have enough padding—if they're too close, the engine's mipmapping will bleed texels from adjacent islands.

Problem: The texture looks blurry or blocky. This indicates compression artifacts or incorrect mipmap settings. Check the texture's compression format—if you're using DXT1 on a normal map, it will look terrible. Switch to BC5 for normal maps. Also check that mipmaps are generated correctly—sometimes the lowest mip level is too small for the texture resolution, causing blurriness at distance.

Problem: The asset is too large or too small in the engine. Scale mismatch. Confirm that your export preset uses the correct unit scale. Most engines expect 1 unit = 1 meter, but your 3D software might default to centimeters. In Blender, set 'Unit Scale' to 0.01 if you want centimeters, or export with 'Apply Scalings' set to 'FBX Units Scale'. Test with a known reference (a 1-meter cube) before exporting the real asset.

Problem: The file fails to import or shows errors. Run step five's validation. For FBX, use the FBX Converter tool to check for corruption. For glTF, use the online validator—it will tell you exactly which property is wrong. Common causes: missing texture references (relative paths broken after moving files), unsupported vertex formats (like 32-bit floats where 16-bit is expected), or too many bones for the engine's limit.

Debugging Workflow

When something fails, don't re-export blindly. Isolate the issue: export a simple version of the asset (a cube with the same material) and see if the problem persists. If it does, the issue is in the material or texture settings. If it doesn't, the problem is in the geometry or UVs. Then fix the specific step, re-export just that part, and test again.

7. Frequently Asked Questions and Common Mistakes

Q: Do I need to run the checklist for every single asset? A: For hero assets and anything that interacts with lighting (characters, weapons, vehicles), yes. For background props that use simple materials, you can skip step two and three if they're procedurally generated. But we recommend running at least steps one and five for every asset.

Q: What's the most common mistake artists make? A: Forgetting to set the correct color space on normal maps. It's easy to miss because the texture looks fine in the viewport, but the engine interprets it differently. Always double-check the import settings.

Q: Should I use compressed or uncompressed textures for final export? A: Compressed, always. Uncompressed textures bloat build size and loading times. Use the highest quality compression your target platform supports—BC7 for PC, ETC2 for Android, ASTC for iOS. If you need lossless, use PNG for 2D assets, but for 3D models, compressed is standard.

Q: How do I handle assets with multiple materials? A: Run the checklist per material. Each material may have different texture resolutions, compression needs, and normal map conventions. Pay extra attention to step two—material consistency across multiple maps is harder to maintain.

Q: What if my asset uses a custom shader? A: The checklist still applies, but you may need to add a step for shader-specific parameters. For example, a toon shader might require a ramp texture that shouldn't be compressed. Test the asset with the custom shader in step four.

Common Mistake 1: Over-relying on auto-LOD generation. Auto-LOD often produces ugly geometry reduction and UV seams. Manually create at least one LOD level for hero assets, and test the transition in step four.

Common Mistake 2: Ignoring the alpha channel. If your texture has an alpha channel but you don't need it, strip it before export. Unused alpha channels waste memory and can cause blending issues if the engine treats them as transparency.

Common Mistake 3: Not testing on the target hardware. The editor viewport is not the game. Mobile GPUs handle textures differently, and console GPUs have specific compression requirements. Always test on the actual device or a representative emulator.

8. What to Do Next: Specific Actions After Polishing

You've run the checklist, fixed the issues, and exported the final asset. What now? Here are five specific next moves.

1. Archive the source and export files together. Create a folder structure like 'AssetName/Source/' and 'AssetName/Export/'. Include a text file with the export settings used (resolution, format, compression). This makes it easy to re-export if the engine updates or if you need to modify the asset later.

2. Add the asset to a shared test scene. If you're on a team, place the asset in a scene that everyone can access. Include a note about any special handling (e.g., 'uses custom shader', 'requires post-processing volume'). This helps other team members spot issues you might have missed.

3. Update your personal checklist with any issues you caught. If you discovered a new pitfall (like a specific compression format that breaks your normal maps), add it to your checklist. Over time, your checklist will become tailored to your pipeline.

4. Communicate any changes to the pipeline. If you had to adjust export settings or naming conventions to make the asset work, tell your team. A quick message like 'I switched normal map compression to BC5 to fix banding' can save others hours of debugging.

5. Review the asset after it's integrated into the build. Once the asset is in a full game build (not just the editor), check it again under final lighting and post-processing. Sometimes the build process introduces new issues—like texture streaming that loads low-res mips too slowly. A final review in the built game catches those edge cases.

Polishing isn't glamorous, but it separates a professional asset from one that looks 'almost right.' Run the checklist, trust your eyes, and ship with confidence.