The reasons behind Niagara’s development
With an expanding user base, the need for a particle system that was more robust and worked across all industries was felt more acutely. The use of Unreal has now extended beyond gaming to industries including architectural visualization, automotive and industrial design, virtual production, and training simulations. This had led to demands for accurate, efficient, and easy-to-use particle workflows. The newer workflows demanded that artists should be able to work on particle systems easily without having to deal with a complex set of tools while also letting the technical team members have access to tools that may not be very user-friendly but allow them to create customized solutions. Particle systems also needed to be more fully integrated with the main code of the Unreal app.
Against the background of these scenarios, the shortcomings of the Cascade particle system started becoming more evident.
The development of Niagara was driven by the following goals:
- It should be easy to use and put control in the hands of the artists
- It should be customizable and programmable in every aspect
- It should have an improved toolset for operations such as debugging, visualization, and performance
- It should be able to seamlessly interface with other parts of Unreal Engine
Perhaps the biggest issue with Cascade was that it was very difficult to add additional features or customized behaviors to particle systems. Artists were heavily dependent on programmers to add new features. Niagara has made it possible for artists to develop additional features on their own, giving them more control.
Every aspect of Niagara can be customized. Cascade does not offer such flexibility. In Niagara, every parameter of forces acting on particles can be tweaked and connected to external parameters. The user can, for example, drill down and change the force of gravity acting on an object over time using a sine wave. This open-ended architecture puts no limits on the kind of effects that can be achieved with Niagara.
Cascade used CPU resources very inefficiently. CPU and GPU simulations would work very differently. Niagara is optimized to handle both GPU and CPU sims and achieve parity between them. Niagara also has two great tools for debugging simulations. In the Niagara Editor, you can use the Debug Drawing tool to see visual representations of the particle system, while in the game level you can use Niagara Debugger, which shows detailed information about given particle systems in the heads-up display. This helps pinpoint performance and behavioral issues in your particle systems easily.
Niagara works very well with other parts of Unreal Engine. For example, a game object’s speed data can be shared very easily with the Niagara particle system to drive various parameters in the particle system, such as sprite size, the brightness of the particle, or the amount of gravity acting on the particle. This lets game designers create fine-tuned game mechanics very easily in a short amount of time. You also read data from external sources.
Cascade did have some upsides. The module-stacking workflow was a great way to get an overview of the particle system at a glance, and Cascade was very approachable for non-technical artists. However, the node graph paradigm of Unreal is very powerful and was necessary to adopt to deliver the next-gen features promised by Niagara. So, a hybrid method with both a stack and graph was chosen for Niagara, which derives the advantages of both paradigms.
Figure 1.15 illustrates the stack paradigm in Niagara where modules are stacked on top of each other. The stack-based workflow is simpler and suitable for designing basic particle behaviors.
Figure 1.15: The stack paradigm in a Niagara Emitter node
While the stack paradigm is simpler, it can be a bit limiting in its flexibility and hence its capabilities. Therefore, when such flexibility and power is required, a node-based approach is used, as shown in Figure 1.16. You will find Niagara adopting a node-based workflow for designing Niagara modules.
Figure 1.16: The graph paradigm inside a Niagara module
As we will learn later in the book, Niagara also makes it easy for teams to work in parallel developing particle systems by employing a modular approach to development and eliminating production bottlenecks.
All these reasons have helped Niagara replace and improve upon the old Cascade particle system and leave it perfectly poised to take on the challenges of delivering particle effects for the wide variety of industry verticals in which Unreal Engine 5 finds itself being used.