Three.js: WebGLDeferredRenderer do not support materials with textures

[jhm-ciberman]

Description of the problem

WebGLDeferredRenderer do not support materials with textures.

Steps to reproduce:

• Create a new scene using the WebGLDeferredRenderer
• Add a Mesh with a material using a texture

To reproduce the issue I have only changed the following lines of the webgldeferred_animation.html file, loading "crate.gif" texture and using it as texture map for the walls.

function initRoom() {

    var loader = new THREE.TextureLoader();
    loader.load("./textures/crate.gif", function(map) {

        var size = 100;
        var geometry = new THREE.PlaneBufferGeometry( size, size );
        var material = new THREE.MeshPhongMaterial( { map, color: 0x222222, specular: 0x222222, shininess: 75 } );

        // . . .

    });
}

Actual behaviour using WebGLDeferredRenderer
Walls are black

Expected behaviour using default WebGLRenderer
Walls show the "crate.gif" texture

More screenshots of my own project:

Actual behaviour with WebGLDeferredRenderer (only transparent objects are rendered)

Expected behaviour with WebGLRenderer

Note: This does not affect transparent objects since they are drawn with forward rendering

Link to example reproducing the bug:

https://github.com/jhm-ciberman/three.js/commit/5fac6b002650289bfdfdfac039128ee8ca1e49ce#r36622571

Three.js version

• [X] Dev
• [X] r112

Browser

• [x] All of them
• [ ] Chrome
• [ ] Firefox
• [ ] Internet Explorer

OS

• [x] All of them
• [ ] Windows
• [ ] macOS
• [ ] Linux
• [ ] Android
• [ ] iOS

Hardware Requirements (graphics card, VR Device, ...)

[Usnul]

WebGLDeferredRenderer is basically an educational toy at this point. I don't think you will get very far with it, unless you are planning to upgrade it yourself.

[jhm-ciberman]

That's sad. Well, thanks for the clarification. Then, I think I will move my project to Unity, or some other engine. I think it is okay to close this issue.

[donmccurdy]

@jhm-ciberman note that even in a production-grade deferred rendering workflow, like Unity's, deferred rendering comes with significant limitations: no semi-transparency, no antialiasing, and some performance overhead. But Unity has a good light-baking workflow, and might even have ways to do that with procedural scenes... in any case, best of luck!

[jhm-ciberman]

Thanks! Yes. I'm aware. But reading Unity's documentation I saw that for forward rendering, Unity limits the number of real time lights that are active to a maximum to prevent performance issues. Maybe is there some way to implement this type of smart light selection in Three.js forward renderer? Anyways, I started porting all the code to Unity. I will still use Three.js for smaller projects since I'm in love with the API <3

[donmccurdy]

Maybe is there some way to implement this type of smart light selection in Three.js forward renderer?

Yes — this has been proposed in https://github.com/mrdoob/three.js/issues/5180 and an implementation attempted in https://github.com/mrdoob/three.js/pull/15223. But there are some issues with that PR and it's stalled. I suspect something simpler (using N nearest lights, or filtering with light.distance) would also be possible though much more limited, but I haven't looked closely at this code.

Finally, there are some more advanced ideas like progressive global illumination (https://github.com/mrdoob/three.js/issues/14051) and lightprobe volumes (https://github.com/mrdoob/three.js/issues/16228).

[jhm-ciberman]

Amazing. Hope to see those ideas to grow!