The Niagara asset wizard for both emitters and systems is the starting point when wanting to create VFX with Niagara. Here is a quick before and after:

There are a few concepts to understand about it, as Niagara is much more technical in nature and allows for additional markup of assets to help teams organize their VFX libraries, namely:

  • Library assets
  • Template/Standard or Parent/Behavior Example assets

Additionally, source filtering was introduced in various menus, including the asset creation wizard. While some of it should be self-explanatory, let me address the weaknesses and problems of the former wizard, and how the new wizard addresses them.

Library assets are considered part of the team’s library for reuse. Simple as that. By default, new assets are not marked as library assets so they need to be explicitly marked as such to appear as such.

In the old wizard, library assets were simply considered “more relevant” and as such, library assets were shown first as a sub-category of the template category.

You were able to access non-library assets, but had to scroll down a bunch. In general, the downside of the wizard was that it was mostly presented as a list, despite categories existing.

Both library and template assets were treated in the same way; nested categories were handling the different permutations of the two categorization factors.

In the rework, we have a much higher degree of separation. Instead of being shown a long list of assets, we can choose what to display. By default, we are only shown library assets; unticking the “Library Only” checkbox will show us non-library assets as well. In this case, library categories are introduced again to the view as to separate between the two.

Behavior Example assets did not exist previously to the rework. Functionally, they behave the same as Templates, but are meant for the user to familiarize himself with different features of Niagara as means of improving the onboarding of Niagara.

In any case: Niagara emitters support inheritance, which means you can inherit from an emitter and make value changes to the structure established by the base emitter. You can also add new modules to the child emitter.

This is where templates (behavior examples too) and parent emitters differentiate. Templates do not support inheritance, while parent or standard emitters do.

When creating a new emitter from a template, you receive a copy of the template. This also means that future changes to the base emitter or template will not propagate to the child emitter. It is self contained. Standard emitters, which every new emitter by default is set to, allows for inheritance and will continue receiving changes from the base emitter.

With the inclusion of behavior examples, we no longer have a binary choice between “template or standard”, so a checkbox wasn’t enough anymore. Instead, the reworked wizard features tab-like UI. These tabs, hence the name, are mutually exclusive.

With an ecosystem that heavily relies on different kinds of assets and advanced categorization options, it is also helpful to be able to filter for different sources of assets. In large projects, you might no longer have a need for default Niagara emitters, or perhaps you are trying to get a look at all the systems contained within plugins. And Jerry’s test emitter in the developers folder surely doesn’t need to be displayed either, right?

The look of the source filtering section was made to be the similar to the content browser type filters. This way it should be intuitively understood that this is a similar system.

The library and source filtering options were also introduced to the script assets’ graph action menus, so it becomes easier to find what you are looking for, and to reduce the noise of information. Additionally, actions display their source right next to their names, adding yet another visual clue to give the user context. Here, we can see us having a “New Niagara script*”, coming from the game’s content folder.

, ,