Character Technical Specifications Gui…

Key points

Define the asset role before choosing budgets, formats, or review gates.
Translate platform, camera, rig, texture, LOD, and delivery needs into acceptance criteria.
Use the spec to make approval measurable before production starts.

Sections 7 parts

01 Asset Classification
02 Geometry and Topology Spec
03 Rig, Skeleton, and Animation Spec
04 UV and Texture Spec
05 Materials, Shaders, and Engine Import
06 LOD and Performance Spec
07 Delivery and Acceptance Criteria

TL;DRToo long, didn't readExpand summary

A character technical spec turns the desired look into production acceptance criteria. Instead of chasing universal numbers, it defines the asset role, platform, camera, rig, texture behavior, LOD rules, and delivery evidence that make approval measurable before production starts.

Spec purpose
The spec connects concept, artist, engine, and receiving team so everyone knows what the asset must do, not only how it should look.
Main mistake
Triangle counts, texture sizes, bone limits, and LOD setups are only useful after the asset role and production context are known.
Acceptance value
A good spec gives technical leads, producers, and clients a concrete way to approve, reject, or request changes without vague taste debates.

A character specification is the production agreement that sits between the concept, the artist, and the engine. It should be specific enough for a technical lead to validate, but readable enough for a producer or client to understand what they are approving.

The mistake is treating specs as a list of universal numbers. There is no single correct triangle count, texture size, bone count, or LOD setup for every character. The correct spec depends on platform, camera distance, animation complexity, material cost, crowd density, and the receiving team’s pipeline.

The client risk is approving a look without approving the constraints that make the look usable. This model turns project-specific requirements into acceptance criteria before production starts.

Illustrated production scene where a character spec separates unclear requirements from an approved asset review.

Specification job

A useful spec turns taste into acceptance criteria

It names the asset role before numbers are chosen.

It explains which constraints come from platform, camera, rig, shader, or review needs.

It gives the receiving team a concrete way to approve or reject the delivery.

Example spec snapshot

Hero real-time character

Classification

Hero skeletal character for close third-person camera. Prioritize deformation, face/hands, material response, and reliable engine import.

Rig target

Client skeleton with documented root, bind pose, and max influences. Skeleton compatibility is a delivery constraint, not a post-handoff cleanup task.

Texture rule

Color maps in sRGB; packed masks, roughness, metalness, AO, and normal data treated as linear/data maps. Color-space mistakes can change the asset after import even when the texture files are present.

01. Asset Classification

Start by naming the role of the character. Budget and quality expectations change when the asset moves from hero close-up to background crowd.

Data table

Character classification and production concern

Classification sets the context for budget, fidelity, deformation, and import expectations.

Classification sets the context for budget, fidelity, deformation, and import expectations.
Classification	Typical production concern
Hero character	close-up fidelity, facial range, material response, deformation quality
Primary NPC	readability, animation stability, texture efficiency, variant support
Background or crowd	silhouette, LOD behavior, material consolidation, memory footprint
Cinematic asset	close-up detail, groom or hair fidelity, render-time material response
Mobile or UGC asset	strict size limits, simplified materials, stable import, marketplace rules

This classification should appear at the top of the spec. Without it, every downstream number is ambiguous.

Illustrated role-first comparison showing hero, NPC, and mobile character categories before choosing production budgets.

02. Geometry and Topology Spec

Define topology by function, not only by polygon count.

Specify:

target mesh type: static, skeletal, modular, groom-supported, cloth-supported, or accessory-only
triangle budget or range by LOD and platform
deformation zones: shoulders, elbows, knees, hips, neck, jaw, fingers, eyes, cloth, or armor
edge-flow requirements around bending or facial areas
whether subdivision, sculpt source, or high-poly bake source must be delivered
acceptable non-deforming detail: cards, shells, decals, floaters, or baked details
collision, physics, cloth, and attachment proxy requirements

Topology is acceptable when it supports the target pose range and engine import, not when it merely looks clean in a static viewport.

Illustrated topology checklist showing shoulder, elbow, knee, jaw, and hip bend tests with warnings for pinching, volume loss, collapse, intersection, and twist failure.

03. Rig, Skeleton, and Animation Spec

For rigged assets, the skeleton should be specified before final modeling and skinning decisions.

Define:

rig type: Humanoid, Generic, Epic-style, proprietary, or client-provided
root bone name, location, and orientation
neutral pose: A-pose, T-pose, bind pose, or project-specific pose
maximum skin influences per vertex if the target engine enforces one
facial requirements: blendshapes, morph targets, bones, corrective shapes, or none
cloth, hair, physics, and secondary-motion expectations
animation test clips or pose checks required for acceptance
whether retargeting, avatar mapping, or animation blueprints are part of the handoff

A character can pass a beauty review and still fail production if the shoulder, jaw, fingers, skirt, armor, or prop attachments do not deform under the expected motion.

Illustrated rig checkpoint with skeleton, root, bind pose, influence, and test-pose rules listed for review.

04. UV and Texture Spec

The texture spec should describe map behavior, not just resolution.

Define:

UV layout: 0-1, UDIM, trim, mirrored, stacked, or studio-specific
texel density target or hierarchy
padding expectations by texture resolution
texture set count and material ID rules
map list: base color, normal, roughness, metallic, AO, opacity, emissive, subsurface, thickness, height, masks
color space: sRGB for color data, linear for data maps and packed masks when required
bit depth and file format expectations
channel packing rules, such as ORM or custom mask layouts
source texture delivery: Substance, PSD, EXR, or baked finals only

Packed maps should always include a channel legend. For example:

Data table

Packed map channel legend example

Document channel packing so integration, shading, and QA teams interpret maps consistently.

Document channel packing so integration, shading, and QA teams interpret maps consistently.
Channel	Example use
R	Ambient occlusion or custom mask
G	Roughness or custom mask
B	Metallic or custom mask
A	Opacity, cavity, blend, or unused

Do not assume a universal packing order. The receiving shader and engine import settings define the correct answer.

Illustrated color-space checkpoint where sRGB color maps and linear data maps are routed through separate import lanes.

05. Materials, Shaders, and Engine Import

Material count affects rendering cost, asset readability, and integration complexity.

Specify:

maximum material slots by LOD or asset type
whether material instances are expected
shader model or master material family
required parameters: tint, roughness variation, emissive intensity, dirt masks, team colors, damage states
transparency, alpha clipping, hair, cloth, subsurface, or two-sided material requirements
expected preview environment for approval
target engine import settings when applicable

For Unity pipelines, technical specs may need to name rig type, Avatar behavior, texture import max size, compression behavior, blendshape usage, and Skinned Mesh Renderer expectations. For Unreal pipelines, specs often separate Skeletal Mesh, Skeleton, Animation Blueprint, material instances, morph targets, and physics assets.

Illustrated material checkpoint where hair, cloth, alpha, emission, and engine cost warnings are combined in a shader review.

06. LOD and Performance Spec

Performance specs should be written as acceptance criteria.

Define:

LOD count and naming
triangle reduction target or visual priority per LOD
whether skeleton and material slots remain stable across LODs
hair, cloth, accessory, and weapon behavior per LOD
texture resolution per platform or distance tier
acceptable compression behavior
preview conditions for checking visual degradation

Avoid declaring a character “optimized” without naming what it is optimized for. A hero face rig, a mobile NPC, a cinematic creature, and a crowd character optimize different things.

Illustrated LOD budget checkpoint with hero and crowd character contexts passing through different performance tiers.

Spec decision

Write the spec around the asset role

Write the spec around the asset role
When	Choose	Avoid
Hero character Fidelity risk	Define close-up material response, facial range, deformation proof, source files, and high-risk review areas.	Using crowd-asset budgets as the starting point.
Modular or customizable character System risk	Define attachment rules, shared skeleton behavior, material variants, naming, and QA combinations.	Treating each outfit or prop as an isolated art asset.
Mobile, UGC, or marketplace asset Platform risk	Define size limits, simplified materials, import stability, allowed formats, and platform rules first.	Approving a high-detail source asset before platform acceptance is clear.

07. Delivery and Acceptance Criteria

The spec should end with a delivery checklist that a lead can verify.

Acceptance criteria:

source files open without missing dependencies
final exports import into the target environment
scale, origin, skeleton, and naming match the spec
textures load with correct color space and compression behavior
UVs, material slots, and texture sets match the documented structure
LODs, morph targets, blendshapes, or animation data are present when required
the asset passes a neutral pose and at least one deformation or preview test
technical notes document exceptions, known limitations, and export presets

When the spec is written this way, approval becomes less subjective. The review can still discuss art quality, but production readiness has objective evidence.

If a spec cannot say what would fail acceptance, it is not yet a production spec. It is a preference list with technical language attached.