girole
March 28, 2022, 10:44am
1
Hi,
I was looking at unity and a tutorial on YT
In that tuto, we can see that no textures are involved in the process, he just position his lightprobes without preping the scene and they immediately get light info.
Do we have something like this, with no preparation in 3js?
Thanks
Hello! Three.js has lightprobe and generaion color of probe, but without automatic generation grid of lightprobes and code for changing light in depend of object position. Some links:
https://threejs.org/examples/?q=probe
https://threejs.org/docs/index.html?q=probe
opened 03:07PM - 18 Mar 15 UTC
closed 04:26PM - 28 Dec 19 UTC
Suggestion
Right now people can sort of create a light node by creating a cube camera and t… hen manually rendering it. I was wondering if it may be worthwhile at some point to create a light probe node type based on Object3D like UE4 has. It would contain I guess both a cube camera and an HDR cube map texture, as well as some logic for an update strategy (either once or some other frequency.)
I think that for a light probe to be truely useful, it will need something like an exclusion list -- a set of objects that should not be visible when updating the light probe. This is useful for the case of a light probe situated exactly at a location of a key reflective object.
I am a bit confused on how light probes are used by materials in UE4 in the end. Does each object just look for the nearest LightProbe and use that one as its environment map or does it interpolate between the nearest few light probes? Or do you manually assign light probes to a material?
I can view manual assignment of light probes to a material as useful in the case of something like a moving car, have a light probe on the car that is located exactly where the car is.
opened 01:13PM - 12 Apr 19 UTC
Enhancement
##### Description of the problem
Now that we have a LightProbe class (https:/… /github.com/mrdoob/three.js/pull/16191), the Spherical harmonic class (https://github.com/mrdoob/three.js/pull/16187) merged as well as some shader support(https://github.com/mrdoob/three.js/pull/16152), we should explore adding a Tetrahedral tesselation method for interpolating between light probes to the renderer so that it can set the 4 SH + weights per object.
The best reference is this presentation from Unity itself:
https://gdcvault.com/play/1015312/Light-Probe-Interpolation-Using-Tetrahedral
(Referenced from here: https://docs.unity3d.com/Manual/LightProbes-TechnicalInformation.html)
It seems that given a set of light probes you just do a 3D delaunay tetrahedralization and use 3D barycentric coordinates for interpolation and you cache which tetrahedral each object is in to speed up lookups. Pretty simple, just need a standard delaunay algorithm implemented along with a searchable tetrahedral data structure.
/ping @WestLangley @donmccurdy @richardmonette
mrdoob:dev
← donmccurdy:feat-lightprobevolume
opened 09:26PM - 11 Jan 20 UTC
## Summary
A LightProbeVolume samples diffuse indirect lighting in a scene at… each of several LightProbe locations, then provides approximate diffuse lighting for dynamic objects at any location within that space. The method complements baked lighting and lightmaps — which only support static objects — by providing high-quality lighting for dynamic objects as they move throughout a larger scene. Like lightmaps, LightProbeVolumes can be 'baked' offline and stored, then loaded and applied at runtime very efficiently.
Fixes https://github.com/mrdoob/three.js/issues/16228.
Thanks to @WestLangley, @bhouston, and @richardmonette for helpful discussions and code that contributed to this PR.
## API
Bake:
```javascript
var cubeCamera = new THREE.CubeCamera( 0.1, 100, 256, {
format: THREE.RGBAFormat,
magFilter: THREE.LinearFilter,
minFilter: THREE.LinearFilter
} );
// Renderer output is sRGB. Configure renderTarget accordingly.
cubeCamera.renderTarget.texture.encoding = THREE.sRGBEncoding;
// Generate a light probe volume and populate probes in a 10x3x10 grid. Then
// sample lighting at each probe using the CubeCamera.
var volume = new THREE.LightProbeVolume()
.setFromBounds( new THREE.Box3().setFromObject( scene ), 10, 3, 10 )
.build()
.bake( renderer, scene, cubeCamera );
// Store volume and baked lighting as a small JSON object.
var data = volume.toJSON();
```
Apply:
```javascript
// Reconstruct the volume with pre-baked lighting.
var volume = new THREE.LightProbeVolume().fromJSON( data );
scene.add( volume );
probe = new THREE.LightProbe();
scene.add( probe );
function render () {
volume.update( mesh, probe.sh );
renderer.render( scene, camera );
}
```
Lighting is sampled only at the center of each mesh, and larger objects like terrain and buildings will not receive realistic lighting from a single sample. Shadows are not cast by light probes.
## Unresolved
- [ ] **Per-object SH.** While per-object SH coordinates can be computed, only one "probe" is actually in the scene graph functioning as a light. So only one mesh can receive dynamic lighting. This can be resolved with an API to assign SH coordinates or a light probe to a specific object or material.
- [ ] **Optimize.** Various inefficiencies left as TODO. For example, LightProbeVolumeHelper should use InstancedMesh, and `volume.update()` should search incrementally from the last known cell to improve update times.
- [ ] **Correct baking.** I'm not convinced my "baking" method is quite right, but it looks pretty good. Maybe this could be done offline in other tools.
- [X] **Class structure.** ~~In this demo, LightProbeVolume is in the scene graph but its probes are not (I don't want them all affecting the mesh). I'm open to other ways of structuring this.~~ It's useful for the volume to have position in the scene.
- [x] **Grid volumes.** ~~Should we allow arbitrarily-shaped volumes, or require grid-shaped volumes? Blender and Godot appear to be OK with grids. That would let us omit the Delaunay library (which generates ~5x~ 1.5x more tetrahedra than needed, for a grid?), improving volume creation time. And if (in the future) we want to upload the whole volume's SH coordinates to a GPU texture for sampling in the fragment shader, I think a grid would be necessary. But it is less flexible / optimizable.~~ Grids only, for now.
## Demo
https://raw.githack.com/donmccurdy/three.js/feat-lightprobevolume-build/examples/?q=volume#webgl_lightprobe_volume
![Screen Shot 2020-01-11 at 1 19 31 PM](https://user-images.githubusercontent.com/1848368/72210746-0f41a600-3475-11ea-96c4-48da18c3e44a.png)
Bug: three.js webgl - lights - light probe volume
Bug: Comparing mrdoob:dev...donmccurdy:feat-lightprobevolume · mrdoob/three.js · GitHub
Better: three.js examples
girole
March 28, 2022, 1:05pm
3
Thanks,
But if I get it right, no usable solution since all those links seem to have it merged at some point but removed afterwards.
I could not find a hint of lightprobe volume in the source.
So, except if I didn’t get the whole story, there is no comparable solution that can be used right now?
I don’t care to place the probes manually, but I do care not to have a cubemap with predefined textures applied on it to simulate light because the scene is dynamically generated.
To some extent, that looked promising as well but not ready yet…
three.js currently does not support light probe volumes, no. You can track #18371 to be notified if light probe volume support is added.