I have a scene where I have a lot of instances of the same particle system. As the game will go for mobile, I fear the particles are calculated even when they are not shown. So to cut it short, I would like to know if the particle system is being calculated and rendered even if off-screen.

  • \$\begingroup\$ This seems like the kind of question you could easily answer for yourself by creating two scenes: one with a hundred particle systems in the camera frustum, and a duplicate scene with all 100 particle systems moved outside the camera frustum. Profile the two scenes on your target hardware and compare the results. This will tell you not only whether offscreen particles have a cost, but precisely how much, and whether it's even worth worrying about for your needs, all with zero Internet hearsay in the mix. ;) \$\endgroup\$ – DMGregory Aug 9 '17 at 1:31
  • \$\begingroup\$ Fair enough, though I usually get some additional wisdom on these forums other than "yes or no" :D I think I will disable those particles if off-camera, they have a warmup anyway. \$\endgroup\$ – agiro Aug 9 '17 at 8:21
  • \$\begingroup\$ This is exactly the kind of internet hearsay I was warning you about. You've currently accepted an answer that says nothing about the costs for the actual case you're asking about. It's a good way to reduce fill rate costs of drawing overlapping particles, but it says nothing about the costs for systems outside of the rendered area. \$\endgroup\$ – DMGregory Aug 9 '17 at 9:09
  • \$\begingroup\$ Thanks for the warning. Well I just asked a boolean question, basically "yes or no"? The answer says "yes they are calculated" and I asked in the comment below the answer for clarification and was told "in my case it's probably no big deal". I'm focusing on finishing the game and optimize this later should the need arise. I'm this sloppy because time is of the essence now :/ spent way too much time on this game already. I don't plan to use that library though :D I might turn the particle systems on/off by camera visibility or player distance. \$\endgroup\$ – agiro Aug 9 '17 at 11:27

Yes they are calculated when offscreen as stated in this library's README (this was quite a problem for them). What is cool is that this library can be used to lower the performance lost by using a second camera. If you don't have much particles then it's not worth but it might be a great improvement if you run a game heavy on particle :

In our game, we're drawing several dozen screens worth of overlapping particles, so the speedup is pronounced.

  • \$\begingroup\$ Thanks for the answer. by "lot of instances" I mean 20-30 instances of particle systems, each having 30 maximum particles. Is that a lot for mobile? No fancy shader, and just some basic floating up movement with some mild turbulence. \$\endgroup\$ – agiro Aug 9 '17 at 8:19
  • 1
    \$\begingroup\$ You will have to try it out, perhaps on different mobiles (especially on one that is not really performing well) but I think it is not a problem at all. 600 particles is nothing if you have no big shader or complex movement. \$\endgroup\$ – Shashimee Aug 9 '17 at 8:22
  • 1
    \$\begingroup\$ Note that the linked library, despite its name, is for speeding up the rendering of ON-screen, visible particles. They talk about fill rate as the primary cost they're optimizing, and you pay that only in-frustum. Their solution was to treat these particles as "off-screen" in the sense of not being drawn by the main camera, and instead viewed by a secondary camera rendering to an off-screen render target at reduced resolution, then upscaled and composited into the main view. So this doesn't actually answer the original question about costs of particles out of frustum. \$\endgroup\$ – DMGregory Aug 9 '17 at 9:05

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.