Particles persist forever if you aren't looking at them

Reproduction Steps

Emitting a particle manually, with emit(), the particles will behave in an unusual manner;
If you are looking away from them when they are emitted, they will persist far, far past their lifetime.

To reproduce, simply be looking away from a particle source when it is manually emitted.
Particles will build up, and when you look back in their direction, all of them will be displayed at once.



Expected Behavior

When particles are emitted, whether I am actively rendering them or not, they should disappear after the correct amount of time.
If a particle is set to last X time, whether I am actively looking at it should not factor in it’s fading.

Actual Behavior

When you look back at a particle source that you were previously looking away from, all of the particles that WOULD have been visible through :emit() suddenly appear & then go through their natural particle lifetime.

This happens excessively - You can have particles that should have emitted & gone through their lifespan over a minute ago, seemingly appearing out of nowhere.

Provided are 2 clips showcasing a Plane which is simply :emit()'ing contrail over time. The particles are set to manually emit due to them being necessary to see & too far away to be rendered through automatic particles.

Video 1 - Normal Behavior. Particles for plane exhaust art short, and fade over time. Particles spawned while looking at them.
Video 2 - Broken Behavior. In the video I am looking up for 30+ seconds. When I look down, a massive particle trail forms - These particles all should have been gone by now, but they only start their lifespan after I look at them.


This is an EXTREMELY disruptive bug, as it destroys any accurate usage of particles. If every manually emitted particle behaves in this manner, then you will see huge pop-in from particles.

I’m surprised this doesn’t seem to be a widely known bug, but I suppose most particles are left on auto-rate.
I always wanted to use particles for things like Bullets and such, but if there’s a chance this will happen to bullets off-screen, it could impact that heavily.

Issue Area: Engine
Issue Type: Display
Impact: Moderate
Frequency: Constantly
Date First Experienced: 2022-10-31 00:10:00 (-07:00)
Date Last Experienced: 2022-11-16 00:11:00 (-07:00)

58 Likes

If anything it just goes to show how many problems there are with particles and the camera.

A while ago, I made a thread explaining how the Level of Detail system of particles is strictly based on rendering where the .CFrame is and not where the .Focus is. (Kinda makes true isometric games awkward to work with). And also causes this bug to occur more than often because of how the camera is setup

If these can be looked into and changed then it could maybe fix all the incredibly weird behaviors particles have

8 Likes

It’s definitely a strange one. There’s something I find even more irredeemably weird though: I finally found another thread talking about this, and it was closed as NOT A BUG. This was like 5+ years ago, though.

Apparently it was intentional back then to behave in such weird ways? Bug, Issue, Mistake, - I don’t really care what the developers call it, but it’s clearly an issue that belongs in here. “Please make the particle system not be broken” is not something to put in the feature request category, that’s for darn sure. For shame it was ignored back then, it better not be now! Years later it is even less acceptable.

I need acknowledgement from staff that this is indeed NOT how this is supposed to be functioning, because I genuinely refuse to believe that this is meant to be like this. Bug or not, it is something that was implemented in a way I would describe as non-functioning.

4 Likes

Can confirm that this is an issue for us as well, particles bundle up and then move once the camera is looking in that direction.

Or sometimes just play several seconds after it was originally supposed to if a script played the particles while the camera wasn’t facing that direction.

2 Likes

I remember reading this post but I can’t find it back – could you link it?

This was definitely confirmed to be an intended limitation and not a bug some years ago. So a feature request here would be more appropriate since bugs are addressed much differently from feature requests internally at Roblox.

Agree that “bug report” vs “feature request” is sometimes very confusing from outside looking in and they should probably remove this distinction since to users issues are just issues.

5 Likes

Maybe it was a misunderstanding or mistake in the past because I don’t understand how this can be a feature and not a bug. When particles are emitted using Emit() if it’s not on screen they won’t despawn or at least take far longer than the set lifetime. If it’s a feature what would be the advantage or use to this? Not to mention it causes lag spikes each time a player looks in an areas that has been emitting particles before they looked there. If people wanted a particle to last longer they’d just make it do so. I’d also like to note that this isn’t the case with particles emitted from being enabled. It’s only an issue when you manually use Emit() on the particle emitter. I’d assume it’s not intended for the two to work differently.

4 Likes

Good chance it was added just as an “eh, it’s fine for now” thing. What IMO makes it a bug is the fact that it should have never been allowed to exist for this long. Like, if this was intentional years and years ago, it is clearly not intentional anymore, as nobody has addressed it or payed attention.

Whether it was intentional or not, yeah, it is so far out of Roblox’s quality standards scope that it should be retconned as a bug even if it was ‘intentional’ at the time

I definitely agree with the concept that, if it is something that has no advantages and many disadvantages, it’s categorically an ‘issue’, proper bug or not

Maybe all of the boards need to be re-named. Engine Bugs should become Engine Issues - because there is no way anyone can realistically justify this as a feature request - I believe basically every single developer on roblox expects particles to behave consistently, and the fact they do not is an issue, not a missing feature.

Also, If it is going to be justified as an intended limitation, it needs to be documented as one. The API should straight up say that this is something that will happen, etc. If there is no way for a developer to know of this ‘intended’ limitation prior to active testing, it is an Issue, and likely definable as a Bug, period.

9 Likes

Does roblox expect me to believe, in any capacity, that they are capable of releasing a full dynamic cloud system, but cannot support a player spawning a few clouds in the sky with particles, due to particles infinitely persisting? Because I don’t.

I also still don’t understand why they play this weird game of “Bug report vs feature request”.
Any attempt to word “Please fix this thing that looks obviously like a bug” as a feature request eludes me, as there is no “feature” being requested. Just the desire to disregard whoever said this was “intentional” behavior at the time - because we need to acknowledge this should not be considered an intentional, permanent solution. If it wasn’t a bug when it was coded, it is now, years later, because it should be clear “particles can crash the game” is not something anyone should have coded to see the light of day.

So here this post remains. I still would like a more proper developer response out of it. Can talk about “bug vs intentional” all you want after that, but the post has to go somewhere.

4 Likes

Bumping this up cause this still has not been fixed. You’d think that Roblox, the one krillion dollar company would fix this simple issue after all these years right?

(no)

This utterly ruins performance in any games that use :Emit() for particles. Seriously, Roblox, fix this!
And even if one staff member noticed one of the other posts about this bug, its gone past the “next quarter” they were going to investigate this in!

Any, and I mean any amount of information about the status of this bug would be greatly appreciated.

6 Likes

Yeah I’m not really sure why we’ve had so little transparency on this.

Does roblox not realize this problem can literally bring the game to it’s knees? Like, this is an issue that I have straight up seen reports of game-crashing from. Developers must be excessively careful when using particles as, with larger games, the particle persistence can genuinely destroy a game’s performance.

Roblox, we need an official response. And not just some random moderator going “uhm technically this isn’t a bug, so instead make a feature request asking the developers to make particles function”. Because honestly if I make a feature request asking that I’m probably just going to get THAT posted deleted too - It really doesn’t fit anywhere. We aren’t requesting a feature. We are requesting for a broken system to be fixed!

Roblox, we need transparency on this one, please. We need to know why this was ever an issue, and what’s taking so long to solve this bug that feels like it should be extremely high priority.

3 Likes

Bump. I’m surprised this thread hasn’t received any activity from Roblox.

6 Likes

Isn’t this a HUGE issue? Yielding particle rendering and executing all of them together the moment a player’s camera looks at the emitter isn’t optimal at all.

I emit a lot of particles for a fighting system and it’s quite baffling that I would have to manually check the camera’s look direction as well as distance to make this engine issue less prominent (by avoiding Emit() at all)

3 Likes

This issue makes Emit a footgun. It’s rendered completely and utterly useless. I will not use this API. Roblox can do better.

5 Likes

Their developers do better sometimes…

2 Likes

As far as roblox is concerned, this is not even an issue or a bug. But I refuse to let them use that as an excuse, hence why we’re in this topic!

6 Likes

Bumping this again due to it heavily effecting my game that uses the particle system to create different weather, there should be no reason that particles keep playing when the player is looking away especially if the camera is locked in first person.

5 Likes

Amen! Dev relations tend to be very good at replying to things but on certain threads, it’s hard to say whether they are purposefully ignoring it, or just haven’t seen it.

The moderators sure saw it when they played “Board ping-pong” with whether or not this was a feature request or a valid issue report.

Is there just like an @ Dev Relations we can ping? They’re all over the place but never where they need to be.

5 Likes

This is definitely not good if this is intentional as particles shouldn’t be stored when culled out. They should be culled out but still moving so that they can be culled back in by your camera looking towards them or them moving into your camera view. It is possible that you could stack up particles like this and cause major lag if I am correct on what happens. I am no expert on this, so if I am wrong, don’t be afraid to correct me!

3 Likes

Roblox still refuses to acknowledge this issue, with multiple moderators taking down previous posts regarding this issue as “intentional” but not a single person recognizing that perhaps this, whether intentional at the time or not, is clearly an extreme issue that can cause performance problems and Crashing.

I wonder if, because of it not being a “”““real””“” bug, if the internal systems Roblox’ tracks bugs with literally has no place for it? Is this like a ghost issue?

2 Likes

You’re right, but the issue goes much deeper - It isn’t just that they aren’t moving, they aren’t despawning. If you have a particle that lasts 1 second and spawns once per second, and look away for 100 seconds, you will essentially have 100 particles spawning in when you look in that direction.

It makes literally no sense. It is the most incompetent “intentional” behavior to ever be programmed.

5 Likes