System Information:
AMD Ryzen 7 2700X
32 GB Memory
NVIDIA GeForce RTX 2070 SUPER
ParticleEmitter’s emitted particles appear to jump forward in time the moment they spawn in. This causes issues for particles which are not locked to part. Generally this affects particle effects like smoke and fire on moving assemblies. This causes effects to look absolutely atricious ingame:
I’ve tried numerous techniques to fix this myself but nothing works.
This bug is really easy to replicate, I’ve included an example file, all you have to do is click play and see for yourself the problem. Particle Emitter Problem Example.rbxl (63.5 KB)
The example part is moving at constant velocity, in a single direction, the particles have no drag and simply emit upward, with VelocityInheritance set to 1. If the particles truly did spawn with the same lateral velocity as the part, they would move in a straight line above the part, but that is clearly not the case:
It would be really great if this could be fixed as it is a giant headache I’ve encountered countless times and it never gets less frustrating to look at.
Thanks.
Expected behavior
What I expect to happen in the example place file is for the particles to draw a perfectly straight line above the part, moving with the part, as if there particles really are moving at exactly the same speed as that part that is what should happen.
I don’t have studio right now but did you check if it isn’t a client - server issue? Like you particles spawning on client but the item being on server ?
That missile video you see has fully clientsided missiles and smoke emission. I know this because all the replication is custom. I am positive the issue is not related to that.
To be sure I’ve revised the example place file for you so that the part’s network owner is the player’s. Just click play in the place and see for yourself. Particle Emitter Problem Example.rbxl (54.4 KB)
The emission position is both jittery and ahead of where the part is.
Can you give me your place file from when you tested it to see if this is maybe a specific platform issue?
It’s ahead of where you think it’s supposed to be because you have velocity inheritance enabled. It’s similar to how you can set your particle speed and drag to a high value, it seemingly starts emitting from a location far away from the part.
Now, I understand why this can be considered a bug (which it may be, I’m not too sure). I don’t know at what point particles are rendered during rendering, so this may just be intended behavior. Again, I do agree that this is kind of odd; just dropping my two cents here.
In a dragless world, if you’re a physics object, moving laterally at constant velocity, and you shoot another physics object with vertical velocity upward from your frame of reference, that physics object should maintain identical lateral velocity to you, and such stay perfectly laterally aligned with you.
That is not what is seen with particle emitters currently. Something weird is happening where as the particle emits, physics also seems to step forward in time once for only that emitted particle. Particles should only step forward in time every time physics does for accurate results.
The particle speed and drag phenomena is entirely seperate to this, as in that case, it appears particles have a large disconnect between the emitter and the particle clump due to low sampling rates, ie how an object can cover large distances easily between frames.
I have had this issue before and it is really annoying. It seems to be very persistent. I have tried to create a workaround with no success. It is as if velocity is tied to framerate?
If i threw an object from a moving vehicle to the perpendicular direction (90 degrees from the car moving direction) the object should move from the car position backwards. Its a bug that i also experience.
Ditto on this bug, I ran into this while setting up engine exhausts.
The particles should theoretically trail smoothly behind the aircraft, but instead randomly jump ahead of it. The effect predictably gets worse as the assembly moves faster.
Issue still persists. Further testing shows that particles updating according to render times instead of physics times. This is inherently bad for particles that exist in the same space as physics objects and are emitted by physics objects. Changing this will not drastically affect existing games. Physics time is proportional to real-time until physics throttling. In exchange we would get particles that don’t look terrible when you try to use them for their intended purpose.
Thank you for bringing this issue to your attention.
It appears part of the problem is fixed.
Instead of spawning in ahead of the part, each particle now spawns right at the emitter which is a sure improvement.
However, the particles still seem to jump around from the physics part’s frame of reference, which shouldn’t be happening ideally.
To ensure we are on the same page, I will re-link the example place I am using and attach a video as well.
The part’s network owner is the client and the part’s displacement over time is linear so this is most likely not related to the part itself jumping around.
Ideally, the particles will form a perfectly straight line above the part if both the particles and the part were to have 0 acceleration.
How are you updating the CFrame of this part?
I looked at the placefile you provided and wasn’t able to see a script containing the update CFrame logic for the part.
The particles had been changed to spawn from their parent’s CFrame, so I do think this is in fact the issue
I am not updating the CFrame of the part through a script. The place has gravity set to 0, and I’ve set the part’s velocity to move sideways at some rate, so physics is updating the part position. The script is only to set the parts network owner to the client.
I’ve opened the place file again and realized I haven’t set physics stepping method to fixed so that is contributing a bit to the part jumping around.
It’s not perfect, I can still see the particles jumping relative to the part every now and again, but it’s far improved from what it used to be. I’m happy to mark it as solved at this point.
