- Home /
ParticleSystem.Emit disables culling?
Hi All,
I'm working a lot with particle systems on mobile VR. I've found this blog post extremely useful, but I have a question about one of its points.
In the section Invalidating procedural mode in the player it says that emitting via script will cause the particle system to enter procedural mode, and that the "tell" for that is that the system's bounds will keep reconfiguring.
I am emitting via script, but as far as I can tell the yellow bounds stay static. I can see that if I switch to world space they do start reconfiguring every frame, but this isn't what I see after calling Emit - the box looks fixed, as it did before, and I can't tell if emitting via script is actually invalidating the system's bounding box.
Is this something that changed in an update to Unity? And is there a definitive attribute I can query on the particle system to see if it's in a "procedural" mode?
Thanks,
John
Answer by Bunny83 · Nov 06, 2017 at 05:57 PM
Well, you only see a bounds change if your particles actually move and require a bounds change. It highly depends on the kind of particle effect you try to create. Certainly nothing has changed in regards to procedural mode and non procedural mode. If you actually understand what that blog post was telling you it should be clear.
The procedural mode can only work when it can actually predict where each particle is in the future and past. Of course when you manually emit particles this is not the case.
You also seem to have misunderstood the information about culling. Both, a procedural and a non-procedural particle system are culled based on their bounds. Culling means frustum culling. So when the systems bounds leave the visible area the system is not rendered anymore. However not being rendered does not mean it's not updated. Procedural systems don't need to be updated when culled because they can simply "jump" to a new state in the future when the system comes back into view. Non procedural systems can't do this because you could actually call Emit while it''s off screen. The newly emited particle needs to be simulated every frame in order to know it's position.
Ok, to summarize - manually emitting particles breaks the predictable nature of a procedural system, and so the system must be updated even if off screen.
What I'm really interested in is occlusion culling. You specifically mention frustum culling but the blog post does not. The blog post does mention using culling groups for custom implementations, and I think those can use pre-baked occulsion maps to deter$$anonymous$$e visibility. What I'd like to do is make sure my particle systems don't get rendered if they are occluded. Is this possible?
Yes, they should be occlusion culled as well (if you actually baked the occlusion culling data). Note that occlusion culling only makes sense in certain situations.
Though occlusion culling should actually work on every visual renderer by testing it's bounds.
ps:
What I'm really interested in ...
Why didn't you ask this in the first place? ^^
As you correctly pointed out I had confused render culling with update culling. Because the article mentions culling groups I thought it was clear that both occlusion and frustum culling were on the table.
Does the following situation make sense for occlusion culling?
I have numerous particle systems in my scene but all are not visible together. I don't want to render particle systems that are in front of me if I know I can't see them (thanks to the occlusion map.) I can see that my geometry is being culled correctly by my occlusion map, but I wasn't sure if the particle systems (and my invalidation of them via script) would have an impact.
Your answer
![](https://koobas.hobune.stream/wayback/20220612142501im_/https://answers.unity.com/themes/thub/images/avi.jpg)