Bridging the two worlds
The conversation around AI in visual effects has too often been framed as a war: traditional craft against generative novelty, established pipelines against an unproven black box. We think that framing is wrong.
Maya, 3ds Max, Houdini, Blender, Unreal, Nuke, Fusion, and Resolve each earn their place in the pipeline by doing something well that nothing else does. ComfyUI earns its place as the open execution engine for generative work. Generative vendor models earn their place the same way. LARGE is the conductor — the layer that lets each tool participate as a peer under a shared Channel Contract, so a director's note travels cleanly from a Houdini layout, through a generative pass, back into a Nuke comp, with provenance intact and only the noted thing changed.
We don't replace the tools artists trust. We integrate with them, export to them, and contribute back to the open ecosystems among them. The goal is to bring AI into the pipeline on terms the existing tools can audit, attribute, and defend — not to build yet another silo.
The ecosystem we plug into
Nine production tools are first-class peers under the Channel Contract. We are starting with Houdini — the procedural workhorse of complex VFX — and growing outward from there. Each peer participates on its own terms: some are adapter targets, some are downstream finishing tools we export to, some are open ecosystems we contribute back to.
The Houdini adapter is the first concrete LARGE component — the proof that the Channel Contract holds end-to-end through a real production tool. Other adapters follow the same pattern. Realtime via Unreal is on the roadmap as a separate tier; we will get there honestly, not by promising it before the substrate is ready.
Complement, don't compete. Nuke and Fusion are downstream finishing tools — we export to them, not replicate them. Production-grade compositing has decades of refinement we won't try to beat; we hand off cleanly and let the finishing artists work where they already work best. ComfyUI is the open execution engine for generative workflows — we build on top of it, contribute custom nodes back to mainline, and present the resulting workflows inside the Channel Contract with full provenance and rights gating. None of these tools is a target to replace. Each is a peer whose strengths LARGE elevates rather than absorbs.
Built on the work of others
LARGE does not invent the vocabulary of on-set production data. The traditional VFX community already has one, and it is excellent.
Published May 12, 2026 by the VES Technology Committee, the guide catalogues 68 datasets across 17 categories — the data that real productions actually generate on set, who creates it, who consumes it downstream, and how it should flow. LARGE adopts it as the native vocabulary of our Channel Contract. Every Shot Bundle the broker dispatches, every provenance record the ledger writes, is tagged with stable VES dataset IDs.
We didn't have to build this taxonomy. The VES authors did, and they released it on a permissive license. Adopting it means studios, vendors, and supervisors speak with us in their own language — not a vocabulary we invented to sell them something.
ves-on-set-data.org · github.com/richardssam/on-set
VES across the Lenscowboy stack
VES adoption is not a LARGE-tier exclusive. The taxonomy threads through every module of the Lenscowboy pipeline. The result is one vocabulary spoken end-to-end, from script ingest through final delivery.
ves.5.5, photogrammetry becomes ves.5.3, prop
scans become ves.5.2. Budget and bid conversations speak
cost-per-VES-dataset alongside cost-per-shot.
ves.7.1.previz_techviz dataset
instance, scoped per Sequence or Shot. PAL imports inherit VES tags from their
source (LIDAR, photogrammetry, camera/lens), and PAL hands the resulting
bundle directly to downstream generative consumers without translation.
Giving back
Adopting the VES guide is one direction of a relationship. The other is contribution. We are committed to four deliverables, all under the same Apache 2.0 license the guide is released on.
-
Empirical schema feedback
When a real broker tries to route a VES-typed bundle to a generative vendor, things break in ways the spec authors can't anticipate from theory alone. We file those observations back upstream as GitHub issues and PRs — the by-product of building, returned to the community.
-
Category 17 · Generative Production Data
A proposed extension covering the data that generative pipelines actually produce: model identity, prompt records, training-data attestations, LoRA fingerprints, dispatch logs, C2PA manifests, retention and deletion certificates. Drafted now, refined against real production runs, contributed back to the VES Technology Committee for review.
-
Open Python reference loader
The VES guide ships as JSON and YAML; the Python community deserves a tidy loader with typed dataclasses and the obvious indexes. We've written one for our own use; we'll publish it as a small open-source package once it's shaken out internally.
-
C2PA × VES assertion mapping
The C2PA Content Credentials standard and the VES taxonomy are natural partners — one is the cryptographic envelope, the other is the inventory. We'll publish the mapping between VES dataset IDs and C2PA assertion keys, so any production using both can wire them together without inventing the bridge themselves.