Your Full NameTechnical artist
← Back to work

Pipeline / Pipeline / system

Asset Ingest and Validation Pipeline

A data-driven ingest path for normalizing DCC exports, validating dependencies, and producing deterministic engine-ready packages.

PythonYAMLGit LFSCIUnity AssetPostprocessor
No preview mediaThis study is intentionally documented without a hero image.
Selected workCase study media
Role
Pipeline Technical Artist
Contribution
Owned the boundary between DCC exporters, validation, package assembly, and engine import diagnostics.
Engine / environment
Blender / Houdini ? Unity
Platform
Windows / Build agents
Status
Architecture study
Team context
Designed for multiple departments sharing a delivery contract.
Year
2026
Technologies

Python · YAML · Git LFS · CI · Unity AssetPostprocessor

System shape

This page deliberately contains more system detail than a recruiter needs. It tests whether the framework can keep the overview compact while still giving an engineer enough information to understand ownership and failure handling.

Data flow

DCC export ? manifest generation ? dependency scan ? validation ? package assembly ? engine import ? report archive. Each stage emits a small artifact that can be inspected independently.

The delivery contract keeps each handoff inspectable.
ArchitectureThe delivery contract keeps each handoff inspectable.Source ↗
export-manifest.yaml
export.json
  source: assets/vehicle/body.blend
  content_hash: 7a9c...
  dependencies: [materials/paint.yaml, textures/body_basecolor.png]
  target: unity/vehicles/body

Failure handling

  • A missing dependency stops the package before engine import.
  • A recoverable naming issue is reported with a proposed rename.
  • A package is immutable after assembly so the report matches the imported artifact.
  • Build agents retain the manifest and validation summary for later comparison.
pipeline/validate.py
if not manifest.dependencies_complete:
    return Result.fail(
        code="DEPENDENCY_MISSING",
        owner="asset-author",
        retryable=False,
    )

Case study

Context

The production problem is not a single exporter bug. It is the accumulation of slightly different assumptions between departments and tools.

Case study

Constraints

  • Existing artists keep their DCCs and local iteration speed.
  • The engine importer cannot infer missing source intent.
  • The system must support partial migration without a flag day.
  • Every decision needs a useful failure message.

Case study

Ownership

I defined the manifest contract, the validation boundary, the error taxonomy, and the handoff documentation. The engine integration remained a separate ownership area with an explicit interface.

Case study

Scale

The design assumes thousands of assets, parallel build agents, and repeated re-imports during look development. Deterministic manifests are the anchor for comparing two runs.

Case study

Technical breakdown

The important technical choice is to keep normalization, validation, and package assembly separate. This lets a local artist run the first two stages without waiting for a full build, while CI repeats the same checks before delivery.

Case study

Results / impact

The system makes failure location visible and creates an auditable path from source file to engine package. The test page is intentionally text-heavy to challenge hierarchy and navigation.

Case study

Trade-offs

A manifest adds ceremony to small experiments. The pipeline therefore treats the manifest as lightweight metadata rather than requiring every personal prototype to pass through the production path.