>> Hi everyone. My name is Alan Willard.
I am a senior technical artist at Epic Games.
I have been there for a very, very long time.
And today I will talk about an Introduction to Niagara.
Niagara is our next generation simulation tool,
primarily intended to replace Cascade
as the primary authoring tool
for things like particle systems and effects,
only it does a lot more than just particles.
The intent is more of a simulation tool,
if you decide to use simulation
for rendering sprites or ribbons
or mass particles, that is great.
There is a lot more going on under the covers
we will be exposing in the future,
letting you do much more interesting things
than just spawning particles and seeing what they look like.
As a bit of background, I have been using Cascade,
and related tools for a while.
I am very much looking forward to Niagara.
This talk is meant much more as an introductory level talk.
We will not look at the guts of the system;
more, how will you create your first system? What will the
system look like? And what we are doing moving forward.
Just for my own information,
how many of you have actually opened Niagara in some setting?
Ten people, maybe?
This will work well for pretty much everybody else.
The very basics are what we are going to be covering,
and some of this you will be familiar with.
Again, this is going to be a fairly short talk.
I will not be getting too deep into any one part of Niagara.
Let us go ahead and get started.
At SIGGRAPH earlier this year, Wyeth Johnson,
who is one of the lead artists at Epic,
and who is doing primarily the heavy lifting on the art side
of design and implementation for Niagara,
gave a much more in-depth talk. If you are interested,
you can go to the Unreal Engine YouTube channel
and you can find Wyeth's talk in its entirety.
Even if you are never planning
to go beyond the introductory phase of Niagara,
it is still worthwhile information
to have on how Niagara is integrated in the Engine,
where we are going with it, and other information.
Niagara is node based, much more so than Cascade;
meaning, similar to Blueprints or other graph tools,
you can connect chains of logic together to modify
or create your final result. Niagara is programmable --
we can make modules now for our particle systems, as artists.
I do not have to completely rely on our engineering team
to make a module for me I can plug in,
share with other artists and is extensible.
All of these systems are designed to not only work
with Niagara, but also link into other Engine systems.
If you have a data interface, which
is what we call our import mechanic
for bringing in data from an application like Houdini,
or data from within the Engine, something like a Skeletal Mesh,
we will be creating more of data interfaces.
As the Niagara develops, you will have more interaction
with other internal and external tools.
And of course, Niagara is cross-platform and scalable.
Part of the initiative right now is to make sure Niagara
works on every single platform Unreal ships on and
the choices we make from an engineering standpoint
makes sense, given this breadth of implementation.
I am going to go ahead
and actually jump into the Editor for a bit.
This is just a simple Content Browser with Niagara enabled,
I am going to open up a demo map.
The map already has a really simple particle system,
done with Niagara. If I select the particle system and move it,
you can see it is not only doing a simple particle,
there is full physics on that particle.
That is being done completely in Niagara.
There is no physics constraint, there is no Blueprint
being invoked here to add behavior.
What does it look like when you create
an all new Niagara system?
I will right-click, select FX and make a new Niagara emitter.
The first thing you see is, fairly new, I have a dialogue
which lets me select to create an emitter effect
from a set of templates listed here.
I can copy one a template which already exists,
so if I want to just take an effect
someone else has done and duplicate it,
or I can create a completely blank template.
The really cool part of this whole template scheme, though,
is that it is defined by the team.
What that means is during the production of my project,
I might find the directional burst and fountain effects
do not apply; I do not use those at all,
they are not relevant to the project I am trying to make,
whether it is a game or an experience,
or multimedia, whatever.
What our art team can now do is create their own templates.
Say every effect in my game
happens to be spherical in nature at start --
I could have a sphere burst be the
top-line emitter I can choose from.
Then when I choose that emitter template and create it,
Niagara automatically sets up the template behavior
so I can see it.
Now I can begin working with this behavior from this template
which has been pre-defined for me.
I can go way beyond--
I can have an entirely finished effect be a template,
and then move on from the template.
One of the ways this works
is that Niagara itself is extremely modular.
While I have an emitter open now,
this is not the entire particle system.
This is just what, in Cascade, would be referred
to as a sub-emitter.
In Niagara, I can see all of the emitter behavior simultaneously,
and I can modify the behavior.
Actually, this object actually exists in the Content Browser.
In Cascade, if I wanted to share an emitter
between two systems --
Well, one, it was not very easy to do --
they all existed inside the particle systems,
they were not a hierarchical category of pieces.
What we have here inside of this emitter
is the stack which makes an emitter possible.
I am going to compress this down a bit.
Everything is color-coded
based on what part of the system it applies to.
We have the base emitter behavior,
and this is what controls the core emitter --
how long does this emitter last?
Is it a GPU or a CPU emitter, properties like that.
Then we have the Particle Spawn --
the Particle Spawn happens
when the particle is actually created.
All of the modules defining these behaviors understand
which part of the stack they are in.
So for example, with Particle Spawn,
in Cascade, if I set the particle velocity,
that would be considered initial velocity.
This velocity would not be updated. At particle spawn,
this is the velocity I want this payload to have.
So, far Add Velocity,
because this is happening at Particle Spawn,
all this is really doing is, the initial velocity
this burst has is slightly more weighted
towards going negative X than positive X,
but velocity is not updating each frame
I am not changing the velocity after spawn,
We do this in the particle update portion of the stack.
If I open up particle update,
this is where properties like forces come to play;
stuff like gravity or wind, or curl noise,
or even things like just standard acceleration,
where I give it a vector and the particle tries to follow along.
All of these values, I can type in manually.
This is a really high drag force,
it tends to slow the system down,
but gravity is still affecting the system, or I can reduce the
force and make it look closer to the default.
I can also change gravity,
and now my particles have a lot more upward velocity,
because they are not being dragged down.
In Cascade, gravity would be called acceleration.
In a lot of ways, there is a good reason for that.
Acceleration is just the tendency for a particle
to move in some direction,
whereas gravity, especially in games,
is just a downward force.
The reason we separated acceleration and gravity
is because we are spending a lot of time identifying things
that will make particle systems look more realistic.
Things like using gravity and physical forces,
instead of just arbitrary values we expect the user
to eventually understand the properties range and limits.
Instead, we are trying to define more
physical constants; mass, density, gravity,
which can be applied to any particle system,
and the systems will all look physically similar,
at least in response.
I am going to open up a Niagara system.
In this case, the system looks exactly the same as the emitter.
It is only bringing in the emitter
which creates this particle system.
You will notice this orb starts off spinning slowly,
and then increases in velocity and rotation speed as it moves.
A lot of this is because the orb has mass.
In Set Variables, we have this concept of name space.
A name space is, does this affect the particle itself?
Does this affect the system?
Does this come in as part of a module?
In this particle's name space, I have Mass.
I can look at particles, here is Mass.
It is a core component of the particle system.
The way mass and force is being handled,
if I decrease the particle's mass
because we are using a constant density calculation;
this not only increases the amount of force
applied on the particle --
which you can see every time the simulation restarts --
but changing the mass, changes the size of the particle.
Mass and density are tied together.
We are using a constant density calculation to say,
"this thing is made of steel, with a density of X."
As I make the orb larger, its mass increases.
As I make the orb smaller, its mass decreases.
The mass affects how much force is allowed to be applied.
If I make something really big and hard to move,
I will need to use a lot more force to get it to respond.
Inversely, if I decrease the mass,
the orb begins to move much more rapidly.
This is part of our initiative
to unify forces and behaviors inside of Niagara,
as well as forces and behaviors from your game,
the gravity affecting your player,
is the gravity affecting your particles,
and everything will be tied together.
There is a lot less guess work going into,
creating a particle and then hope it falls appropriately
All of these forces can be tied together,
just like our little pendulum; when as I move it,
the force is applied, trying to get it to swing back down.
We can do something a little more dramatic --
give me a second to switch levels here --
I am going to open up Pendulum Ball.
This Pendulum Ball was written by Wyeth,
the gentleman I pointed out at the beginning.
What this does is
it illuminates the pins on this orb,
based on the amount of force is applied to them,
which there is also a small amount of curl noise
passing through the system,
and this is why you see an occasional ripple.
The awesome part is, this is all being done in real-time.
If I just drag this system into the Editor,
you can see all of the behaviour happening in real-time.
All of this is because inside of this stack,
we have a module that Wyeth wrote called
Fibonacci Sphere Location, which handles the placement
for all of those pins. I can modify the sphere radius,
and because all of these modules can work together,
as I change radius, it will change the forces applied.
The Fibonacci Sphere Location Module itself looks like this.
I am literally coding, just like you would in
Blueprint. I am taking what the particle is doing,
the data we can interact with,
and I can do math operations very simply.
Again, it is context-centered,
it looks just like working with Blueprints.
What I am actually doing is, I am writing a script,
and then I can expose variables in a name space --
You can see here, they are "Module.VariableName".
These variables then will show up in
this module as user-editable inputs.
I can write something both very multi-functional,
I can write it to not care what particle gets the module,
the module just does its thing and moves on,
or I can write something a little more complex
and single-purpose.
All of these can be exposed to the users.
These modules that I am writing
do not live inside of this particle system;
they live inside of the Content Browser,
just like everything else.
I have my Mass example, I have input scripts,
I have Functions and Modules -- they look just like this,
but I can just drag them into my Niagara Emitter,
and they will immediately begin working.
Again, all of this is still in early access.
Which means is, we are constantly evaluating
whether we made the right decisions,
from a user interface point of view, from a code side,
from the expected flow for artists
and other designers to use it. We are making changes.
While you can access Niagara, and you are more than welcome
to play around with it, we would caution some restraint
when planning to use this for a shipped project,
until we have announced we are releasing it
as a full aspect of Unreal Engine 4.
Before you ask -- I do not know for sure when that date is.
Our big pushes right now are for
compatibility across all platforms,
making sure all of our choices in terms of scalability,
rendering, and general features are all accessible.
I have a couple of other demonstrations in here as well.
Random Spring -- so if you wanted to literally
just have little floating arrows --
I do not know why you would --
but it does mean this same code running in here
can be used to do floating candles and Hogwarts,
or coalescing particle effect before an attack
in something like a first person shooter or a fighting game.
So all of these modules are way more utilitarian than they look
when you first use them,
because again, they can be shared
between different particle systems.
We have data interfaces allowing us to bring data
and drag it from one portion of Engine to another;
so if I wanted these pendulum pins to be on a Skeletal Mesh,
we can do that as well.
Moving forward, we plan to expose a lot more data
interfaces across different portions of the Engine;
data like Static Mesh, Skeletal Mesh, Materials,
things like that, as well as additional hooks for Blueprints
so you can interact with material
and mesh properties directly,
and not be limited to what can be done
inside of the particle system as it is originally created.
As I said, this is not going to be
a particularly long demonstration.
The idea is more to give you an introduction
to how the Engine works with Niagara.
There is one last thing I want to show, in Niagara itself.
In the emitter stack, you are restricted to emitter,
and what the particle does in Emitter Spawn and Update.
At the Particle System level,
you can write much more exposed parameters
affecting the entire particle system, and its sub-emitters.
This is where we store data for Sequencer as well.
One of the wonderful parts of Niagara
is a Sequencer integration
allowing you to both see your effects on a timeline,
but also control those effects through scheduling.
Things like, I want X-number of particles
to spawn at this point in time, and then I want this
other sub-emitter to turn on and off --
things you would normally spend hours in Cascade working on,
jumping between sub-emitter setting delay offsets,
and other finer timings.
You can now visualize all this directly inside of Niagara.
If you have 30 sub-emitters making up one final emitter,
you can easily look at the timeline
and see when everything is happening,
add new events and other controls and then preview it.
There is a lot of very, very cool, very powerful tools
which are a part of Niagara, in addition to just Niagara itself.
Thank you very much. I hope it was informative.
I hope everybody enjoys playing with Niagara,
moving forward in the future.