
LAPS — Llama Asset Pipeline System
A modular Python pipeline tool built across multiple shipped titles. Each module was added because production needed it — not because it looked good on a CV.
The Story
LAPS started as a single naming convention script on a shipped title. Across multiple productions it grew into a full pipeline system covering asset validation, FBX export, texture processing, and Unreal Engine automation. Every module exists because a real bottleneck demanded it.
The architecture is intentional: one shared config file defines all studio rules, a common validator base class means every module speaks the same language, and a unified HTML reporter means leads and producers can read results without opening Maya or Unreal.
Pipeline Flow
Architecture
LAPS is structured in three layers. The core is DCC-agnostic — it runs anywhere Python runs. DCC-specific modules sit on top of it and only add what the environment provides.
Modules
Phase 1 — Core
Config Loader
StandaloneReads laps_config.json from the project root. Defines naming rules, mesh budgets, texture specs, and export settings in one place. Every module reads from here — change one file, update the whole pipeline.
Base Validator
StandaloneAbstract base class every LAPS validator inherits. Enforces a common interface: validate() runs checks, _pass() / _warn() / _error() record findings. The reporter talks to this interface — not to individual validators.
HTML Reporter
StandaloneCollects results from any number of validators and writes a single HTML report. Runs on any machine — no Maya, no Unreal needed to open it. Producers and leads get a clean pass/fail overview with per-module detail.
Naming Validator
StandaloneValidates asset names against studio conventions: correct prefix (SM_, T_, M_...), no forbidden characters, name length within budget. The first thing to run in any pre-export pass.
Phase 2 — Standalone Tools
Texture Analyzer
StandaloneValidates texture files using Pillow: power-of-two resolution, max size enforcement, format compliance, and sRGB heuristic detection by naming suffix (_D, _N, _R...). Runs on a single file or an entire folder.
Channel Pack Processor
StandaloneJSON recipe-driven channel packing — define source→output channel mapping in a config file. Supports dry-run mode to preview output before writing. Built on the same principles as the channel packing blog post.
Phase 3 — Maya
Mesh Quality Analyzer
MayaOpenMaya API 2.0 mesh traversal — detects non-manifold edges and vertices, degenerate triangles (zero-area faces computed via cross product), and triangle/vertex count against studio budgets.
UV Validator
MayaChecks UV set count, flags UVs outside the 0-1 tile, detects overlapping shells, and calculates per-face texel density using the shoelace formula — flagging faces that deviate more than 40% from the mesh average.
FBX Export Manager
MayaPre-flight checks before every export: frozen transforms, deleted history, no unknown nodes, material assignments. Auto-fixes what it can, blocks export on hard errors. Exports with UE5-optimised FBX settings and writes a JSON audit log.
Maya Shelf Button
MayaOne-click entry point — runs all three Maya modules in sequence with a progress window, writes the report next to the scene file, and opens it in the browser automatically.
Phase 4 — Unreal Engine
UE Asset Validator
unreal/asset_validator.pyPost-import validation inside Unreal Engine's Python API. Checks naming conventions, LOD chain completeness, material slot count, and texture sRGB / compression settings — all against the same laps_config.json used in Maya.
Material Instance Generator
unreal/mi_generator.pyJSON recipe-driven batch creation of MaterialInstanceConstant assets. Wires texture parameters, scalar overrides, and vector tints in one pass. Supports dry_run mode to validate the recipe before touching the project.
Niagara VFX Validator
unreal/vfx_validator.pyValidates Niagara systems against configurable platform budgets (PC / Mobile). Checks emitter count, estimated peak particle count, CPU vs GPU simulation mode, Ribbon/Mesh renderer cost, and warm-up time hitches.
Report Output
Every LAPS module feeds into a single HTML report. No DCC required to open it — producers, leads, and QA can read it in any browser.
The report below was generated by running demo_phase1.py against a set of test asset names — clean ones and intentionally broken ones. Open it live in your browser:
📸 A screenshot of the report will replace this area once captured — for now, click above to see the real output.
Using LAPS
Any module can be run from a single entry point. The same call works from a terminal, a Maya shelf button, or a CI/CD pipeline: