Together with the addition of behavior examples mentioned in this post, to help new users how Niagara functions and how to make use of it, some kind of comment functionality was required. While script assets can contain a message that is easily accessible from within the editor, that system has no awareness of any module’s usage context. That usage context typically being an emitter, as an emitter is a host for modules.

Introducing: the note feature.

As of Unreal Engine 4.27, notes can be added to any module within an emitter by right clicking the module item in either the overview graph or within the stack and choosing the “Add Note” option. Since they exist on an emitter level, it becomes possible to better describe any module within the context of its actual usage. In this case, the Initialize Particle module has a note describing how a mesh array is used.

Future upgrades and analysis of obstacles

While it is not currently possible to attach notes to any item other than modules, internally I wrote an incomplete upgrade to allow for (almost) any stack row to contain notes. This is more difficult than one would suspect, as the modules themselves are serialized, but function input rows for example are not. Every stack row has a semi-formal ID that allows for additional serialized data storage. Across editor sessions, any row, while transient in nature, will regenerate its previous ID so that we can maintain some level of consistency. The problem arises in the surrounding functionality, like copy & paste. Pasting a copied module with some custom notes implies a functional copy & paste of its contained notes as well.

Since the note data isn’t stored in the UObject that is copied, we have to manually transfer and update the note data. The pasted object will have another ID than the copied object however, so we can’t do a full copy of the note data but have to change some of it. Potential approaches are:

  • Analyze the stack entry guid pattern of the copied module and create the new guids from the old guids. This is the most desirable option as it would be fail-safe. It does require a guid pattern to exist though. The “semi-formal” ID generation causes problems here. While the ID generation for the same object is consistent, it is not consistent for the different types of objects, so we can’t assume just one way of creating them. The solution is to formalize the ID generation completely, so we can be sure of the new ID to be correct.
  • Analyze the stack hierarchy and infer the mapping from old to new guids via that hierarchy. This doesn’t quite work because some of the stack elements can be dynamic entries that are spawned for user convenience, or are temporary. Examples include compile error messages or the note entry itself! We would need a way to retrieve only the persistent, module defining stack entries so we can ensure a fixed hierarchy.