In Unreal Engine 5.8, Niagara GPU ribbon may suffer continuously shuffling ribbon link order under specific conditions.
This issue does not occur in Unreal Engine 5.7. It is reproducible only in Unreal Engine 5.8.
The issue occurs both when:
Migrating an existing UE 5.7 project to UE 5.8.
Creating a brand-new UE 5.8 project using the default, out-of-the-box engine configuration.
This indicates that the issue is a regression introduced in UE 5.8, rather than a project migration issue.
Known trigger conditions:
The emitter is using GPU Compute Sim
The particle count is greater than 64
Particles.RibbonLinkOrder is explicitly assigned, either by using a Set Parameter module or the Partition Particles module, rather than being left undefined.
As a temporary workaround, we leave Particles.RibbonLinkOrder undefined in our GPU ribbon emitter and instead use an unrelated particle attribute (for example, Particles.PartitionParticles.NormalizedIndexInPartition) to drive the particle behavior logic.
By avoiding any explicit assignment to Particles.RibbonLinkOrder, the ribbon is generated correctly and the issue no longer occurs. This workaround allows us to circumvent the bug while preserving the intended particle behavior.
Create a new Minimal Emitter in a new Niagara System.
Set the emitter’s Sim Target to GPU Compute Sim.
Add a Spawn Burst Instantaneous module to Emitter Update, and set Burst Count to any value greater than 64. Optionally limit Loop Count to 1.
Set Particles.RibbonLinkOrder using Return Normalized Exec Index.
In the Initialize Particle module, set Position Offset to any value that is derived from or offset by RibbonLinkOrder (for example, placing particles along an axis based on RibbonLinkOrder).
Add a Ribbon Renderer.
Observe the Niagara System in the Niagara System Editor preview, Level Viewport, or Play In Editor (PIE).
Expected result:
The ribbon should be constructed in the same order as the particles’ execution order, producing a continuous ribbon with a stable topology.
Actual result:
The ribbon segments are unexpectedly shuffled, resulting in an incorrect ribbon order. The issue consistently occurs when the burst count exceeds 64.
This issue also has a secondary consequence. If a Niagara Sim Cache is recorded from a ribbon effect, leaving Particles.RibbonLinkOrder undefined results in incorrect ribbon connectivity during Sim Cache playback.
This behavior is not new to UE 5.8; it is also present in UE 5.7. However, because the current workaround for the UE 5.8 regression is to leave Particles.RibbonLinkOrder undefined, it is no longer possible to produce a Sim Cache that replays correctly.
In other words, the workaround avoids the ribbon ordering bug during live simulation, but it causes the recorded Sim Cache to lack the ribbon link information required for correct playback, resulting in a broken ribbon during cache replay.
Niagara Sim Cache is heavily used in our cutscenes to ensure deterministic and consistent playback across runs. As a result, the inability to generate a valid Sim Cache for ribbon effects has a significant impact on our production pipeline.
Although the current workaround restores correct ribbon behavior during live simulation, it prevents us from baking ribbon effects into Sim Cache with correct ribbon connectivity, making the workaround unsuitable for our cinematic workflow.
Our programmers investigated further and found that after changing the FRibbonLink typedef in the #else branch from int to float, resolves both of the following issues:
Incorrect ribbon ordering when the particle count exceeds 64.
Incorrect ribbon connectivity when the maximum RibbonLinkOrder is equal to or greater than 1.0. (this additional bug wasn’t reported initially, but I only encountered it today when testing GPU ribbon with particle count less than 65.)