Skip to content
Fluxx

DCC Bridges

Fluxx provides a DCC bridge layer that lets artists work in their existing tool (Nuke, Maya, Unreal, Houdini, Blender, Resolve, Substance, AE) while the Fluxx Vault, ComposiTrack, and Fabrixx pipeline handle the data flow underneath. The bridge is the integration surface. The DCC is the artist’s workspace, running inside a Fabrixx VM that the pipeline service provisioned.

The DCC bridge is the seam where the Fluxx-native primitives (Vault, finish-track assignment, ComposiTrack sub-frames, AI provenance, VM lifecycle) become operational inside a DCC session. Six surfaces have AYON analogs; two are Fluxx-native with no AYON equivalent.

v0.1 priority DCC list (working assumption)

Per Fluxx_Pipeline_Architecture_v0.1.md §10 gap item 4: Nuke + Unreal + Maya is the working assumption. Houdini Solaris next. Resolve, 3ds Max, Blender, Substance Painter, After Effects later.

Open call: the precise v0.1 cut is not locked. Surfaced as Task #13 priority #4 in the current build phase plan. Engine direction (Chaos V-Ray vs Unreal) was tested at Demo 1 and shifted to Unreal in Norman V7 M3.5; that lock pulls Unreal in early. Nuke is non-negotiable as the comp substrate. Maya is the canonical 3D modeling and animation tool across the industry. The three together cover the operational scope of a Phase 1 production.

Bridge architecture (six surfaces with AYON analogs)

1. Host bootstrap

Pipeline service launches a Fabrixx VM with the bundle baked into the image at provision time. The image includes the DCC binary, fluxxd in-VM daemon, the bundle’s addon set materialized in the VM filesystem, and standardized environment variables (FLUXX_PIPELINE_URL, FLUXX_API_KEY, FLUXX_BUNDLE_NAME, FLUXX_TENANT_ID, FLUXX_PRODUCTION_ID, FLUXX_HEADLESS_MODE, plus context). Artist connects via remote desktop (PCoIP or NICE DCV); the DCC is already running with the Fluxx plugin loaded.

2. Plugin SDK shape

fluxx_plugin.py manifest at plugin root, six-folder directory structure, BaseFluxxPipelinePlugin (server-side) plus FluxxPlugin (client-side) with extended lifecycle hooks (on_session_start, on_session_end, on_context_change, on_vm_provisioned, on_vm_teardown), interface markers (IHostPlugin, IPluginPaths, ITrayPlugin, plus Fluxx-native IProvenancePlugin, ITrackAssignPlugin, IStagePlugin). See Plugin SDK for the full SDK breakdown.

3. Publish path (Pyblish-shaped)

Three-stage discipline ported from Pyblish:

  • Validate. Plugins from client/<plugin>/plugins/publish/. Halt-on-validation-failure semantics.
  • Extract. Scratch path /fluxx/scratch/<session_id>/<publish_id>/. Ephemeral.
  • Integrate. Writes to Vault: each Representation uploaded to cloud object storage in the tenant’s storage namespace, content-addressed by hash, Vault record created via pipeline service API. C2PA pass-through, AI provenance fields, camera origin, and pipeline origin all attached at integrate-time. Emits publish.completed persistent event.

4. Load path

Four-step resolution: Resolve Version → Representation via Vault API → resolve Representation → cloud object storage URL (provider-agnostic: s3://, gs://, az://) → materialize URL → in-VM cache (/fluxx/cache/, LRU eviction bounded by VM disk) → DCC loads from cache. The cache layer is the critical seam preventing every load from hitting object storage at S3 latency.

5. Event spine

Persistent plus fire-and-forget split adopted verbatim from AYON, plus tenant scoping at every event, plus cost-attribution events as a first-class topic family (vm.provisioned, vm.teardown, render_pass.completed, cache.hit, cache.miss), plus stage configuration events (stage.configuration_loaded, stage.wall_repositioned, stage.lighting_recipe_applied). See AYON Port / Reject for the underlying event spine pattern.

6. Headless mode

FLUXX_HEADLESS_MODE env var flag suppresses UI; same code path runs in render workers. Plus: headless VM provisioned by the render-job scheduler not by artist-session request; publish path bypassed in render mode (workers consume, never publish); cost attribution attaches at the worker VM-hour level.

Bridge architecture (two surfaces Fluxx-native, no AYON analog)

7. VM lifecycle integration

Pipeline-service-owned provisioning is the fifth Fluxx-native primitive. Six lifecycle events:

  • vm.provision_requested (request received)
  • vm.provisioned (VM ready, image baked, addon set materialized)
  • vm.session_started (artist remoted in)
  • vm.context_changed (artist switched project, shot, or task)
  • vm.teardown_requested (session end or schedule)
  • vm.teardown (VM released)

Plugin hooks fire at each event: on_vm_provisioned for pre-warm, cache populate, register; on_vm_teardown for flush state, emit final events, release locks. No analog in AYON because AYON’s launcher assumes a long-lived host.

8. Domain extensions

Fluxx-native data model extensions the DCC bridge surfaces:

  • ComposiTrack sub-frame data model. Three Representations per shot: ChromaTrack, ContentTrack, CompensationTrack. First-class in the Vault.
  • Finish-track assignment. Per-shot finish_track field (Near-Time or Near-Time VFX). ITrackAssignPlugin marker. shot.track_assigned events. See Pipeline Architecture > primitive 4.
  • AI provenance. prompt, seed, model, model_version, LoRA, generation_timestamp, generation_tool, parent_asset_id, plus C2PA Content Credentials pass-through. IProvenancePlugin for ingest, display, enforcement. See Q-G18 and Q-G50.
  • Cost attribution hooks. cost.attributable_event events from render, load, and agent invocation. Consumed by the attribution service that produces per-shot, per-finish-track, per-tenant cost.

Framework for adding new DCCs

A Fluxx DCC plugin author writes fluxx_plugin.py, lays out the six-folder directory, implements BaseFluxxPipelinePlugin (Pydantic settings with six scopes: tenant, production, studio, project, site, tenant-site), implements FluxxPlugin (lifecycle hooks), declares capabilities via interface markers, declares plugin paths via IPluginPaths (pointing at directories with actions, create, load, publish, inventory, provenance, track-assign, stage, cost-attribution plugins), implements publish plugins (Pyblish style → Vault), implements load plugins (resolve to cache → DCC native load), subscribes to events, supports headless mode, and registers VM lifecycle hooks. Packaged via create_package.py, registered with the Fluxx pipeline service’s plugin registry, pinned in a bundle, bundle assigned to a mode (Production / Staging / Development) for a tenant.

The framework is consistent across DCCs. The per-DCC plugin author writes the DCC-native parts (Maya MPxCommand, Nuke menu items, Unreal blueprint nodes) and inherits the bridge layer wholesale.

Per-DCC build envelope (Cat 1)

Per the dev plan v0.3 cost bands (see Build Categories Cat 1):

  • Nuke: $80K-$200K per plugin module
  • Unreal Engine: $150K-$400K (larger due to nDisplay plus engine integration)
  • Maya: $80K-$200K
  • Houdini: $80K-$200K (Solaris next priority)
  • Blender / Resolve / Substance / AE: $30K-$100K each (later phase)

Module-count band per dev plan rollup: 5 to 8 modules total, $700K-$1.7M outsourced.

Source dependencies

  • 02_Working/Pipeline_Research/DCC_Bridge_Framework.md (primary blueprint)
  • 02_Working/Pipeline_Research/Plugin_SDK_Comparative.md (SDK comparative)
  • 02_Working/Pipeline_Research/Fluxx_Pipeline_Architecture_v0.1.md (bridge architecture context)

Synthesis gaps

Per DCC_Bridge_Framework.md §12 (deferred to v0.2):

  • Per-DCC plugin specifics (Maya, Nuke, Houdini, Unreal, Resolve hooks)
  • Path-template equivalent for cache layout
  • Hot-reload mechanics in VM context
  • Event topic catalogue (specific topics that fire)
  • Plugin SDK governance: public or internal-only at v0.1
  • DCC selection priority for v0.1 (still working assumption: Nuke + Unreal + Maya)

Audience visibility

industry, vendor, production, sales, director, investor.