I have an actor whose tick group is set to post physics:
SetTickGroup(ETickingGroup::TG_PostPhysics);
He is set to this because his location is matched to a physics object in-game to allow decoupling his physical location from his rotation. If I use the normal tick group, you see jitter when matching his body to his physics asset (even with sub-stepping on).
Now the issue I have is that I have other items such as particles in my blueprint. For instance my engine particle that is parented to a bone like so.
If I use the default tick group, when I move my character, the particle systems look how you’d expect, but there is movement jitter caused by matching the visual actor to the physics object:
If I use the post physics tick group, my movement jitters go away to be replaced by a very obvious positional lag on my attached particles:
How can I remove this particle jitter/lag while still using the post physics tick group? My only option so far seems to be manually setting translation of the items, this defeats the entire purpose of attaching things to parents but may have to be my final solution.
I’ve tried manually updating the location of the the particle system every tick but the behavior is identical:
Thrusters->SetWorldTransform(comp->GetSocketTransform(“ThrusterSocket”));
Additionally, if I set a particle to be local space, it fixes the particle lag… but I didn’t want local space particles to begin with and beam particles don’t have the option of being local space.
As you’ve noticed this is a known issue that was referenced with UE-3358. Our developers are aware of the issue and will address this in a future release. I’ll add your information to the report for reference as well.
This function returns a vector that will be the place for the source at “the next frame”, which in fact counter the “lag” and make it look like it’s at its place.
For the target, to keep it aligned (if needed to be aligned):
In fact, the trick is “just” to calculate the next position of the beam source and target (calculating in fact the next position of the actor and applying the offset between the position of the beam source/target to it) using it’s current velocities (linear and angular)
Note: This is still work in progress… It’s not correcting the angular offset that is “created” by rotation the actor. but it fully counters the linear movement lag.
If the lag persists, try to change the var in the function (which is 1.045 in my case)
This ticket is heavily backlogged as a minor priority and likely will go unresolved. Before anyone gets upset by this, it needs to be mentioned that this is not the case with all Cascade bugs. Right now, only crash and regression bugs are being addressed for Cascade. This is because Epic is moving forward with Niagara/Cascade 2.0. This is intended to be the replacement for Cascade and will eventually replace it all together. Using Erio’s method below is probably the best solution for the time being.
That is unfortunate, as this could be a blocker if Niagara is not in a usable state by the end of my project (Q2 '16) and it most likely means any existing particles need to be reworked (e.g. anything from the marketplace).
