Panoramas vs PBR renderer

Questions
1

Hi guys I’m creating 360 equirectangular panorama application, but I’m stuck with combination of panoramas and GLTF loader.

when I change renderer encoding to:
THREE.sRGBEncoding meshes looks good, but panorama sucks. When I disable this, panorama looks good and meshes sucks. (I use MeshBasicMaterial for panoramas)

This is encoding on:

image
image621×729 37.7 KB

This is encoding off:

image
image1139×734 68 KB

I tried to change encoding of panorama texture itself with

            new three.TextureLoader().loadAsync(pathToLoad).then((texture: three.Texture) => {
                texture.encoding = three.sRGBEncoding

But there is problem that this operation is too expensive and my panorama streaming has performance issues (but color is good). (I have 64 pieces splited to file which I send to web and place on 64 sphere slices - I cant use drawing on one texture because oculus support and photo get destroyed quality if i go in this way)

2

I’m surprised that setting texture.encoding = sRGBEncoding on the panorama texture would affect performance at all. Are you able to share a demo comparing before/after that change?

3

Hi sorry bad words, its not performance of rendering, its performance of loading. When I load new panorama set without changing encoding is takes about 500ms app freeze (depending how fast they come). But when I change encoding while loading app freezes for 3-8 seconds. I’m also adding video where only difference is encoding comment.

            new three.TextureLoader().loadAsync(pathToLoad).then((texture: three.Texture) => {
                if (panorama.is_previewed) {
                    //console.log(texture.encoding)
                    texture.encoding = three.sRGBEncoding

                    const material = this.frontPanoramaMaterials[moonIndex]
                    material.map = texture
                    material.needsUpdate = true

                    this.frontPanoramasGroup.children[moonIndex].visible = true
4

Hm I think @Mugen87 might know, maybe something related to WebGL 1.0 or a performance issue in a particular browser?

5

The decode of sRGB textures with WebGL 1 is problematic. If a platform does not support the EXT_sRGB extension, three.js performs a slow decode fallback on the CPU via ImageUtils.sRGBToLinear().

So make sure that your device actually uses WebGL 2. If not and you can’t accept the performance, you probably have to avoid a sRGB workflow or stick to r136.

6

I have webgl2 … But I solved this by rewriting glb loader and disabling srgbe convertion