Added LightProbeHelper

[WestLangley]

This should be helpful to someone.

There is a bit of repeated shader code, but we can clean this up when things clarify.

var helper = new THREE.LightProbeHelper( lightProbe, size );
scene.add( helper );

[WestLangley]

The helper is the little guy.

[donmccurdy]

I like this, although the outcome of #16223 discussion may affect it. LightProbeVolumeHelper?

[bhouston]

I think it is a light probe helper. It visualizes a single light probe. :) It is not a volume. The volume helper would probably show the tetrahedral structure as lines with multiple little spheres.

[donmccurdy]

It does that now, but if individual light probes were no longer Object3D instances, should they still have individual helpers?

But LightProbe exists today, and LightProbeVolume is still a topic of active discussion, so I'm fine with merging this. :)

[mrdoob]

Thanks!

[Mugen87]

In the meanwhile, it would be preferable to have LightProbeHelper without a dependency to ShaderMaterial if possible so the helper is usable in WebGPURenderer.

Instead of directly evaluate the probe in a shader, how about converting the probe to an (irradiance) environment map and apply that to the sphere. The texture itself could be generated via JS as aCanvasTexture.

[WestLangley]

Some questions, in no particular order...

1. If we didn't convert to an irradiance map, can we create the custom material in LightProbeHelper in a way that is supported?
2. Should we support Lightprobe defined by an irradiance map -- in addition to SH3?
3. Can we avoid the JS workflow recommended in your suggestion?
4. Light probes have demonstrated use in experimental XR, but that is all (so far) in three.js. Is it even worth pursuing such changes at this time?

[Mugen87]

If we didn't convert to an irradiance map, can we create the custom material in LightProbeHelper in a way that is supported?

I'm not sure how this would work. If we decide against the JS workflow, we probably need a separate helper class. Passing the renderer into the helper won't work because of incompatible imports (three.module.js vs three.webgpu.js).

Should we support Lightprobe defined by an irradiance map -- in addition to SH3?

That would be a nice feature.

BTW: When I remember correctly big engines actually always sample irradiance environment maps in their shaders for performance reasons and do not evaluate the light probe.

Can we avoid the JS workflow recommended in your suggestion?

I've initially thought our light probes should represent baked lighting but then I've seen probes might be updated per frame like in webgl_lightprobe_cubecamera. So I'm afraid the JS workflow would be too slow.

Light probes have demonstrated use in experimental XR, but that is all (so far) in three.js. Is it even worth pursuing such changes at this time?

Granted, it is not a high priority task.

The main issue with our light probe implementation is the lack of a backing feature. However, there is #18371 which I would like to see merged at some point. Defining a JSON format for baked light probe volumes is a start for having exporters.