Architecture

b2c3d is one web application with eight applications in it, a server that runs every capability as a job, and a set of model workers. Three ideas carry most of the weight.

A capability is an operation

Adding a capability is a single file: a typed parameter model, a typed result and a function. It registers itself, and from that one registration it gets an HTTP route, a command-line entry, a job with progress streaming and cancellation, and a tool for agents over the Model Context Protocol. The suite has dozens of them, from generate_concept and segment through generate_scene, texture_scene, autorig and retarget_motion to the exports.

Interface actions are registered the same way. A box drawn on Studio's canvas, a camera move or the hand-off from Concept is a command with a published schema, which a connected browser tab implements. Both registries generate the agent tool surface, so an agent asked to frame the camera and then retexture the sofa cannot tell which runs on a GPU and which runs in a browser tab, and does not need to. Permissions are a catalogue derived from the same registries, and agents get a policy and a kill switch that are checked fail-closed.

Assets are immutable

An asset's identity is a uuid that survives every edit; its bytes are stored by content hash. An edit writes a new version with the old one as its parent, so history is a graph and nothing is overwritten. That gives provenance, deduplication and permanent, cache-friendly URLs, and it is what non-destructive editing rests on. Deep links carry only asset ids, and state is recovered from provenance, so a link never goes stale.

A version has exactly one root file, the canonical bytes, and any number of representations: the same content in another format or resolution. A USD converted from a GLB is not a new version, and it hangs off the version it was converted from rather than the asset, so it can never claim to be a later version's USD.

Progress tells the truth

Long work reports what it is doing. A phase with no honest denominator shows an indeterminate bar rather than a percentage that stalls, and every job can be cancelled mid-run.

The stack

• Backend. Python and FastAPI, with capabilities as operations, run as jobs.
• Storage. Postgres for metadata and S3-compatible object storage for content-addressed blobs.
• Coordination. Redis for the job queue, leases and realtime fan-out. Application processes hold no durable state. Jobs are routed by what a worker already holds in memory rather than round-robin, work is leased, and delivery is at least once.
• Web. React and TypeScript with react-three-fiber for the viewport. One origin serves the marketing site, the suite and the API, with the applications route-split inside one bundle.
• Runtime. NVIDIA CUDA containers: a main image, separate workers for motion and materials, and R&D builds that are the only place research-only components exist. A residency manager is the only thing that touches a loaded model.

The test suite runs without a GPU on purpose. The queue, the event stream, cancellation, the asset store and the registries are where the platform's own bugs live, and none of them need one.

Built on a research model, not inside it

b2c3d began as a fork of MIDI-3D, the multi-instance scene diffusion research model. The inherited code keeps its licence and is mapped path by path. Vendored model code, MIDI-3D's and the others', may be repaired but not restructured, so it stays comparable with upstream. Everything around it, the platform, the applications, the asset model, the job system and the other stages, is our own.

How BigBluePipeline feeds it

b2c3d is the single source of truth for assets. BigBluePipeline is how artists reach it from the applications they already work in: they publish, version and import from inside Blender and Maya through one shared set of dialogs.

Its Exchange client sends each publish to b2c3d as a bundle: the artist's native file, such as a Maya scene, plus the interchange formats consuming applications need, such as glTF and USD. b2c3d stores the bundle as one asset placed at the shot it names, with the native file as its root and the interchange files as representations of the same version. A lookup by any of the files finds the same asset.

The two systems share a production model. BigBluePipeline's show, sequence and shot hierarchy is b2c3d's production tree, and its "versionless" asset, an element known as its latest, candidate or approved iteration, maps onto b2c3d's asset and its versions rather than a second table of identities. An iteration made at a shot supersedes the sequence or show asset of the same name for that shot, and an override is never silent: publishing a name that would override an asset above it is refused, naming what it would override and who made it, until the publisher confirms. Every publish from BigBluePipeline is flagged as human-authored in its provenance.

Designing the Exchange client also found a real bug before it ran: the library listing filtered by shot after limiting the result, so a busy organization could silently push a shot's assets out of the window. Every filter now runs in the query, before the limit.