pMerge

pMerge is used when two independent particle branches need to continue as one particle stream. Blackmagic describes it as combining particles from two streams; any particle nodes downstream of pMerge then treat the two streams as one.

The most important correction to the older article is topology: one pMerge is not an arbitrary multi-input collector. It has exactly two inputs with identical particle-data meaning. One connector is orange and the other green, but they are not Background and Foreground and there is no A-over-B layer order.

Both inputs accept only the output of particle nodes. Typical sources include pEmitter, pImageEmitter, pChangeStyle, pTurbulence, pFriction, pBounce, or the output of another pMerge. MediaIn, Background, Text+ and normal RGBA images are not valid pMerge stream inputs.

pMerge does not convert the particle system into an image. Its output remains Particles data. A downstream pRender is normally used to convert the particle system into either a 2D image or 3D geometry depending on pRender Output Mode.

With pRender in 2D Output Mode, the regular image domain begins after pRender. At that point the result can be processed by Merge, Glow, Color Corrector and MediaOut. This is the key boundary: pMerge combines particle data, while a regular Merge composites images.

With pRender in 3D Output Mode, the particle result enters the classic Fusion 3D pipeline and can continue through Merge3D and Renderer3D. pMerge itself does not change: it still combines particle streams before the render boundary rather than merging 3D geometry or pixels.

The pMerge Inspector is intentionally almost empty. Blackmagic explicitly describes the node as having no controls whatsoever. This is normal behavior rather than an incomplete or broken Inspector.

No-control means that system behavior is configured around pMerge. Emitters define particle creation, forces and modifiers change motion or state, style tools define appearance, and pRender defines the 2D/3D output boundary. pMerge only joins the two incoming streams.

Blackmagic specifically documents that Sets already assigned to particles are preserved when the streams are combined. That matters because downstream particle nodes can still isolate a particular Set after pMerge.

pMerge does not create, rename, or automatically assign Sets by input. If sparks and smoke need different downstream behavior, assign meaningful Sets upstream and let downstream Conditions filter those Sets after the merge.

Three streams require a cascade: A + B → pMerge 1, then pMerge 1 + C → pMerge 2. Add another two-input pMerge stage for each additional stream. There is no dynamic Particle 3 socket or input-count control.

Cascading requires no special conversion because a pMerge output is still an ordinary particle stream and can connect to either particle input of the next pMerge. Clear node names become increasingly important as the cascade grows.

Particle 1 and Particle 2 are equivalent data roles. Swapping the two inputs is not analogous to swapping Background and Foreground on a regular Merge; pMerge does not perform Over, Add, z-order, or any other pixel-compositing operation.

pMerge is not a particle-count optimizer. The downstream branch receives the combined workload from both streams, so a heavy A branch plus a heavy B branch still produces a heavy system for later particle calculations and rendering.

Place pMerge where branch behavior actually becomes shared. If A and B need different turbulence, drag, collision, or style changes, process them separately and merge later. If one force should affect both in the same way, merge earlier and place the force downstream.

Preserved Sets let you merge early without losing every distinction between branches, but those Sets must already exist. pMerge does not infer semantic groups such as smoke, dust, or sparks from which connector they used.

pMerge has no Effect Mask, Region input, Bitmap input, or Conditions panel controlling its merge. Spatial gating belongs to particle modifiers that explicitly support Conditions/Region; do not project the normal 2D-effect mask model onto pMerge.

In a complex Flow, treat pMerge as a typed junction inside the particle domain. Ordinary image-processing nodes do not belong in that stream until pRender produces an image, or until the particle system is converted to the appropriate downstream domain.

For troubleshooting, start with pEmitter A + pEmitter B → pMerge → pRender. Once that minimal graph works, add modifiers one at a time so routing problems remain separate from emitter, Set, force, or render-mode problems.

Fusion 21 still lists pMerge as a current particle-system feature. The two-input/no-control/Set-preservation contract is established in Blackmagic particle documentation; exact target-build UI validation remains a separate live check.