Many thanks for this great feature! Performance is already great (2-3ms for 50-60 point lights), though we are thinking if there is something we can do to help the renderer when some of the lights are definitely not required to be rendered.
Toggling the light component on/off forces a recompile of something that hangs the main thread for a while. For the moment we just set the intensity to zero for lights that shouldn’t be rendered (for our game purposes).
Curious if there is something in addition we should be doing. Anyway this works already great, many thanks again. @mvaligursky
Thanks @LeXXik! The critters are hardware instanced spheres using an emissive material (the glow is coming from the Bloom post process). So they can be easily animated and have their transform updated. Here is with a simple scaling animation:
I just created this PR Clustered lighting does not use lights with intensity of zero by mvaligursky · Pull Request #3271 · playcanvas/engine · GitHub
Which ignores lights by clustered lighting that have intensity of 0. So that would avoid having to disable the lights which has a cost. At the moment, till the clustered lights are fully implemented (with shadows …), the existing lighting solution is still the driving one and at the moment it rebuilds the shaders if the number of lights change, even though the shader does not use those lights at all. All this code will change when clustered lights are the fully supported lights.
What the clustered lighting does: it gets a list of lights it needs to use per frame (they need to be visible, intensity > 0), creates a bounding box around those, and subdivides that box into a number of cells as you specified. So another way to keep this fast is to keep only the lights around the camera with intensity >0 (for example don’t have one light on another island), as that would stretch the bounds a lot and you’d likely need higher cell subdivision.
And when you have that, use small number of cells, as updating those is costly. Perhaps you could do with 10x3x10 cells or similar.
You can keep an eye on the performance of clusters update by looking at
to see how long it takes to update them. And also how many clusters you have … ideally it should be just one … that would need all lights to have the same layer settings.
Awesome, that will works wonders with our implementation!
Many thanks Martin for the detailed explanation. It starts to feel like we have a deferred render approach, this is amazing to have in WebGL, it can do wonders in a night or indoors scene.
