I highly doubt that it is “for performance reasons”.
More likely is that the vertices are simply being addressed by their indices in the triangle list.
So if different triangles reuse the same vertices, multiple particles end up at those vertices.
At least that would be my guess.
1 Like
Thanks Niels,
Does reusing the same vertices not happen to all the triangles of a mesh? If a polygon mesh consist of multiple triangulated polygons that have three vertices shared by other triangulated polygons, should it happen to all the triangles of a mesh?
For some reason, it seems to be only happening to a curved mesh.
Hi! I was wondering if there is a way for Niagara sprite render, to lock an specific axis for the camera facing. I think this could be easily done in Cascade but is there a way to do this in Niagara?
Thanks in advance 
You can set a custom facing vector to build custom facing behavior of sprites.
Although, if I remember correctly, to get the same thing as cascade, you keep the facing vector the same, and set the orientation vector to the axis you want to lock.
How would I go about reading color information from a material in Niagara?
I want to spawn particles from the edges of a dissolving mesh.
I got it to work by reading the material color using UV and mesh sampling. In my material, I am dissolving a texture and then masking it out using particle color before adding the edge color on top. This way I can let only the particle spawned from the edge be seen when I set the particle color to (0, 0, 0, 0).
But doing it this way I can’t customize the particles outside of their color base on the edge color.
I attempted to emit particles from these particles but the invisible particles would still emit particles, and I’ve had a hard time trying to kill them off.
Any advice? Maybe there are some other ways of achieving this?
Hi all,
have pretty weird stuff happening with DynamicParameter curve. I’m trying to control panner speed from particle emitter through Dynamic Parameter.
fsr, can’t attach screenshot here, but I’m just multiplying dynamic parameter1 to appended vector, which then goes to Panner Speed.
Problem is, when I use float or float range, it works fine. But it when I’m trying to use curve it goes crazy speed, like more than 10 at least.
Also, it works fine with single key curve and if keys have value difference no more than 0.01 (it’s probably just ignoring it).
That’s not a niagara issue, but rather a limitation of how the panner node works in the material.
What the panner is doing is multiplying the time by your input and adding that to the UVs, so as time goes on your UVs are being displaced. So with a speed of 0.1 for example, at t=1s your UVs are going to be (0.1,0.1), at t=5s they are going to be (0.5,0.5), and at t=10s (1,1)…
The thing is, since the material is not storing any current offset, it doesn’t respond correctly to changing values in real time. If you change that panner value in the middle of the game, let’s say at t=10s you change that value from 0.1 speed to 0.2 speed… the UVs will suddenly go from (1,1) to (2,2), since 10s*0.2speed = 2. It’s not going to start going faster, it’s going to calculate the result as if it had been going that fast from the beginning.
If you want something like a panner node that you can change in real time what you can do is have a material parameter whose value is added to the UVs, like an offset. You can then have a niagara parameter that starts at 0 (or any value really) and that is increased by a set amount (let’s say X) every frame, you can do this in the particle update stage in your niagara emitter.
Instead of setting up the desired curve in the dynamic parameter like you’re doing right now, you would just send this niagara parameter there, and instead have the curve wherever you are adding that X value to your niagara parameter, so the amount added to this offset parameter changes along the particle’s lifetime.
At least that’s the solution I’ve always used, if there’s an easier way I’d like to know…
EDIT: I just came across this video by chance, which showcases all this very nicely:
1 Like
Nothing much to add here except that you can sample time from Niagara as well, so even with the setup described by Filo, you can still switch back to a look which just uses time.
1 Like
Hey you all! have any of you had any problems with niagara system not being the same in PIE and in packaged build?
no error, nothing!
My only clue is that I am using a Grid3D
if I set the num attributes to 0 I get these warnings, it works on PIE, but not on standalone and not on package
If i set it to 1, it works on PIE and standalone, but still not package, but I also receive this warning>
LogNiagara: Warning: GridEmitter.Grid3D: Unnamed attributes should not be used with named. This is a deprecated workflow
I think you always want at least 1 attribute on your grid. Did you take a look at hte Grid3D examples? They initialise the attributes on EmitterSpawn, right after creating the grids.
Also, are you on latest UE version?
but I AM using attributes, at least 4 named attributes 
I fixed the package bug, I was copying my array to another parameter to easily access it from user.MyArray to system or emitter namespace using set parameter in update and it simply was not updating, using the user parameter directly worked (in 5.3)
but the warnings remains
hello, I’m working on a world scale simulation and using LWC in UE 5.3.
From what I gather since 5.1 the LWC makes it so that the system does a cache reset every few LWC tiles… and it kills all particles then restart the simulation (weather fx) … the system is local and follow us (it is a children therefore it’s location is always 0.0.0) is there anyone who knows how to bypass for good (without leading to future additional problems) the LWC cache reset if the system is local and at a 0.0.0 position ?
thanks so much to whoever can share their precious time and knowledge !!
I there a way to use multiple materials and select them at run time? I do not want to use any Blue print methods.
Hey folks ! Can anyone let me know if it’s feasible to “per instance” edit materials used by a mesh particle system. As in, edit material parameters that would only affect specific particles. (This is on UE4.26)
This sounds like we can’t since we’d have a copy of the material per particle which would likely blow up, but thought I’d shoot this thought on here. Cheers
Need more than 16 floats?
