I have a question in regard to spawning (very) fast-moving projectiles and the Niagara particle effect. The problem I’m having is that:
The effect starts not at the projectile spawn location, but further down the projectile path.
The effect is not rendered at some distance before the collision.
In the first case, my assumption is that since the render thread is behind one or two frames, the projectile location is changed already when it’s rendered. However, I’m using the ProjectileMovementComponent with bUpdateOnlyIfRendered set to true.
In the second case, basically, the same assumption - the collision is registered and the particle system is deactivated before it is moved to the collision point. I think I know how to fix this one, however.
Here’s a demonstration of what I described above - it seems like the projectile is spawned too far away from the barrel. However, if you slow down the velocity, the spawn location is exactly where the socket is.
The projectile is a simple blueprint actor with a Box collision as a root component, Niagara system as a child of that Box, and a ProjectileMovementComponent.
I checked the Niagara system and it has no delays I could find. I tried “spawn per unit” to no avail. If I set the global time dilation below zero (say, 0.4), even fast projectiles start rendering particles closer to the barrel.
I had a similar issue and I fixed it by ticking this setting on the Niagara Component inside the Blueprint, here:
If you go into the blueprint where your Niagara component is attached/parented, go to the details panel of the Niagara component, and search for tick. Next to the ‘Niagara Tick Behaviour’ you’ll see the default setting which is ‘Use Prereqs’ I tried ‘force tick last’ but that didn’t work, so ticked ‘force tick first’ that did the trick for me, now my trails are spawning from the exact spawn point of my blueprint instead of what you are seeing also with your system.
I should also add, I have no idea what affect this has on performance/cost of the Niagara system, but it didn’t break show any visible issues.
After some experimentation, setting the Niagara Tick Behaviour to force tick first plus changing the Niagara system rendering parameters (decreasing distance between particles spawned and adding initial instantaneous burst) fixed the problem.
I’m glad you hear you got a solution , just as a side note, something else that anyone could potentially look at could be this too, there is a tutorial from Andreas Glad who talks about a custom Niagara script that can help in this case too
None of the things here will solve this problem, at least not for my specific case. There has to be some way that the projectile movement speed is affecting the particle system and its velocity. There is little to no information out there in internet land that demystifies Niagara systems, even though it’s been out for quite some time.
If you have a Niagara system that depends on velocity, and you attach it to a projectile, it won’t work right. I know there is a simple solution, and I’m sure it has to do with managing the two different velocities, but my own tests have solved nothing.
I tried multiplying and dividing by owner velocity, using the owning velocity instead, delaying projectile speed, and a few other things to no avail. I’m surprised there is so little on this problem and even the subject. I thought the majority of people used Niagara for projectiles.
I have learned that the systems don’t even start until the projectile that they are a part of has been alive in the game world for at least 1 second or so. I also learned that opposing velocity for trail effects is very difficult to get right (at least on mesh systems).
Thank you for the suggestion!
, just as a side note, something else that anyone could potentially look at could be this too, there is a tutorial from Andreas Glad who talks about a custom Niagara script that can help in this case too
