Automotive 3D Pipeline Validation
Reads a car's delivery tree and reports what is there, what is missing and what breaks the rules
Professional work · Apr 2026 – present
The problem
Graphics delivery for a car model spans authoring sources, delivery mesh packs, logic modules, scene projects and screenshot comparison sets. Answering how far a car has got, and what is wrong with it, meant opening half a dozen folders by hand.
Approach
- Register surfaces in a contract and keep rules in a catalogue with stable ids and severities, so adding a page is a descriptor, a reader and a renderer rather than a fork.
- Serve a Qt/QML desktop application, a web dashboard and a CLI from one core, so the same evidence reaches a person, a browser and a script.
- Drive native C++ helpers built against the Ramses rendering SDK and SDL3 from the Python layer, and validate the native report before recording any evidence from it.
- Read and validate the pipeline's own Lua scene logic and test configuration, because a tool cannot report on a delivery it does not understand.
Outcome
A pipeline map showing which stages a car has actually reached, a mesh rule engine with a stable finding catalogue covering geometry, UV, material, texture, skinning, scene and container rules, and a 3D workbench that draws findings on the geometry and isolates any part for review.
Evidence
Around 1,800 automated tests across 21 product surfaces, run against real delivery data for 26 car models, plus a source-and-build recovery snapshot verified to rebuild the application, native components included, on a clean machine.
Limitations
An internal alpha, not a production deployment. It is read-only against the source repository, never records a review verdict, and every visual judgement stays with the reviewer. The workbench inspects delivery meshes in authoring space; it is not a scene renderer. Client data and internal workflows are not published.
Built with
- Python
- C++ / CMake
- Ramses
- SDL3
- QML / Qt Quick
- GLSL
- glTF