ParticleSystem.Update using significant resources even for default particle system

I'm pretty confused about what I'm seeing here. First, the profiler capture:



For my profiling session, I put a single ParticleSystem into my scene, just the default particle system you get when adding a PS to a scene, with no changes to it. After a few seconds I turn off the particle system.

My big concern is the first line in my profile Overview: ParticleSystem.Update using 6.33 ms. This seems massive for a simple particle system. Also, it doesn't seem to matter if I put 1 particle system or 10 in my scene: ParticleSystem.Update uses pretty much a constant amount of resources each frame.

The thing is, if I create a brand new project and stick a single particle system into this, I'm NOT seeing ParticleSystem.Update using significant resources. So is it possible I've done something weird with my project settings that is causing the entire ParticleSystem concept to run inefficiently?

I'm just not sure how to dig into this further, as the profile isn't giving me anything else to go on.

Thanks.

 

I just noticed that this only occurs when I disable V-Sync. So maybe with V-sync disabled the particle system just has to do a lot more work than it otherwise would have?

Perhaps this isn't an issue at all...

 

Some problem here on unity 5.5.1p1. Any idears ?

 

Just found this happened to me too (5.5.0). First the profiler was listing a line of code that changed the emission rate, but when I commented that line out it listed ParticleSystem.Update instead -- didn't seem to save any fps. With vsync enabled, neither take much time at all. Vsync off, it shoots up to like 5ms.

So is this a bug with the way it reports in profiler or a bug with particles/vsync that really does cost 5ms? Is there a bug tracker entry already?

edit: if I destroy all particle systems, Gfx.WaitForPresent seems to replace it. So a profiler bug?

 

My issue with ParticleSystem.Update adds even more to the topic confusion (running Unity 5.4.1p4 here): for my test scene, PS.Update only shows on the profiler if I add the GPU graph to the profiler. It does not show otherwise (like in @JTown 's case, it gets "replaced" by Gfx.WaitForPresent).

What's interesting is that this never shows in the editor profiling (w/o gpu profiling or vsync). It's the development builds that revealed the issue.

I was also assessing a project upgrade to 5.5 but from what I'm seeing, this issue waits for me at the other end

 

I'm seeing the same thing in my project, when running on an iPad Air.
A simple particle system with 20 particles max has spikes that add up to 30 ms.
Using Unity 5.4.3f1.

 

same problem here

unity 5.6.0f2

and no changes if i switch vsync on or off

if i disable all particle spawner .. the frame rate goes from 25fps to 50fps

 

fixed in the unity 5.6 f03 Version

 

I have 5.6.f03 and the problem is still occurs.

 

Same issue here, but the behavior differs if using one device or another. On iPad Air 2 its taking 15ms as seeing in the timeline, but on an iPhone SE it doesn't appear at all.

 

I have the same problem - reproducable in Unity 5.6.1f1 as well as 2017.1 beta 5.
InUnity 5.5.0.f3 the scene has around 55-60fps while on >5.6 the scene has 20-30fps with large variation (due to ParticleSystem.Update) - when I remove the particle systems then the problem goes away.
Do you already fix this problem, or do you need more repro samples?

 

I'm seeing this on iPad Air (1st gen) as well. I'm on Unity 5.4.3 but I can't update yet due to a crash that I haven't found a workaround for (reported here). Is there any chance the fix will be back ported to 5.4.3 or any other earlier versions? Or is there a workaround?

 

Getting this at a constant ~4ms on 5.6.2f1.

 

Issue still present in 5.6.2f1, huge performance hit for spawning 1000 particles:

ParticleSystem.Update / WaitForJobGroup / ParticleSystem.UpdateJob / PatricleSystem.CollisionModule (4ms)
Camera.Render / WaitForJobGroup / ParticleSystem.GeometryJob (2ms)

 

1000 particles on any CPU particle system in any engine is a HUGE amount, especially if you are using collisions.

 

This is still an issue in Unity 2017.2.0b11. Here are screenshots from the Editor and an Android device.

Editor

Android

 

I found that the issue is caused by subparticles. At this point subparticles are useless for me and until the issue is resolved, I ended up with a temporary solution. I disable subparticles and instead dynamically create and manage a pool of particle systems for every parent particle. It's not pretty, nor full-proof, but for now it does the job.

 

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.

 

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

 

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

 

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?

 

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.

 

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.

 

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?

 

Is the bug fixed in 2018.3 ?

 

I would also be curious to know when this is fixed because using 2017.3.1p4 (good version) vs 2017.4.12f1 (and more recent) has a big difference in performance with the particle system.

When using 2017.3, I run at 190fps but when I switch to 2017.4 I have half the performances (run at 90 fps).
My project is alsmost empty, but uses a lot of particles.

 

Aargh, I am encountering this issue in 2017.4.10f1 in VR : ( I was hoping LTS would mean we get fixes to these quite important bugs...

 

I don't understand that the backport is too risky. The risk already happened and it is in 2017 LTS in the form of a bug. Some of our projects are on 2017LTS because as the version name states, it is Long Term Support and we are only in the first year of it.

I understand 2018.2 not getting the fix. That wasn't surprising. But 2017LTS not getting the fix?

So, to minimize Unity's risk of not introducing new bugs to 2017LTS, I will be forced to change my project to 2018.3 and take the risk of introducing new bugs to my project? No disrespect, but this is simply wrong.

A particle system that is broken, that will not be fixed for LTS because of risk.

If it is "not safe", then make one that is "safe". That is what the whole Unity Team is for.
If it is "not possible", then mark LTS as a build "not safe" for production.
It is either one of the two.

Please, I urge you. Look at it from the perspective of a developer and re-evaluate if this is an issue that can be over looked. Or drop the LTS name so that other people are not mislead.

 

I really want to take your word for it, but you are not making any sense.

What do you mean you can't go back and undo that? Nobody here asked to go back to previous code. We asked for a fix for a known issue. Are you going back to old code for fixing it in 2018.3? I am guessing not. I don't understand where this "undo" popped out from, unless I missed something.

You are mixing two different things. The first is about taking the risk of implementing a fix that may introduce new bugs. The second is fixing a known bug for a LTS. The two are different. The first can be handled, like you said, by working it out on 2018 Beta, which according to you is fine. (I don't get how fixing a bug in a beta is more important than fixing the same bug in already released build but I will bite) The second can be done on LTS's own schedule. It can either be a backport of 2018 when the fix is mature/stable or a completely new one. Eitherway, the two (how to fix and will you fix) are unrelated. Those two have nothing to do with whether a bug in LTS should be fixed or not fixed. The fix can take time to arrive, and I will understand, but dropping support for LTS midway is just unprecedented.

Nope, it is about Unity taking the risk vs the users of Unity. If you are worried about a change in code effecting every one else, then work on a different repo, release a beta of a LTS. Do whatever that needs to be done. I mean, come on, there are archives of past versions. If this worries you more than actually fixing it, then separate a branch off of it. Again, there is no risk for users other than LTS versions having known issues decided not to be fixed. The risk already crashed for us developers. The only remaining risk or cost is on Unity.

Never said it was simple. It is a matter of "it needs to be done." Imagine you buying a car, and a part of it is broken, and the manufacturer says, "well how would I know if the new fix is safe? this can't be fixed in 2 days - I wish it was that simple. And then he says, "just buy next year's model".

Also, if being safe is what is stopping this fix, then why are you fixing it for 2018.3? Aren't you worried that it will not be safe? I mean how do you tell when it is safe? Are you sure you can get it safe by 2018.3's full release? I mean seriously?

So you are saying that the real reason behind this is because the work required is too much and we were actually talking business rather than coding risks. I am really starting to hope this whole conversation just took a wrong turn and all this is a misunderstanding...

It is not disappointing, but makes me wonder if I made the right business choice to use Unity. I understand that you are in a difficult position, and I am guessing the decision to abandon this bug was not made by you. What worries me is that that "future version" you mentioned is LTS. A long term supported build of the game, not introducing new features but fixing all bugs out over 2 years and providing a stable engine build for production.

Again, please, please fix this for 2017LTS.

 

So I waited a few weeks for 2018.3 to come out due to this post. Did this get fixed as mine is shocking! Im using the particle as dirt spray on a racing game. I have reduced it and reduced it more and more and it still runs rubbish. Its literally a bog standard particle that sends out 3 per second with a very basic shader. The game runs a solid 60 fps on Xbox X and as soon as a single particle appears it drops to high 40s. Using deferred lighting by the way.

 

I believe what richardkettlewell was trying to say that the current problem of particle system that the 2017LTS is using, is not due to a code/programming bug, but a code design flaw, for which in order to address the performance flaw, it commands a major rewrite to most parts of the particle system, which leaves little or no room for stress testing, and backwards compatibility can not be guaranteed.

I am currently using 2018.3 but the the use of particle system is still a CPU performance issue for my current project but due to different reasons (mainly the drawing and rendering). I was wondering if Unity is looking into further optimizations or off-loading the generation of vertices and calculations to the GPU instead of the CPU.

Oh and with regard to the prewarming of particles, does it have to occur on every OnEnable()?