4.20p1 - Niagra Questions/Issues

So I’ve been playing around with Niagra this morning but since there is very little info out there I have a few questions, and a couple issues (that may not be issues at all, most likely I’m doing something wrong).

Issue #1
First off I’m having trouble getting the “Collision Bounce” module to function. When I add it in I get the following error:

Niagra01.JPG
The only changes I have made are setting the emitter to a GPU sim (but this error comes up for CPUsim too, no difference), and also increased the spawn rate to 400.
The module’s tooltip says it should be placed after the “Solve Forces and Velocity” module, however moving it up/down the stack doesn’t make any difference. I also tried the old cascade trick of setting the bounds from the main toolbar but this didn’t change anything either. To make sure I didn’t mess something up I just created a new emitter and added the Collision Bounce module as before, same error comes up with no changes made. Viewing the graph says there is an error in the top left corner, but none of the nodes in the graph have an error message.

Issue #2
Is the Emitter Graph not supposed to be edited? I’m almost certain I saw it being edited in the GDC presentation, however anything I try to do causes an immediate crash. As an example I was trying to move the Collision Bounce node before the Solve Forces and Velocity node, but trying to disconnect a wire, or add a wire, will cause a crash.

Issue #3

I created an emitter and modified a few values, compiled/saved and closed the window. Then I created a new system but when I added the emitter it reset all of the values back to defaults on the emitter. Is this intended behavior? When working with Niagra should you create an emitter and immediately add it to a system instead of modifying it first?

Issue #4
The toolbar in Emitter and System don’t work properly with small toolbar icons, the Compile button is missing on both Emitter and System.

Emitter normal and small toolbar buttons:
Niagra02_Emitter.JPG
Niagra03_Emitter.JPG

System normal and small toolbar buttons:
Niagra02_System.JPG
Niagra03_System.JPG
EDIT: I have submitted a bug report for the toolbar button issues, for tracking it is:
4.20p1 Niagra System & Emitter Small Toolbar Button Missing UE-60115

Finally a quick question; There are 2 plugins for Niagra (not including the Houdini plugin), should they both be enabled or is just the Niagra plugin enough to create particle fx?

If these do turn out to be actual bugs, or not intended behavior, let me know and I will create a proper bug report for them.

If anyone else has questions or issues feel free to post them in this thread, would be a good idea to keep them all in one place.

Thanks

First off, thanks for giving Niagara a try. There are a lot of rough edges, but we’re committed to improving them before we get out of Early Access.
We’re working on both doc and example content for Niagara to help get people started. It is still in active development, but should be available by the time that 4.20 is out of previews.

Issue#1. The collision bounce module needs to be removed. It has been replaced by Collision Linear Impulse. In particle update the order should be:
Solve Forces and Velocity
Collision Query
Collision Linear Impulse

Issue #2
The emitter and system graphs are there for debug purposes. We will probably hide them behind a CVAR in subsequent releases. Everything should be done through the stack or within modules.

Issue #3
This one I’m a little unclear on and there might be a bug here. When you include an emitter into a Niagara System, it should keep the values that were last set on that emitter. This sets up a relationship between the system’s version and the original standalone version. From now on, any edits you make to the standalone version will get merged with any edits you make to the system version. The idea behind this was to allow you to create a small(ish) set of base emitters that can be combined together to make the full system. Then later on, you can add/remove/refactor modules on the base version and they will merge with the system instances you created. If this doesn’t match what you are experiencing, please let us know and we can investigate further.

Issue #4:
We didn’t test with small icons and will take a look.

Extra:
The Niagara plugin is the primary plugin. We have worked with SideFX to make a simple Unreal plugin that allowed us to do the Houdini part of our GDC demo. The Extras are just fun additional modules that we built during development that aren’t part of the official suite, but you can use them for examples or to just play around.

I also wanted to add this note.

We’ve seen some reports of Niagara crashing when you create an emitter in some projects with binary versions of the editor. This is due to an unresolved bug where the project isn’t getting the proper config options copied over. If your Niagara Editor project settings look like the attached image, you likely have this.

The fix is to go into the Project Settings for Niagara Editor and import the attached config file, Niagara-Editor-Backup-20180606-203035.txt. You’ll need to rename the file from .txt to .ini.

#1

The is that in the collision bounce module the preform query node that is being used is an old node.
Simply add a new query node and wire it and delete the old one.

Hey Shaun!

I tested out the Collision Linear Impulse and it works perfectly, thanks for clearing that up.

Huh, I must have imagined it then, oh well using the modules works just fine so I can’t really complain. :smiley:

It would be a pretty cool if you could copy/paste into the graph like you can with blueprints to transfer between projects, or send the setup to a friend though.

That’s what I thought, and using it this way is going to be so much easier. Probably my favorite of Niagra (so far at least).

I don’t know why it reset on me yesterday but so far today I have not had the again. If it does happen again though I will submit a bug report.

No worries Shaun! I like the small ones since they let you squeeze a few more pixels into the viewport, but I can live with the large buttons for now. I received an email back regarding the bug report, here’s a link to it on Tracker: UE-60115

Interesting, can you explain a bit more about the Houdini plugin? Does it enable you to use new content types?

Thanks again for taking the time to answer, really appreciate it! I’m sure that I’ll have some more questions for you guys very soon.

ps. You’re missing your Epic Staff badge on your account, I’ll bug the community team to get it added. :wink:

It’s not possible to make changes to the graph, see Shaun’s reply above.

Hey there, hope it’s okay for me to post on this thread. I am using the 4.20 preview with Niagara enabled but not the extras.

I am trying to use this volume material to generate a fog particles


I see it emitting sprites but they are invisible

Do I have to change a setting in the render to make it render volume materials?

The Houdini plugin lets you use Houdini’s capability to export a simulation to a CSV file and replay that within Niagara. You can use it to do really fun stuff.

Is there support for custom Render Modules? For instance if we wanted to add an array of static meshes for the particle system to choose randomly?

Some questions too…

  • What is the specification for the Houdini CSV, so we can use it to write our own CSV files from other sources, without having to create a custom c++ input parameter data interface?

  • How do we set parameters in custom modules to be animatable with the Niagara timeline-sequencer ?

  • i’m surprised there is no Texture input parameter data interface?

  • There is a vector field data interface … how do we add this asset ?

  • It seems there is a limit of one million particles using cpusim ?

  • Will we be able to delete the basic modules we don’t use in an emitter?

  • Will there be array/map/set datatypes?

  • Can we get values from an emitter in another emitter using the namespacing and expressions ?

  • How to get dynamic input scripts to work ? i get an error it can’t find the input map. They also don’t show up in the list, but i guess that’s because it doesn’t compile.

Figured out the csv by looking at an example and this post :

You can just make up your data by putting any of the property titles in first row, and then that data for each point in a next row.

For example

P, color
“(0.0, 0.0, 0.0)”, “(0.0, 0.0, 0.0)”
“(100.0, 0.0, 0.0)”, “(0.0, 0.0, 0.0)”

Which translates to 2 rows / points and 6 columns, Px,Py,Pz,R,G,B

Support for adding module inputs to the timeline in the emitter and system editor is pretty limited right now. If you’d like to try adding support for your own custom modules you can do so through metadata in the module editor. For a module that should be shown as a time range the EmitterLifeCycle module is a good example and for a module that should show up as a single key with a value, the SpawnBurstInstantaneous is a good example. The basic process is to add the “NiagaraTimelineSecitonClass” and “TimelineMode” key/value pairs in the script meta data, and then you mark up individual inputs in the input meta data.

There is also support for controlling niagara systems through the level sequencer where you can control the life cycle and can animate exposed user parameters of certain types.

This will be coming in a future release, but it may be available sooner directly through the dev-niagara stream.

There are still issues with this functionality and is currently unsupported for the 4.20 release, it will be fixed in a future update.

We put in some limits to prevent users from immediately crashing when putting in large numbers. We’ll be looking into other solutions going forward, like making the system more robust, and making limits optional and configurable.

You should be able to delete all of the modules when you’re in the emitter editor, although there is currently a bug which prevents the script from compiling if you don’t set “DataInstance.IsAlive” somewhere, but this will be fixed. In the short term you can either add you own module to set that value, or you can set it directly in the particle stack.

Once you add an emitter to a system all of it’s modules become “locked” and can’t be deleted. We do this to facilitate the emitter inheritance where changes to the emitter are automatically propagated into the system. We will probably have an option in the future which would allow you to “unlock” the emitter at the system level and then you could make any changes you want and it would not get changes from the source emitter anymore.

This is something we have talked about, but aren’t any short term plans to implement this.

The primary mechanism for passing information between emitters is to use events. We will also have the ability to directly read information from another emitters particles in a future release.

Dynamic input scripts take a parameter map input and provide a single typed output. They should show up in the emitter/system editor regardless of whether they compile, but they’ll only show up in compatible sections of the stack which is determined by how you’ve setup your “Module Usage Bitmask” in the script editor.

Thanks for the thorough answers !

Great answers and knowledge above! Just wanted to add one more question, is motion blur currently supported with Niagara particles and if so how can it be enabled? (Tried looking for checkboxes everywhere but couldn’t find anything.)

Definitely an essential effect to properly convey direction and speed on fast moving debris mesh particles, sparks etc. Thanks!

Niagara is absolutely phenomenal so far, can’t wait to get deeper into it!

EDIT: Found the. When comparing the Niagara content examples project and a default new project, I found that “Accurate velocities from Vertex Deformation” under Project Settings -> Rendering needs to be ticked in order to see motion blur with Niagara!

Cannot add niagara to the animation
2.
No thumbnails in the content browser
3.
in sequence cant update use.XXX
4.
Cannot be copied to other systems in the system
5.。。。。。。

niagara can’t set user value default

Hello fellow Niagara users! (particularly, perhaps. @FrederickD )Bit of an urgent request if I may.

I’ve got some particle systems that have been sent to me from C4D as alembic caches - they look good but performance is shaky. I’d like them to give me a CSV of their system and fudge a Houdini particles implementation. I’ve got a few questions: Does the CSV contain animation data - for example do you have Px,Py,Pz and also a time index? Does anyone have an animated CSV they can send me for experimentation? The ones in the engine are baked into uassets.

Thanks massively for any help here!

Dan