Search Unity

ParticleSystem.Update using significant resources even for default particle system

Discussion in 'General Graphics' started by dgoyette, Dec 11, 2016.

  1. dgoyette

    dgoyette

    Joined:
    Jul 1, 2016
    Posts:
    2,413
    I'm pretty confused about what I'm seeing here. First, the profiler capture:

    upload_2016-12-10_22-38-31.png

    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.
     
  2. dgoyette

    dgoyette

    Joined:
    Jul 1, 2016
    Posts:
    2,413
    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...
     
  3. richardkettlewell

    richardkettlewell

    Unity Technologies

    Joined:
    Sep 9, 2015
    Posts:
    1,373
    It's likely that this is a known issue we are working on resolving in a future version.

    If it's what I think it is, the particle system is waiting until the previous frame's rendering is complete, before modifying the particles for the current frame. This can happen when you have a lot of other rendering happening.
     
    SteveHinan likes this.
  4. niflying

    niflying

    Joined:
    Jul 11, 2012
    Posts:
    53
    Some problem here on unity 5.5.1p1. Any idears ?

    QQ截图20170205105727.png
     
  5. richardkettlewell

    richardkettlewell

    Unity Technologies

    Joined:
    Sep 9, 2015
    Posts:
    1,373
    Hard to say what's going on, with just a screenshot. Can you log a bug with a repro project?
    Alternatively, looking at the Timeline view of the profiler might give me a better insight into what's happening here.
     
  6. J_P_

    J_P_

    Joined:
    Jan 9, 2010
    Posts:
    1,023
    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?
     
    Last edited: Feb 8, 2017
  7. Hyperg

    Hyperg

    Joined:
    Jul 6, 2015
    Posts:
    18
    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 :)
     
  8. Pixelome

    Pixelome

    Joined:
    Sep 30, 2014
    Posts:
    10
    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.
    Particles.png
     
    Last edited: Feb 27, 2017
  9. turritom

    turritom

    Joined:
    Mar 22, 2013
    Posts:
    113
    Unbenannt.JPG 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
     
    Last edited: Mar 30, 2017
  10. turritom

    turritom

    Joined:
    Mar 22, 2013
    Posts:
    113
    fixed in the unity 5.6 f03 Version
     
  11. Killersan

    Killersan

    Joined:
    May 27, 2014
    Posts:
    76
    I have 5.6.f03 and the problem is still occurs.
     
  12. Bravo_cr

    Bravo_cr

    Joined:
    Jul 19, 2012
    Posts:
    148
    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.
    Particle Update iPad Air 2.png
     
  13. RaventurnPatrick

    RaventurnPatrick

    Joined:
    Aug 9, 2011
    Posts:
    36
    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?
     
  14. richardkettlewell

    richardkettlewell

    Unity Technologies

    Joined:
    Sep 9, 2015
    Posts:
    1,373
    We fixed a bug that could be affecting you, which will land in 5.6.1p1. It caused the update jobs to be dispatched really slowly on some platforms.

    The bug in question was only present in 5.6.x, so would not affect earlier Unity versions.
     
    Last edited: May 14, 2017
    karl_jones likes this.
  15. samizzo

    samizzo

    Joined:
    Sep 7, 2011
    Posts:
    482
    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?
     
  16. LacunaCorp

    LacunaCorp

    Joined:
    Feb 15, 2015
    Posts:
    145
    Getting this at a constant ~4ms on 5.6.2f1.
     
    MartinW likes this.
  17. MartinW

    MartinW

    Joined:
    Feb 14, 2013
    Posts:
    7
    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)
     
  18. varfare

    varfare

    Joined:
    Feb 12, 2013
    Posts:
    227
    1000 particles on any CPU particle system in any engine is a HUGE amount, especially if you are using collisions.
     
  19. artaka

    artaka

    Joined:
    Feb 19, 2013
    Posts:
    128
    This is still an issue in Unity 2017.2.0b11. Here are screenshots from the Editor and an Android device.

    Editor ParticleSystem_EndUpdateAll_Editor.png

    Android
    ParticleSystem_EndUpdateAll_Android.png
     
    xw132456 likes this.
  20. artaka

    artaka

    Joined:
    Feb 19, 2013
    Posts:
    128
    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.
     
  21. richardkettlewell

    richardkettlewell

    Unity Technologies

    Joined:
    Sep 9, 2015
    Posts:
    1,373
    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/is...op-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.
     
    ifurkend likes this.
  22. richardkettlewell

    richardkettlewell

    Unity Technologies

    Joined:
    Sep 9, 2015
    Posts:
    1,373
    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.
     
  23. artaka

    artaka

    Joined:
    Feb 19, 2013
    Posts:
    128
    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.
     
  24. SteveHinan

    SteveHinan

    Joined:
    Nov 5, 2014
    Posts:
    6
    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%
     
  25. johnnyppp

    johnnyppp

    Joined:
    Jan 18, 2017
    Posts:
    4
    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?
     
    Last edited: Oct 18, 2017
  26. tomas-3rdeye

    tomas-3rdeye

    Joined:
    Oct 2, 2017
    Posts:
    1
    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.
     

    Attached Files:

  27. Partel-Lang

    Partel-Lang

    Joined:
    Jan 2, 2013
    Posts:
    2,019
    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
     
    Last edited: Dec 23, 2017
  28. zelmund

    zelmund

    Joined:
    Mar 2, 2012
    Posts:
    396
    making game in VR and.... particles is huge problem in 2017.3 ((((
     
    unity_7Mgl4I4SM_R0_Q likes this.
  29. richardkettlewell

    richardkettlewell

    Unity Technologies

    Joined:
    Sep 9, 2015
    Posts:
    1,373
    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).
     
    karl_jones likes this.
  30. Gnimmel

    Gnimmel

    Joined:
    Apr 21, 2010
    Posts:
    353
    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?
     
    unity_7Mgl4I4SM_R0_Q likes this.
  31. Yoirgla

    Yoirgla

    Joined:
    Jan 2, 2015
    Posts:
    15
    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 ?
     
  32. Partel-Lang

    Partel-Lang

    Joined:
    Jan 2, 2013
    Posts:
    2,019
    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.
     
    unity_7Mgl4I4SM_R0_Q likes this.
  33. richardkettlewell

    richardkettlewell

    Unity Technologies

    Joined:
    Sep 9, 2015
    Posts:
    1,373
    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.. :)
     
    Last edited: Feb 15, 2018
  34. matteumayo

    matteumayo

    Joined:
    Jul 25, 2016
    Posts:
    170
    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.
     
    Last edited: May 21, 2018
  35. richardkettlewell

    richardkettlewell

    Unity Technologies

    Joined:
    Sep 9, 2015
    Posts:
    1,373
    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.
     
  36. artaka

    artaka

    Joined:
    Feb 19, 2013
    Posts:
    128
    Great! Looking forward to the fix!
     
  37. glenneroo

    glenneroo

    Joined:
    Oct 27, 2016
    Posts:
    48
    Was the fix backported to 2018.2?
     
  38. ralphyua

    ralphyua

    Joined:
    Mar 28, 2017
    Posts:
    20
    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.
     
  39. GS796

    GS796

    Joined:
    Dec 16, 2016
    Posts:
    20
    Will this fix be backported to the 2017.4.X LTS build?
     
  40. richardkettlewell

    richardkettlewell

    Unity Technologies

    Joined:
    Sep 9, 2015
    Posts:
    1,373
    No we think it’s too risky
     
  41. idurvesh

    idurvesh

    Joined:
    Jun 9, 2014
    Posts:
    493
    Is the bug fixed in 2018.3 ?
     
  42. laurelhach

    laurelhach

    Joined:
    Dec 1, 2013
    Posts:
    229
    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.
     
  43. richardkettlewell

    richardkettlewell

    Unity Technologies

    Joined:
    Sep 9, 2015
    Posts:
    1,373
    Hi everyone,

    We (finally) have another update on this. Thanks for your patience.
    The work has been completed and will be available in 2018.3. The first version it will be available in is 2018.3.0b7.

    Due to the scope of the fix, we do not believe it is safe to backport to 2017.4 or 2018.2, as it could introduce other unwanted side effects. We have time to fix these kinds of issues during the 2018 beta cycle, but cannot risk shipping to our stable 2017 release cycle, in case it causes other issues. Apologies that this fix will only be available in the 2018 cycle.

    To be clear:
    The fix is in 2018.3
    The fix is not in 2017.4 or 2018.2
     
    Last edited: Oct 25, 2018
    laurelhach, Hades714 and matteumayo like this.
  44. Ayfel

    Ayfel

    Joined:
    Feb 28, 2015
    Posts:
    13
    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...
     
  45. jjejj87

    jjejj87

    Joined:
    Feb 2, 2013
    Posts:
    362
    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.
     
  46. richardkettlewell

    richardkettlewell

    Unity Technologies

    Joined:
    Sep 9, 2015
    Posts:
    1,373
    I'll try to explain it..

    That is not what risk is. Or at least not what this risk is. That was some previous risk we took when we changed the code the first time. We can't go back and undo that. Mistakes happen. Making further changes introduces new, different risks.

    In a nutshell, risk is the potential for unexpected bad things (tm) to happen as a result of us changing the code. We have already discovered 2 quite serious side-effects from this fix in 2018.3, for which fixes are in progress for. That's ok because it's still in beta. (although new bugs are never ideal and we make every effort to avoid them) If I had backported this, a lot of people would have serious problems with 2017.4 right now. Far more serious than this bug.

    Unfortunately this is about you taking the risk vs. everyone who uses 2017.4 being forced to take the risk. I understand that there are a small number of users such as yourself who care passionately about this issue, and I sympathise with that, but that alone is not enough for us to risk making changes that affect all Unity developers on the LTS version.

    How will we know what is safe? Some bugs can't be fixed in 2 lines of obvious code. I wish it was that simple :)

    I am truly sorry but there is no potential for it being backported. The change is large, bugs are still being fixed with the solution, and the surrounding codebase has also changed in 2018.3, making it non-trivial to even begin to integrate into 2017.4.

    I know this must be disappointing, but I've attempted to explain it as fairly as I can - there will always be some bugs/problems that can only be fixed in future versions with new work/redesign of the code.

    Best regards,
     
    karl_jones likes this.
  47. jjejj87

    jjejj87

    Joined:
    Feb 2, 2013
    Posts:
    362
    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.
     
  48. madcowie

    madcowie

    Joined:
    Aug 11, 2014
    Posts:
    16
    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.
     
  49. richardkettlewell

    richardkettlewell

    Unity Technologies

    Joined:
    Sep 9, 2015
    Posts:
    1,373
    I recommend using some profiling tools to diagnose the cause more precisely. Or submit your repro project as a bug report and we'll take a look once it's been processed by QA.
     
  50. weiping-toh

    weiping-toh

    Joined:
    Sep 8, 2015
    Posts:
    56
    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()?
     
unityunity