The Heliox Asset Handoff: A Foolproof Checklist for Artists and Engineers

The handoff between artists and engineers is often the most fragile moment in a production pipeline. Files arrive with the wrong naming scheme, missing LODs, or collision meshes that fail in engine. The result: back-and-forth pings, missed deadlines, and frayed relationships. This guide gives you a repeatable checklist—tested across small indie teams and larger studios—to make that handoff predictable and fast.

We cover every stage from export settings to engine import, with concrete criteria for poly counts, texture budgets, naming conventions, and metadata. You will also find a decision framework for choosing the right level of detail per asset type, plus common failure modes and how to catch them early. Whether you are a technical artist building the bridge or a producer scheduling the gate, these steps will reduce iteration cycles and keep your pipeline healthy.

1. The Handoff Problem: Why It Breaks and Who Pays

Every team has a story. The hero asset that looked perfect in Maya but flickered in-game because of a smoothing group error. The modular kit that had to be re-exported three times because the pivot points were off. The character whose rig constraints didn't match the animation blueprint, causing a week of rework. These are not isolated incidents—they are symptoms of a missing handoff standard.

The core issue is asymmetry of knowledge. Artists think in terms of visual fidelity and creative intent; engineers think in terms of runtime performance and data structure. Neither side is wrong, but without a shared language, assumptions collide. The artist exports a 100k-triangle prop because it looks great in the viewport. The engineer imports it and the frame rate drops by 15%. The artist names their file 'final_v2_actuallyfinal.ma' and the build script can't find the correct source. These mismatches are predictable and preventable.

This is where a checklist becomes more than a bureaucratic form. It is a communication protocol. When both sides agree on the rules before the first asset is exported, the handoff becomes a mechanical step rather than a negotiation. The checklist we outline below is designed to be adapted—you will likely add team-specific items—but the core categories remain consistent across projects: naming, geometry, UVs, textures, materials, rigging, collision, LODs, and metadata.

Who Should Own the Handoff?

In many teams, the technical artist (TA) is the natural owner. The TA understands both the DCC tool's export quirks and the engine's import expectations. But even without a dedicated TA, the responsibility can be shared: artists own the export settings, engineers own the import validation, and a producer or lead signs off on the final checklist. The key is that one person is accountable for each asset's handoff readiness.

We have seen teams where the handoff is entirely automated via scripts that check naming, poly count, and texture size before the file is even committed. That is the ideal end state. But automation requires a clear spec first, and that spec is what this checklist provides.

2. The Core Checklist: What Every Asset Needs Before Export

This checklist is organized by the typical order of operations in a DCC tool. You can use it as a literal checklist in a spreadsheet or integrate it into your asset tracking system. Each item includes a rationale so you know why it matters, not just what to do.

Naming and File Structure

Every asset must follow a team-wide naming convention. A good pattern is: Category_AssetName_Variant_LOD_Author_Version. For example: Prop_Chair_Red_LOD0_AJ_v03.fbx. This ensures that build scripts can parse the file, that LODs are grouped automatically, and that version conflicts are obvious. Avoid spaces, special characters, and vague suffixes like 'final' or 'new'.

File paths should mirror the naming hierarchy. Keep the folder structure flat—no more than three levels deep—to avoid path length issues on Windows builds. Include a readme or a _handoff_notes.txt file for any exceptions.

Geometry and Topology

Poly count must match the agreed budget for the asset's tier (hero, secondary, tertiary). Use a shared reference table: hero props ≤ 10k tris, secondary ≤ 3k, tertiary ≤ 500. Check for hidden geometry, floating vertices, and non-manifold edges. All meshes should be triangulated before export (quads are for editing, triangles are for runtime).

Pivot points must be centered on the asset's logical origin (usually the base center for props, the root joint for characters). Test that the pivot aligns with the grid snap in the engine. If the asset is modular, ensure grid snapping works at the intended unit scale (e.g., 100 Unreal units per meter).

UVs and Texture Layout

UVs must be non-overlapping, within the 0–1 space, with no islands flipped. Check for UV distortion using a checker texture in the DCC. All UV shells should have a consistent texel density—use a tool like Texel Density Checker to verify. For hero assets, aim for 10.24 pixels per centimeter at a 2K texture; for background assets, 5.12 is often sufficient.

Texture sets must match the engine's expected naming (e.g., _BaseColor, _Normal, _ORM). Pack multiple maps into channels where possible (e.g., roughness in alpha, metallic in red). Avoid texture sizes above 4K unless absolutely necessary—2K is the sweet spot for most real-time applications.

Materials and Shaders

Assign a temporary material with the correct shader type (e.g., Standard, Clear Coat, Hair). Do not leave default Lambert or Blinn materials. Name the material exactly as it should appear in the engine, because many importers use the material name as the instance name. If the asset uses multiple materials, each must be clearly separated by polygroup or by assigning different materials to different meshes.

Include a note if the material requires a custom shader or a specific texture channel setup. Do not rely on the artist's local shader library—export a .sbsar or a shared material package alongside the mesh.

3. LODs and Collision: The Overlooked Essentials

LODs (Levels of Detail) and collision meshes are the two items most frequently forgotten in the handoff. Without them, engineers have to generate them automatically, which often produces poor results or performance hits.

LOD Creation Rules

Each asset should have at least three LODs: LOD0 (full detail), LOD1 (50% reduction), and LOD2 (20% reduction). For very small or distant assets, LOD3 can be a billboard or a single quad. Use a consistent reduction algorithm—either manual decimation or a tool like Simplygon—and document the reduction ratio per LOD.

Ensure that LOD transitions are seamless: no popping or visible vertex snapping. Test LOD switching in the engine with a camera distance slider. The screen size thresholds should be agreed upon by the team: for example, LOD0 switches at 20% screen coverage, LOD1 at 10%, LOD2 at 5%.

Name each LOD file with the _LOD# suffix so the engine can auto-group them. Do not include LODs in the same FBX file unless your engine supports per-file LOD groups (most do not—separate files are safer).

Collision Meshes

Collision geometry must be simple—use convex hulls, boxes, capsules, or a combination. Avoid using the render mesh as collision. For complex shapes, break the collision into multiple convex pieces (e.g., a chair's legs as separate boxes, the seat as a single box).

Name the collision mesh with a suffix like _UCX (Unreal) or _Collision (Unity). Ensure the collision mesh is non-overlapping and completely encloses the render mesh. Check for gaps that could cause the player to fall through. If the asset is a static prop, use simple collision; if it is interactive, you may need per-poly collision (but only if absolutely necessary).

Document the collision complexity budget: for hero props, up to 10 hulls; for secondary, up to 5; for tertiary, a single box or sphere.

4. Rigging and Animation Constraints

Character assets and animated props require additional handoff rules. The rig must match the skeleton hierarchy expected by the engine's animation blueprint. This is a common source of friction: the artist rigs with a different bone naming or orientation, and the animation retargeting fails.

Skeleton and Bone Naming

Use the team's standard skeleton template. Export the skeleton as a separate FBX for reference. Each bone must have a unique name, no spaces, and follow the hierarchy: root, pelvis, spine_01, spine_02, etc. The bind pose must be exactly the T-pose (or A-pose if specified), with all bones at zero rotation relative to their parent.

Check that the skin weights are normalized and that no vertex has more than 4 influences. Export with skin weights included. If the engine uses a different bone orientation (e.g., Y-up vs Z-up), apply a transform before export—do not rely on the importer to fix it.

Animation Clips

Each animation clip should be a separate FBX file named with the character name and clip name (e.g., Char_Warrior_Idle.fbx). Include a start and end frame that matches the clip length exactly—no extra frames. Set the frame rate to the project's standard (30 fps for most real-time, 60 for high-fidelity).

Remove all animation curves that are not needed (e.g., visibility, scale). Use a consistent root motion setup: either lock the root bone in place or export root motion curves, but decide which one before the first animation is created. Document this decision in the handoff notes.

Blend Shapes and Morph Targets

If the asset uses blend shapes (e.g., facial expressions), export them as separate morph targets within the same FBX. Name each target clearly (e.g., BrowRaise, SmileLeft). Test that the blend shape indices match the engine's expected order—a mismatch can cause facial animation to break silently.

Limit the number of blend shapes per mesh to 50 or fewer, as some engines have a hard cap. If you need more, consider using a bone-based facial rig instead.

5. Metadata and Documentation: The Glue That Holds It Together

A folder full of FBX files is useless without context. Metadata tells the engineer what each asset is for, what its budget is, and what exceptions were made. This section covers what to include alongside the asset files.

The Handoff Document

Create a simple text file or spreadsheet per asset (or per batch) that includes: asset name, author, date, poly count, texture sizes, LOD distances, collision type, material names, and any known issues. This document should live in the same folder as the asset files. It does not need to be fancy—a .md or .txt file is fine—but it must be present.

Include a section for 'exceptions' where you note anything that deviates from the standard. For example: 'This prop uses a 4K texture because it appears in a close-up cutscene.' Without this note, the engineer will flag it as a budget violation and waste time investigating.

Automated Metadata Extraction

Better than a manual document is a script that reads the asset file and generates a JSON metadata file automatically. Tools like fbxinfo (part of FBX SDK) or custom Python scripts in Maya can extract poly count, texture paths, and LOD hierarchy. This JSON can then be parsed by the build pipeline to validate the handoff automatically. We recommend investing in this automation early—it pays for itself within a few weeks.

If you cannot automate, at least create a template that artists fill in before export. The template should have checkboxes for each checklist item, so nothing is forgotten.

6. Common Handoff Pitfalls and How to Avoid Them

Even with a checklist, mistakes happen. Here are the most frequent failure modes we have seen across teams, along with preventive measures.

Pitfall 1: Inconsistent Unit Scale

One artist works in centimeters, another in meters. The engine imports the first asset at 1/100th scale. The fix: set a project-wide unit scale (e.g., 1 unit = 1 cm) and enforce it in the DCC export settings. Add a unit check to your import script that rejects files outside a tolerance range.

Pitfall 2: Missing or Wrong Texture Compression

An artist exports a normal map as sRGB, causing weird lighting artifacts. The solution: include a texture compression guide in the handoff document. Specify that normal maps use linear space (no sRGB), roughness maps use linear, and base color uses sRGB. Most engines auto-detect this, but it is safer to set it explicitly in the texture import settings.

Pitfall 3: Overlapping UVs for Lightmap

Static meshes need a second UV channel for lightmaps. If the artist only provides one UV channel, the lightmap will bleed. Add a checklist item: 'Second UV channel exists and is non-overlapping, with a 2-pixel padding between shells.' Use a lightmap resolution of 64 or 128 per meter for most assets.

Pitfall 4: Incorrect Pivot for Modular Assets

Modular wall pieces need their pivot at the grid snap point (e.g., the bottom-left corner). If the pivot is at the center, the pieces will not align. The fix: include a reference grid in the DCC scene and snap the pivot to the nearest grid point before export.

These pitfalls are not exhaustive, but they cover the majority of handoff rework. Add your team's specific frequent issues to the checklist as you encounter them.

7. Frequently Asked Questions

Q: Should we use FBX or glTF for the handoff?
Both are widely supported, but glTF is gaining traction for real-time pipelines because it is an open standard and supports PBR materials natively. FBX is still more common in game studios due to legacy tooling. Choose one and stick with it—do not mix formats unless your pipeline explicitly supports both. We recommend glTF 2.0 for new projects and FBX for established pipelines that already have import scripts.

Q: How do we handle version control for large binary files?
Use Git LFS (Large File Storage) or a dedicated asset management system like Perforce or Subversion. Avoid storing binary assets in a regular Git repository—it will bloat the history. Set up hooks that run a validation script on commit to check the handoff checklist automatically.

Q: What if an asset needs to be updated after handoff?
Treat it as a new handoff. Increment the version number in the file name, update the handoff document, and re-run the validation. Do not overwrite the old file—keep a history of versions so you can roll back if needed. Communicate the change to the engineering team with a brief note about what changed.

Q: Who is responsible for catching errors—artist or engineer?
Both. The artist runs the checklist before exporting. The engineer runs an automated validation on import. If an error slips through, the team should do a post-mortem to improve the checklist or automation, not assign blame. The goal is to make the process foolproof, not to catch people making mistakes.

Q: Can we skip LODs for small props?
Yes, but only if the prop is very small (e.g., a coin or a button) and will never be seen close up. For anything that the player can interact with or that appears in a cutscene, LODs are essential. When in doubt, add LODs—they cost very little to create and can save significant performance.

8. Putting It All Together: Your Next Steps

You now have a comprehensive checklist for the asset handoff. But a checklist only works if it is used. Here are three concrete actions to take this week:

1. Create your team's handoff template. Use the categories from this guide—naming, geometry, UVs, textures, materials, LODs, collision, rigging, metadata—and adapt them to your engine and DCC. Write the template as a markdown file or a spreadsheet, and share it with the whole team for feedback.

2. Automate one validation step. Pick the most frequent error in your current pipeline (e.g., missing LODs or wrong pivot) and write a script that checks for it on import. Even a simple Python script that prints a warning can save hours of manual review.

3. Run a pilot handoff with one asset. Choose a simple prop and go through the entire checklist with both an artist and an engineer present. Note where the checklist was unclear or missing an item. Revise it, then roll it out to the rest of the team.

The handoff does not have to be a pain point. With clear rules, shared ownership, and a little automation, it becomes a smooth, predictable part of your pipeline. Start small, iterate, and watch your iteration cycles shrink.