High speed, emit over distance particle system leaves gaps

I am attempting to understand why a particle system that uses emit over distance and is moving very quickly (2,000+ units per second) leaves gaps in its emission. The video demonstrates the issue at varying speeds.

It does not appear to be the particle limit for the system given that it continues emitting. I have also tried all the collision detection modes on the rigidbody, no change in visuals.

Looks like imprecision. What are your particle settings? Have you tried changing the Particle System Emitter Velocity value?

2 Likes

Good call Karl, emitter velocity in the main module changed from rigidbody to transform fixed the issue, but why?

My issue is solved, though I don’t understand why rigidbody is breaking here. Best guess is the gaps represent the fixedUpdate time steps.

1 Like

Yep. RigidBody uses the velocity from the RigidBody where transform calculates the velocity based on the transforms previous position and current position. So looks like a fixed update issue as you say. If you are using a rigid body to move your system then you should use the RigidBody mode, if you don’t then particles can sometimes fire off in random directions due to the delay in updates.

There is still some kind of bug here I would assert though. That value I am adjusting in the video is a VelocityChange force applied after instantiating the object. From my point of view I am using this correctly by giving the rigidbody a velocity and letting the physics engine move it, I do not set transform.position or rigidbody.position.

When do you give the rigibody the velocity? In FixedUpdate? Feel free to file a bug report if you think its a bug. I suspect its just due to when things are updating.

In the Start() method of the object I use:

AddForce(rigidbody.rotation * Vector3.forward * speed, ForceMode.VelocityChange);

Are you only allowed to use physics functions like AddForce inside FixedUpdate()?

You can use it outside of Fixed update but there may be inaccuracies which would explain your problem. Try doing it in start with a yield to fixedupate.

This would only create a problem in the tiny gap in time between the Start and the next FixedUpdate, not the consistent problems the user is seeing through each subsequent frame and update/fixedUpdate.