Niagara Scalability: Effect Types

Apr 12, 2021.Knowledge

Niagara provides the Effect Type asset to act as a way to group related effects and specify reusable settings for them. Currently Effect Types are geared towards scalability settings, but we may add other properties in the future that make sense to bundle with effects of the same type. Effect Type scalability does not need to use the System’s simulation, that is, it runs in native C++ rather than in Niagara’s scripting runtime and is therefore more preformant.

The scalability settings can be overridden at the individual system and emitter levels, so specific effects can tailor the scalability settings to their needs, without having to copy over the individual settings that will stay the same.

The scalability settings from Effect Types and their overridden settings will be used at cook time to prevent the packaging of effects if they will not be used on a specific platform, saving on space.

You can set the Effect Type in the System Properties and specify a default Effect Type in the Niagara section of your Project Settings.

Effect Type Scalability Settings

Update Frequency

Controls how often the scalability state of systems with this effect type are evaluated. This allows us to have per frame evaluation for expensive or critical player effects but have a lower update rate for less important effects that can tolerate a little latency. A lower update rate means less overhead for each effect.
Some effects like impacts can also be set to evaluate only on spawn. There’s little reason to evaluate short lived effects every frame.

Cull Reaction

Controls what an effect does when it fails the scalability checks. For example, when it goes beyond the Max Distance.

The options are a combination of two choices:

  • Kill or Asleep: Controls if the system can reawaken.
  • Clear (on/off): Clears existing particles immediately or allows them to complete naturally.

For example Burst FX should use the KIll option since they spawn once, they don’t need to reawaken, and their short lifetime makes them a good candidate for clearing.

Significance Handler

Controls the relative significance of instances in the scene. Less significant effects will be culled first. This is paired with instance count culling.

  • None: No significance handling.
  • Age: Newer systems are more significant. This can be useful for things like impact effects, where culling a newly spawned effect would be visually disruptive.
  • Distance: Effects closer to the camera are more significant.

System Scalability Settings

Scalability settings applied to the whole system. They are stored as an array, and each entry corresponds to a set of platforms based on quality buckets (Low, Medium, High, Epic and Cinematic).

Platforms will be included in their respective buckets, and some platforms are in multiple ones. You can add and remove platforms for a setting entry to have finer control over scalability for specific platforms.

Here’s an example of a simplified System Scalability Settings array. For each entry, those settings apply to the entire bucket that’s highlighted, excluding any that are removed (signified by the red “-”). The entry will not apply to any of the buckets that are grayed out, unless they manually opt-in (signified with the green “+”).

In this example Low, Medium and High buckets will have a Max Distance of 1000, except for Windows platforms in the High quality bucket. They will be included along with Epic and have a Max Distance of 1500. The Cinematic bucket will have no scalability applied.

Each setting can have any combination of the following checks. If they are not enabled, no testing will be done for that check.

  • Max Distance: If a system goes beyond this distance from the nearest camera it is culled.
  • Max Effect Type Instances: The max number of instances allowed for this effect type. This count is shared across instances of all systems using this effect type. Uses the Significance handler to decide which systems to cull.

Example: This allows the definition of a max number of environmental effects, without having to worry about each individual system defining a max and how these would interact with one another.

  • Max System Instances: Similar to Effect Type Instances, but only applies to instances of a specific system. Can be useful for specific effects that should be prioritized, but should still have the same general scalability as its Effect Type.
  • Max Time Without render: If a system is not renderer for this amount of time then it is culled. Is effectively a visibility cull that includes frustum culling and occlusion. This can only work with systems using fixed bounds.

Emitter Scalability Settings

These settings are used as a default for various emitter specific properties.
Right now this is limited to spawn count scaling but this may be extended in future.
Spawn Count Scale: This value is used as a scale for all spawn counts in our standard spawning modules.