Fusion Architecture Map: how all node systems fit together

Fusion becomes much easier once you stop thinking of every node as another effect in one giant list. Several different data systems coexist inside the same Flow, and each system has its own compatible nodes and transition points.

The architecture map answers two questions: what kind of data is on this branch, and where does that data become a normal image that can join the final composite?

A wire may represent a 2D image, a mask, vector Shape data, a particle simulation, a classic 3D scene, a USD scene or control data such as tracking. Connections only make sense when the receiving node understands that data type.

When two nodes refuse to connect, the problem is often architectural rather than a software bug. Find the data boundary instead of forcing the connection.

Regular image nodes are where most finished branches eventually meet. Footage, titles, rendered particles and rendered 3D elements can all become image layers and then be combined with Merge, masks, color operations and MediaOut.

This is why learning normal 2D compositing first gives you a stable base even when the project later includes much more advanced systems.

Shape data usually becomes an image through SRender. Particle data becomes an image through pRender. Classic 3D scenes become images through Renderer3D. USD/U scenes use their own render/output stage.

Before that boundary you manipulate objects or simulation data. After that boundary you manipulate pixels. Knowing which side you are on determines which nodes make sense.

Tracking nodes often generate motion data that drives another branch. Channel, depth and color-space tools preserve or transform technical image information. Utility nodes control domain, caching, metadata and Flow organization.

These tools may not be the visual centerpiece of a shot, but they are what make a complex composite reliable enough for production.

Find MediaIn and MediaOut first. Then locate the major Merge nodes and identify separate islands: Shape, particles, 3D, tracking, color and utility. Look for SRender, pRender or Renderer3D to see where specialized data becomes pixels.

Once the architecture is visible, inspect the details inside each island. This is faster and more reliable than reading a hundred nodes from left to right without knowing which system each one belongs to.

Materials describe how a surface reacts to light; lights describe illumination; cameras define the view. None of these is a final 2D layer by itself. They only become visible after a 3D or USD scene is evaluated by the appropriate renderer.

This distinction matters when reading a Flow. A material branch belongs with geometry and shading before the scene renderer, while ordinary color correction belongs after the rendered image has entered the 2D pipeline.

If a material seems to do nothing, inspect assignment, geometry, normals, lights and renderer settings before reaching for a 2D workaround. The problem is often still inside the scene domain.

USD nodes operate on structured scene-description data: assets, hierarchy, transforms, geometry, materials, cameras and lights. They are designed for a different production problem from a simple stack of 2D effects.

Keep scene edits inside the USD branch while the hierarchy is useful. Render or output the scene only when the rest of the Fusion composition needs a conventional image rather than editable scene data.

Classic Fusion 3D and USD can both describe scenes, but they are not interchangeable families. Treat each as its own domain with its own compatible merge and render tools.

Tracking is an analysis stage. Point, planar, surface and camera trackers extract motion from MediaIn and produce information that can drive transforms, corner pins, masks, stabilization, 3D cameras or other downstream controls.

The track itself is not the finished visual effect. Validate it first, then transfer or connect the motion to the element that must follow the plate. A poor track will contaminate every stage built on top of it.

Thinking of tracking as control data explains why it can bridge several domains: the same analysis can guide a 2D graphic, a matte, a cleanup operation or a reconstructed 3D scene.

The visible RGB image is only one part of what may travel through a Fusion branch. Alpha, Z/depth, motion vectors, normals, mattes, stereo information and metadata can be just as important to later processing.

Operations that appear harmless can drop or misalign auxiliary information. Resize, Crop, Merge, Saver and color-space conversions should therefore be checked when a later key, depth effect or stereo stage behaves unexpectedly.

Inspect the channel you are actually troubleshooting. A beauty image can look correct while its alpha or depth data is already broken.

Merge-like nodes combine compatible data inside a domain: regular Merge combines images, Merge3D combines scene objects, SMerge combines Shape data, and other systems have equivalent family-specific operations.

Render nodes usually mark the exit from a specialized domain. SRender, pRender, Renderer3D and the USD renderer turn vector, simulation or scene data into pixels that ordinary 2D tools can process.

When two nodes refuse to connect or the result is invisible, ask which domain each side belongs to and where the conversion to image data is supposed to happen. That question resolves many Fusion architecture problems immediately.

Crop, Resize, SetDomain, AutoDomain, Loader, Saver, metadata tools, WirelessLink and Underlay may not create the hero effect, but they make a large composition practical to calculate, inspect and maintain.

Domain control can prevent expensive effects from processing empty space, intermediate renders can isolate heavy branches, and clear organization keeps a complicated Flow from turning into an unreadable web of wires.

A production-ready graph therefore has a technical layer as well as a creative one: source preparation, explicit boundaries, caching, metadata preservation and readable grouping all matter.

A pure 2D route can be as simple as MediaIn → Transform/Color/Blur → Merge → MediaOut. A mask such as Ellipse or Polygon connects to a mask input and limits an operation without becoming the main visible image.

A Shape route looks like Shape nodes → SRender → Merge; a particle route looks like pEmitter → particle modifiers → pRender → Merge; a 3D route looks like scene objects → Merge3D → Camera/Light → Renderer3D → Merge.

Tracking usually begins with MediaIn → tracker, then sends solved motion to Transform, Planar Transform, Corner Pin, a mask or a camera. Reading these recurring routes makes unfamiliar graphs much easier to decode.

Start with MediaIn and MediaOut, then find the major Merge nodes. After that, identify isolated islands of Shape, particles, 3D, USD, tracking, color/channel processing and utility operations instead of trying to read every node in sequence.

Mark the conversion boundaries: SRender, pRender, Renderer3D, USD render/output, and any place where tracking data is applied to an image or scene. Also note Crop/SetDomain and intermediate Saver nodes that change how the branch is evaluated.

A readable Flow should answer three questions: what creates the element, what controls its motion or appearance, and where it becomes a final image layer. Once those points are clear, even a very large comp becomes navigable.

Study regular 2D nodes first for everyday compositing. Move to Shape versus masks when visible vector graphics and effect mattes start to blur together, and use the particle guide for smoke, sparks, dust and procedural motion.

Use the 3D plus material/light guides for cameras, geometry and lit scenes; use the USD guide for structured scene assets; use tracking when a synthetic element must inherit real motion; and use the color/depth/channel guide when auxiliary image data matters.

The goal is not to memorize hundreds of node names. It is to recognize the data system, its merge rules and its render boundary so the detailed node reference becomes a map of a production pipeline rather than an arbitrary list of tools.