Sort type selection¶

Sorting Type on a ParticleEmitter decides whether (and how) particles are sorted before drawing. The choice is almost always driven by the blend mode of the assigned Particle Material; sorting cost is a secondary consideration.

The four options¶

Identity: Spawn-order draw. No per-frame sort cost. The index buffer is allocated once with identity mapping and reused every frame. Default.
Depth: Per-frame back-to-front GPU sort by distance to the sorting camera. Required for correct alpha blending of transparent particles: without it, particles draw in arbitrary order and transparency goes wrong at overlaps.
Reverse Depth: Per-frame front-to-back GPU sort. Cheaper than Depth for opaque particles because early-z rejects fragments hidden behind already-drawn particles. Incorrect for transparent materials.
Unsorted: No index buffer is allocated. Saves the per-emitter memory cost of an index buffer. The assigned ParticleMaterial must not reference SortingIndicesBuffer, or drawing will crash.

Picking by blend mode¶

Material blend	Sort type	Why
Transparent (alpha-blended)	`Depth`	Back-to-front is the only order that composes correctly under alpha blending.
Additive	`Identity` or `Unsorted`	Additive blending is commutative; order does not affect the result.
Opaque (alpha-tested)	`Reverse Depth`	Front-to-back maximises early-z rejection. `Identity` also works but is slower at high overdraw.
Subtractive or other non-commutative blends	`Depth`	Treat as transparent-style; order matters.

Cost¶

Sort dispatches are indirect: the per-frame workgroup count is derived from the active particle count, not MaximumAmount. An emitter with MaximumAmount = 50000 and 5k live particles pays a 5k-element sort, not a 50k one. The cost of Depth / Reverse Depth is therefore real but scales with what is actually on screen.

MaximumAmount still matters for a sorted emitter’s memory footprint: sort scratch buffers (radix counters, local offsets, index buffer) are allocated to cover the full pool at load. Keeping MaximumAmount tight on sorted emitters saves memory, but the per-frame compute savings come from a lower live count, not a smaller pool.

Identity and Unsorted are free per-frame (no sort dispatch).

Practical heuristics¶

Start with ``Identity``. Switch to Depth only if you can see transparency artefacts.
Fire / smoke (additive or multiplicative blends): Identity is fine. Gains from sorting are invisible.
Alpha-blended textured billboards (soft particles, rain drops on a bright sky): Depth.
Mesh-instanced 3D particles with opaque materials (debris, rocks): Reverse Depth.
Memory-constrained targets: if the emitter does not need sort indices, pick Unsorted to drop the index buffer allocation.
Subemitters: inherit sort choice from the source when they share visual style (fire → embers: both additive, both Identity); diverge when blends diverge (fire → smoke: fire additive Identity, smoke transparent Depth).

Gotchas¶

ParticleSystem.SortingCameraOverride lets you point sort key computation at a non-default camera. Useful when particles live in a secondary viewport with its own camera. If empty, the scene’s default camera is used.
A material that declares a SortingIndicesBuffer uniform must not be paired with Unsorted: the binding has nothing to read. The shipped 2D rendering materials all reference the sort buffer, so keep those on a sorted mode.