20. Dezember 2019
How Epic is integrating Niagara into Fortnite
Hi, I’m Scott Kennedy, the lead FX artist on the Fortnite development team. At Epic, we like to “dog food” our own tools, and we’re doing just that with Niagara using Fortnite as our sandbox. For those unfamiliar, Niagara is the new Early Access particle tool that we’re actively working on to replace the aging Cascade editor. While we’re not recommending developers switch to Niagara for development at this time, we’re working to make it a far more flexible and data-driven toolset that is much more freeing compared to Cascade.
With Fortnite Chapter 2’s emphasis on water, we added a whole new way to traverse the map as well as a visual change to the landscape. With these goals in mind, we decided to push a brand new water system. When we started building this new tech, we saw a perfect opportunity to use Niagara. We could think of no better way to harden our tool than to throw it at millions of players across mobile all the way up to high-end PCs. This blog entry discusses what we’ve learned integrating Niagara into our existing pipeline. My hope is that some of the trials and tribulations that our team went through can serve as lessons and provide a good starting place for other developers hoping to use the new particle tool.
What we learned
Niagara is full of great features that were simply not possible in Cascade, like Emitter inheritance(more on this later) and a programabile workflow, but as the saying goes, “with great power comes great responsibility.” It became apparent that organization is paramount to a smooth Niagara pipeline. Niagara generates a lot more assets than Cascade does so having proper naming conventions, file structure, and working guidelines is a necessity in my opinion. Here is an example of the naming conventions we landed on:Niagara Systems: NS_SystemExample
Niagara Emitters: FN_EmitterExample
Niagara Modules: FN_ModuleExample
Niagara Dynamic Inputs: FN_DynamicInputExample
You may be wondering why we landed on FN_ for multiple asset types. This helps our artists know what are Fortnite-approved assets when searching within the tool. It provides an easier at-a-glance understanding when looking at a list of assets. Since you are largely adding these assets from menus within the tool and not dragging from the Content Browser, we didn’t need to add redundant prefixes to differentiate Emitters from modules, for example.
Another procedure we implemented was to have a gatekeeper for generating new Emitters and modules. In our case, Andrew Melnychuk is our FX Technical Artist who is dedicated to support the FX team with module creation and highly complex math problems. He’s also the general facilitator for Niagara on the Fortnite team. By having one person on the team be the only one creating new Emitters or guiding other artists with building their own new Emitters, we can, in theory, keep asset bloat down and reduce duplicate work across multiple Emitters and modules. This has also given someone the head space to try and build foundational Emitters to support the types of FX we create on Fortnite all the time (Think Master Materials). Having this dedicated role has also dramatically reduced our reliance on engineers to create new features.
Niagara supports inheritance in multiple ways. One way to do this is to make children of Emitters much like Blueprints or Materials. This is a wonderful feature that saved us some painful refactor work and time during Chapter 2’s development. Let’s say you wanted to create a new scale-by-distance module on all your weapon effects. You can add it to the parents and all the children get it instantly. Niagara is incredibly flexible in that artists can now create default Emitters for the rest of the team to share. In exploring how we would set up our Emitter structure, two schools of thought emerged. One: build only a few broad and generic Emitters and have the FX team use those few starting points much like you would in Cascade. Two: build very specific Emitters that support specific asset types in the game like gun_sparks and gun_smoke. Using a broad and generic approach keeps asset bloat down but requires artists, in theory, to start from scratch every time they are building a new effect. Conversely, going with our second train of thought of creating very specific emitters can jump start artists by adding very specific and art-directed emitters, but this generates a large amount of files, can reduce creativity, and reduces the benefits of inheritance. Our team landed on a hybrid solution. For example, weapon FX use a very directed Emitter set specific to building weapon FX that allow us to quickly build new guns and an Emitter set for building Skydive Trails that have not only improved our workflow but allowed us to work faster. We also have a set of generic Emitters that are render specific FN_Mesh, FN_Sprite, and FN_Ribbon. These generic Emitters allow you to work much in the way you would in Cascade when you add a new Emitter. As we continue to use Niagara, I’m sure we will find more opportunities to create better parent Emitters.
What went right and what were our wins
Swimming! We introduced an entirely new mobility mechanic in Fortnite and all of the supporting FX for that system were built in Niagara. This is a huge win! With the cadence of Fortnite’s development, playing it safe, especially on a brand new feature and brand new tech, might be the obvious choice, but it wasn’t for us. We dove into this initiative head first and from the get-go decided to use Niagara with no fallback on Cascade. This initially was a challenge since the tool is still being actively worked on, which slowed us down at times. Having to do the swimming in Niagara exposed a gamut of bugs and missing functionality that helped harden the tool and get it closer to leaving Early Access. By using Fortnite as a forcing function, it greatly benefited the tool as well as gave us more options than doing FX in Cascade. For instance, our new water shaders were vastly more powerful since Niagara ups the limits of dynamic parameters from four to 20.
Another win for us was Fortnite’s new vehicle, the Motorboat. Since we were creating all the swimming water visuals in Niagara, we decided to build the boat using Niagara as well. Vehicles are quite complex with lots of variables driving FX with things like speed, health, and boosting, and the boat had to work with our water system on top of that. Niagara was perfectly suited for this. We would take data in and instead of solely relying on game code or Blueprints code to control things like spawning behavior, we were able to do more within the tool. The boat, for instance, had a custom Emitter and modules built that read the angle and speed when the boat was in water and only spawned splashes on the side touching the water. This type of spawning behavior simply isn’t possible with Cascade without the support of Blueprints or code.
Water wasn’t the only thing that shined in Fornite Chapter 2. In the months leading up to the start of Chapter 2’s development, we had started an early roll out of Niagara in Fortnite. One of the first things we tried was porting an existing Skydive Trail from Cascade to Niagara. For Chapter 2, we decided to create our first brand new Skydive Trail solely with Niagara and tried to do some stuff that could only be done with the new particle tool. For context, Skydive Trails in Fortnite functionally are just Cascade systems attached to the player during the beginning drop portion of the game. They are spawned in code and the FX team has no access to Blueprints to do anything that Cascade can’t do out of the box. With Niagara, we came up with our first Skydive trail that was going to react to the players’ inputs but all within the new VFX system. What we came up with was the Spectrum skydive trail. This system is using data and attributes like player speed and angles to change colors, pan textures faster, and drive values in Dynamic Parameters in the Material to reveal more texture in the alpha mask. This was our first simple test and from here on out, we’re using Niagara exclusively on all future Skydive Trails. The new Niagara Skydive trails are already a step up from any that we’ve done in the past.
Another thing that went really well in Chapter 2’s development was having a new system view that loosely resembles the same view in Cascade. One of Cascade’s strengths was a very understandable at-a-glance view of how a particle system is built. There is a common language that all FX artists using Unreal know, which allows the sharing of assets and facilitates working on larger teams easier. Until now, Niagara was missing this at-a-glance view. We’ve also reached Cascade parity across the modules that are provided in the Niagara plug-in, further speeding up onboarding for new comers to Niagara. The new system view has greatly sped up working in Niagara as there is now far less scrolling through the stack view. You simply click on the module you want to focus on instead of endlessly scrolling through an entire Emitter stack. We now have the best of both worlds. This includes Cascade’s rapid development and easier-to-understand workflow coupled with a full attribute/data-driven particle editor with full graph view if needed.
Early experiments and challenges
Early experiments lead to an exciting and completely procedural approach to modeling water interactions. By modeling the intersection between an analytical representation of the character's limbs and the water’s surface, we were able to dynamically choose how many splashes to spawn, at what speed they should travel, and where they should be placed. Unfortunately, this didn’t make it in on time for Chapter 2 but we look forward to seeing where it goes in the future!When we first began to adopt Niagara and we began porting existing assets, we made a bit of a mess with our new Emitters and modules. By experimenting and trying to work this brand new tool into a very complex and active pipeline, we ended up with a lot of work that was unused or needed to be redone. While the exploratory early days were extremely useful in informing how we move forward, we incurred tech debt and had to go back multiple times through to clean house on old Emitters and modules that were no longer needed in the project. What ended up happening was, as new artists rolled onto Niagara, it was unclear which Emitters to use, so we ended up with unsupported Emitters, or people would create new ones when they didn’t need to. This can be a common problem with the Material pipeline as well. When a project is lacking clear organization and proper naming conventions, it’s easier to just create a new Material from scratch with the functionality you want instead of digging through the Content Browser to try and figure out what Master Material to use. Working through this is what lead to having one person on the team act as the Emitter gate keeper. By funneling through Andrew and myself, we were able to make more meaningful Emitter choices and spread the pipeline process to the team as they switched to the tool, which reduced our tech debt moving forward.
What we see in the future for Niagara and Fortnite
Looking into the future, I hope to find more ways to push Niagara beyond what was previously possible with Cascade. Even though our initial procedural tests didn’t ship in Fortnite, they show that with more development time coupled with the fact that hardware is getting faster, fully emergent and dynamic interactions within the world are possible. One thing that we’re always striving for on the Fortnite FX team is having FX feel like they are integrated and touching the world, and not just composited on top.One of the obvious problems with working in a tool that hasn’t been out of Early Access has been the sheer amount of bugs and workflow issues we ran into. But at Epic, this is the only way we can ensure the tools we are building are world class and meaningful additions to Unreal Engine. We have generated a long list of quality-of-life requests and as these get tackled, workflows will be faster, better, and surpass what many have become accustomed to with Cascade.
The power and flexibility of Niagara will mean we are less reliant on engineers to build features and frees us to try things we didn’t even think were possible before. Niagara is the future of FX in Unreal and by using the tool in Fortnite, it ensures it will not only be stable, faster, and flexible, but easier to use with a sped-up workflow for all Unreal developers. Cheers, and I can’t wait to see what amazing things get built in Niagara moving forward.