Asset Specification and Platform Requirements Guide

Convert the creative brief into a production contract

Begin with the asset's gameplay role, camera distance, animation needs, and expected instance count. Translate those facts into geometry, material, rig, collision, LOD, and texture fields. Assign an owner and revision number. Build a small reference scene in the target engine and validate one representative asset before scaling production. The source file, interchange export, engine package, and preview renders should share an asset identifier. If a requirement changes, record the reason, approver, affected variants, and migration action rather than silently overwriting the baseline.

Specify versions, axes, formats, and budgets

Record the DCC release and plugins, export format version, engine release including patch, renderer, units, up axis, forward axis, pivot rule, and naming convention. Set triangle limits per LOD, material-slot count, texture dimensions, channel packing, compression class, skeleton and bone limits, and collision method. Performance requirements need a scene, hardware tier, resolution, quality preset, camera path, warm-up duration, and metric. “Runs at 60 fps” is incomplete without those conditions.

Separate shared source constraints from platform overrides

A mobile, desktop, and console build may share the same authored high-resolution source, but not the same runtime payload. Define which fields are invariant and which may vary: mesh reduction, texture mip cap, shader feature level, skin influences, collision complexity, or optional attachments. Give each variant a deterministic suffix and parent source. Do not permit local artist copies to become undocumented masters. A platform override should reduce or adapt the asset without changing its identity or breaking animation and material bindings.

Decision example: one hero asset, three targets

A hero vehicle targets high-end PC, current console, and mobile. The team keeps one detailed source and one skeleton. PC receives the full material feature set and highest LOD; console uses lower texture caps and fewer transparent layers; mobile gets stronger mesh reduction, baked lighting detail, and simplified collision. Each variant is imported into the pinned engine release and profiled in the same route. A single lowest-common-denominator asset would waste quality on stronger hardware, while three unrelated sources would multiply fixes.

Diagnose requirement failures before blaming the asset

If scale or orientation is wrong, compare scene units, export conversion, and import preset. Missing materials usually indicate unsupported shader nodes, renamed slots, or absent dependencies. A passing triangle count with poor performance can still result from overdraw, material changes, skinning cost, or excessive instances. If only one platform fails, diff its override and engine settings against the shared baseline. If all variants fail identically, inspect the source contract and exporter first.

Evidence checklist for specification approval

• Attach the approved requirements sheet with owner, revision, date, and target matrix.
• Provide source and export filenames, checksums, DCC version, exporter, and import preset.
• Capture wireframe, UV density, material slots, skeleton, pivots, collision, and LOD transitions.
• Record profiler results from the named hardware, scene, resolution, and quality preset.
• Open every variant in a clean project and verify missing dependencies, warnings, and packaging.

Related DCC references