Lights: Add selective lighting via layers

[FarazzShaikh]

Related issue: #5180

Description

Adds support for selective lighting via Layers - Lights and object mask are passed in an uniforms, then, a light is only calculated if it passes the mask test.

Potential issue

This impl uses logical AND & which is only supported in GLSL ES version 3. Do we want to support version 1 and 2 as well? In which case I will be looking for a way to polyfill AND.

TODO

• Fix support for multiple lights
• Add support for all other light types (Currently only supports point light)
• Polyfill logical AND

three.js.examples.-.Google.Chrome.2024-06-12.20-47-08.mp4

[github-actions]

📦 Bundle size

Full ESM build, minified and gzipped.

Filesize dev	Filesize PR	Diff
679.4 kB (168.3 kB)	681.4 kB (169 kB)	+1.98 kB

🌳 Bundle size after tree-shaking

Minimal build including a renderer, camera, empty scene, and dependencies.

Filesize dev	Filesize PR	Diff
457.4 kB (110.4 kB)	459.4 kB (111.3 kB)	+1.98 kB

[Mugen87]

Similar to transform feedback (see #14416 (comment)), I'm not in favor of adding support to selective lighting in WebGLRenderer since we already have this working for WebGPURenderer.

https://threejs.org/examples/webgpu_lights_selective

The renderer has a WebGPU and WebGL backend and the demo works for both of them.

We are currently in the process of a slow migration from WebGPURenderer to WebGLRenderer and that means we only add selected features to WebGLRenderer anymore. Meaning features with a manageable scope. Your PR will add quite a lot of complexity until all light types and other TODOs are implemented. IMO, it's out of scope. It's probably best if you start using WebGPURenderer if you want selective lighting in your app.

@mrdoob How do you feel about this?

[FarazzShaikh]

Gotcha, feel free to close if truly out of scope. However, this PR even when complete will not really be too complicated, its a few uniforms and a few lines of shader code.

In my opnion, even if core developement on WebGLRenderer is halted, Three should still allow for community driven updates to it since I believe the use of WebGLRenderer will stick around for a good while even after the migration to the new renderer is complete.

[Mugen87]

Yeah, I can understand that. Depending on how Ricardo and others from the core team think about this issue, we maybe decide differently. So let's keep this PR open.

But I also see devs discovering WebGPURenderer, the new material system and especially TSL and they are excited about the new possibilities. It is not surprising if these people can't wait to migrate and then do not miss WebGLRenderer at all.