Beam Emitter - Use Local Space not being checked

The “Use Local Space” option does not work for beam emitters; the checkbox remains unchecked. Intentional or not, this is a pretty important feature. I’d like to attach a beam emitter to a vehicle, but the beams lag pretty far behind as a result of them being simulated in world space.

Is there an alternative setting I’m missing?

Hey OhiraKyou -

What are your Source and Target settings in the Beam Emitter set as? You should be able to set up a relative location check on a source object (your vehicle) and a random point (you can create a target point in the blueprint to use as a reference) in from of the vehicle. By doing this setup in your blueprint you should have complete control over your beam without absolute position/location lagging.

Thank You

Ketchum

The emitter is parented to the vehicle, with the start and target offset by 75 left and right (user set). The beam itself is what’s lagging behind the vehicle, because it is being simulated in world space (the individual beams would never separate from each other during a turn if that weren’t the case). I’ve tried using the other source/target methods, but that doesn’t change the fact that the beam is being simulated in world space.

Before turn (stationary):

During turn:

Settings:

Hi OhiraKyou -

I’ve been trying to reproduce the behavior you have shown above and have not been successful yet. Would you be able to upload a sample project showing this issue?

I will continue my investigation, but let me know -

Thank You

Ketchum

Here is an example project. Simply look around with your mouse to see the beams separating as they lag behind the camera’s rotation (using the TestGameMode in TestMap).

Have you tried the example project in my last reply yet?

Hey OhiraKyou -

My apologies for the delay getting back in touch with you. Good news though, I beleive that you can easily fix the issue you are having by unchecking the “Lock Target Tangent” and “Lock Source Tangent” in the Target and Source modules respectively.

Thank You

Ketchum

The emitter still lags behind as a whole now. I think I checked the lock settings in an attempt to fix the larger problem of the entire emitter not immediately moving with its parent. Here is an example in which I’ve added spheres where the beam’s source and target should be and rotated the emitter to make it easier to see it moving. Even setting the source and target to follow these spheres doesn’t help. While looking around quickly, you can easily see the emitter failing to keep up.

Hey OhiraKyou -

Thank you for the second project it helped me see exactly what your issue is. I have entered a report (TTP#347838) and I will keep you informed as we work on a solution.

Thank You

Ketchum

can you tell me what the status of TTP#347838 is? I’m facing this same issue: Post Physics Update + Attached Object Jitter - Programming & Scripting - Epic Developer Community Forums Is it slated to be fixed in 4.7?

Hey hyperdr1ve -

We are still working on this particular issue and it does not look like it will be fixed for 4.7. I have updated the bug report with you information and for our reference in tracking this issue internally, UE-3358

Any update on this? I’m having the same issue where I have an “lightning ball” that lags behind the projectile because the particles are in world space when I want them to be in local space with the projectile (the “lightning ball” particle system is a component/child inside of my projectile blueprint).

Hi -

Unfortunately this issue is still backlogged currently. I currently do not have an ETA for the fix.

Ketchum

Has this been fixed in 4.8?

Hi eviltenchi -

This issue is still backlogged, I still do not have a definitive ETA on the fix.

Ketchum

Any updates yet? This pretty much makes beam emitters useless for movable pawns.

Hello -

Unfortunately our engineers have deemed that this issue will not be fixed in the foreseeable future, in part because of the development of Niagara as a replacement for Cascade.

Thank You

Ketchum

Any ETA on Niagara? It seems like that has been pushing off Cascade bug fixes for over a year now.

I’ve been analyzing the issue for going on a year now and finally found a solution in my project. What I finally discovered was that if you have a physics simulating body that contains a particle system anywhere in its hierarchy, that particle system will have a tendency to lag behind the physics simulation.

The ultimate solution for me was to change the tick group of the thing that my particles were attached to so that they are Post_Physics.

Alternately if you are calculating values and setting your emitter position by hand, make sure that the work happens in a tick function that occurs Post_Physics.

I posted a few more details in my lab notebook.

Does this solution still work? Using 4.15, the beam still lags behind my actor even after I change the tick group of the actor (on which the beam is attached) to Post_Physics.

Edit:
Actually, I was able to get rid of the lag by setting the particle system component’s tick group to Post_Physics. Seems like the tick group isn’t inherited from the actor.