RT4D: Dimensional Media Engine

A governed GenBlaze media pipeline for MRS structure, live website demo surfaces, B2 caching, provenance, and CECP evidence trails.

Comment

Inspiration

Most generative media demos stop when an image appears. RT4D began with a stricter question: can a media system explain where a frame came from, preserve the evidence next to the pixels, and disclose which parts are live, cached, optional, or unavailable?

Mandala Rendering System treats media generation as governed infrastructure. GenBlaze coordinates the workflow, Backblaze B2 stores durable media and manifests, and CECP evidence trails make the demo auditable instead of hand-wavy.

What it does

This submission demonstrates a governed still-image and demo-video media pipeline with live website stills, demo caching, provenance, and honest provider disclosure.

The verified path shown in the updated demo is:

  • Live hosted MRS / GenBlaze website surface
  • MRS structure, lighting, composition, and evidence framing
  • deterministic structure/cel plates
  • ffmpeg H.264 video export
  • Backblaze B2 demo-cache storage model
  • manifest sidecars with intent, world, timeline, provider, model, parameters, and SHA-256 hashes
  • provider fallback disclosure
  • CECP evidence-trail documentation

The demo-cache layout is canonical:

genblaze-media/demo-cache/{shot_id}/f0000/render.png genblaze-media/demo-cache/{shot_id}/f0000/manifest.json

The live API can request a cached frame. A cache hit is labeled b2-cache. A live render is labeled live-generate. If cached beauty is missing and painters are unavailable, the system fails closed as structure-only rather than pretending a provider succeeded.

How we built it

The GenBlaze media app is a FastAPI service inside the Mandala Rendering System repo. It contains render/cache orchestration, Backblaze B2 upload path, local sidecar writing, provider availability disclosure, demo-cache retrieval, and the governed handoff used by the video pipeline.

The pre-render CLI can create schedule hints, render shot frames, write local sidecars, and optionally upload the resulting PNG and manifest pair to B2:

cd mrs/apps/genblaze-media python -m app.pre_render --plan plans/demo-shot-plan.example.json --schedule-hint-only python -m app.pre_render --shot-id mandala-open --frames 0-23 --upload-b2

The live demo path can then run against the cache:

export GENBLAZE_DEMO_CACHE=1 export GENBLAZE_DEMO_CACHE_SHOT=mandala-open npm run genblaze:media

How we use GenBlaze

GenBlaze is the media workflow boundary. It coordinates request handling, provider selection, storage handoff, metadata normalization, and result indexing.

The declared provider cascade is:

gmi to fal to nvidia to hfspace

The current implementation is careful about disclosure: a provider is only described as active when credentials and local probes support that claim. GMI pre-rendering is optional and requires GMI_API_KEY plus the GMI package. The demo does not claim live GMI generation when that environment is not configured.

How we use Backblaze B2

Backblaze B2 is the durable cache and provenance store. Demo frames and their manifests are written under stable object keys so a judge or operator can understand exactly which shot and frame they are seeing.

Manifest sidecars include:

  • intent_id
  • world_id
  • timeline_id
  • parameters
  • provider and model
  • asset_sha256
  • source label

Those fields form the CECP evidence trail for the media artifact.

Honesty boundary

The updated video uses actual screenshots from the live hosted site at https://mandala-rendering-system-mrs.onrender.com/.

Hybrid ownership is disclosed plainly: MRS contributes structure, lighting, composition, orchestration, provenance, and evidence. AI/final-pixel systems remain the polish/final-output layer when used.

StoryForge audio and broader media orchestration are declared integration boundaries, but they are not overclaimed as the proven live path in this video.

The proven live path for this demo is the still-image plus cache pipeline: B2 cache, source labels, provider disclosure, sidecar manifests, and CECP evidence docs.

Challenges we ran into

The hard part was not just generating an image. The hard part was keeping the demo honest across caches, optional providers, local credentials, hosted CPU limits, and durable object storage.

The pipeline now treats labels as part of correctness. Cached frames are not called live renders. Missing painters do not silently produce fake success. Provider availability is disclosed instead of assumed.

Accomplishments that we are proud of

  • Governed still-image demo-cache path
  • Live website demo surface used in the updated video
  • Canonical B2 layout for render PNGs and manifest JSON
  • Provider fallback disclosure
  • Optional GMI pre-render boundary
  • CECP evidence trail docs
  • Tested fallback labels: b2-cache, live-generate, and structure-only
  • Local verification: demo-cache and polish tests passing

What we learned

A reliable generative-media demo needs more than an impressive frame. It needs stable object IDs, durable storage, precise labels, replayable manifests, and the humility to say exactly what is live and what is only declared.

GenBlaze made the orchestration boundary clear. Backblaze B2 made the evidence durable. MRS supplied the governed rendering substrate.

What's next

The next step is to deepen the live provider fanout, wire richer image-to-image polish paths, and continue expanding MRS from still-image evidence into broader governed media workflows while preserving the same source-label and evidence discipline.

Built With

Share this project:

Updates