ParticleSystem.Update using significant resources even for default particle system

If you are using 2017.1 or newer, and you are also using either of the Size modules on your sub-emitters, then you may be hitting this issue: https://issuetracker.unity3d.com/issues/shuriken-particle-system-waitforjobgroup-cause-huge-fps-drop-after-upgrading-from-5-dot-6-to-2017-dot-1, which is fixed in upcoming patches (2017.1.p4, 2017.2.0f2)

But, it’s a lot of guesswork.

If you want real answers, submit a bug report with a minimal reproduction project demonstrating the problem, and we can provide better help.

1 Like

Without knowing anything about your Particle System(s), it is hard to provide much useful help. Perhaps inspect the worker threads in the Timeline Profiler to see exactly where the time is being spent.

Thanks Richard,
Looking forward to the upcoming patches. Meanwhile, I’ll try to find the time to put together a minimal scene for reproducing the bug.

I am having similar problems with my particles in Unity 2017.2 running on Android S8+ Gear VR setup.
I did not notice this problem in 2017.1 before I upgraded to 2017.2

PreLateUpdate.ParticleSystemBeginUpdateAll

  • ParticleSystem.Update
  • WaitForJobGroup 52.7%

Have this same issue, SteamVR setup, just updated and now have this issue.
There is no active particle system in the scene.

EDIT: Changing GameObject of the particle system has fixed the issue, not a satisfying solution, is there more information?

Hey, Richard.

We too hit this issue running 2017.1.2p4. Running with VR (Oculus via SteamVR) in the editor. Even with particle systems disabled PreLateUpdate.ParticleSystemBehinUpdateAll takes a lot of time. Deleting all particle systems completely eliminates it and improves frame time.

I’m including a particle system which you should be able to drop into Unity’s VR demo to reproduce the case.

3328781–259380–particle.unitypackage (52.7 KB)
3328781--259382--drop.png

Happens in Unity 2017.3 with “Virtual Reality Supported” enabled.

Very easy to reproduce:
Make a new project, add a Particle System to the scene. Play the scene, see the Profiler being nice and smooth.
Enable “Virtual Reality Supported” in the Player Settings, play again and take a look at ~2ms spikes from ParticleSystem.Update.

Does not happen with legacy particle emitters, Particle.Update takes 0.00.

Case no 981387

3 Likes

making game in VR and… particles is huge problem in 2017.3 ((((

1 Like

Hi, I have looked at this bug. (To others reading this, it is not specific to VR).

Unfortunately, the behavior is currently By Design.

If you unroll the Particle System marker, you’ll see it’s waiting for the previous frame’s rendering to complete.
This is a current design limitation, but shouldn’t have much impact on your overall performance. We are hoping to remove it in the future, but, in all likelihood, the Render Thread is just too busy (see Timeline view in the profiler). If this stall wasn’t there, it would just stall a little bit later, before executing Camera.Render, instead.

Why does this happen?

The next logic frame (main thread) is allowed to start, while the previous frame’s rendering is still being submitted.
We cannot simulate the particle systems until the previous frame is finished drawing it (otherwise we risk modifying data that the render thread is still using).

1 Like

I have just ran into this myself. I updated unity today after oculus wanted to update my graphics driver as well as a few others things and I have regretted it since.

My game was running fine at about 120 to 150 fps in the editor using SteamVR on an oculus, but now it runs at around 50 to 60 fps making me very sick.

The profiler says particleSystem.Update is at 63%!

I updated unity from 2017.2 to the latest, but I also updated a older nvidia driver for my GTX 1070, so it could be driver related?

1 Like

Hi. I disagree with what you said. I think the render are done pretty quickly but the issue comes from the particle system itself. As far as I’m concerned, my prototype runs at 250+ fps if I only have one camera in scene (VR camera) but as soon as I place my 2 portals, and my camera count goes from 2 to 6, the particle update time takes above 50% of each frame. i should be around 100+fps without it. It is my impression something is wrong with the particle system itself.
Here is a screenshot with the issue.

Here is a screenshot without the issue (nothing changed, just paused the editor for a few minutes and played again)

Any ideas ?

Thanks, but I can’t really agree with “shouldn’t have much impact on your overall performance”.
As soon as I fire some particles, the game slows down from > 100fps to 50 fps and speeds back up only when the particles stop, also in a build.

1 Like

Ah, that’s disappointing to hear - can you DM me with a screenshot of your timeline Profiler, and we can try to dig a bit deeper and see if there is something we can do? The key would be to find out what the main thread is doing after the stall, and before Camera.Render begins. (Presuming the repro project in the bug is too simple to show this slowdown, please correct me if I’m wrong and I will repro myself instead).

Best moving to DM as this thread is a bit unwieldy… :slight_smile:

I appear to be suffering from this issue after upgrading to 2017.3.1f1. Is there any solution/news on this? Or are VR users stuck without being able to utilize the particle system? Thanks.

Hey all,

I want to resurrect this old thread to let you know that this issue is not being ignored - we are working on a fix for 2018.3, and hoping to be able to backport it to 2018.2.

We have redesigned the part of our code that was causing this stall, so we no longer have to wait for the Render Thread to “catch-up” before the next Particle System update can begin.

4 Likes

Great! Looking forward to the fix!

Was the fix backported to 2018.2?

I am finding CPU spikes with the ParticleSystem.Update as well. Doesn’t happen all of the time, but when it does happen, it takes over 35 ms to process a frame. Hope this will be fixed soon.

Will this fix be backported to the 2017.4.X LTS build?

No we think it’s too risky