SSRPass: throws err for a simple scene.

Describe the bug

  • An err is thrown when i call render() on EffectComposer{} which is added a SSRPass.
  • The err only occurs when my scene contains both Meshs and InstancedMeshs.

To Reproduce

Steps to reproduce the behavior:

  1. add 1 instanced mesh and 1 regular mesh to then scene
  2. make an effect composer; add a RenderPass .. followed by a SSRPass.
  3. call composer.render() in animation loop.
  4. bring up devtools, it shows

Uncaught TypeError: can’t access property “isInterleavedBufferAttribute”, attribute is undefined

stacktrace:

    get https://cdn.jsdelivr.net/gh/mrdoob/three.js@dev/build/three.module.js:12445
    setupVertexAttributes https://cdn.jsdelivr.net/gh/mrdoob/three.js@dev/build/three.module.js:14100
    setup https://cdn.jsdelivr.net/gh/mrdoob/three.js@dev/build/three.module.js:13770
    renderBufferDirect https://cdn.jsdelivr.net/gh/mrdoob/three.js@dev/build/three.module.js:23733
    renderObject https://cdn.jsdelivr.net/gh/mrdoob/three.js@dev/build/three.module.js:24269
    renderObjects https://cdn.jsdelivr.net/gh/mrdoob/three.js@dev/build/three.module.js:24242
    render https://cdn.jsdelivr.net/gh/mrdoob/three.js@dev/build/three.module.js:24025
    renderOverride https://cdn.jsdelivr.net/gh/mrdoob/three.js@dev/examples/jsm/postprocessing/SSRPass.js:577
    render https://cdn.jsdelivr.net/gh/mrdoob/three.js@dev/examples/jsm/postprocessing/SSRPass.js:396
    render https://cdn.jsdelivr.net/gh/mrdoob/three.js@dev/examples/jsm/postprocessing/EffectComposer.js:150
    <anonymous> https://fiddle.jshell.net/_display/?editor_console=true:196
    onAnimationFrame https://cdn.jsdelivr.net/gh/mrdoob/three.js@dev/build/three.module.js:23897
    onAnimationFrame https://cdn.jsdelivr.net/gh/mrdoob/three.js@dev/build/three.module.js:12286
    start https://cdn.jsdelivr.net/gh/mrdoob/three.js@dev/build/three.module.js:12299
    setAnimationLoop https://cdn.jsdelivr.net/gh/mrdoob/three.js@dev/build/three.module.js:23911
    <anonymous> https://fiddle.jshell.net/_display/?editor_console=true:195

Live example

  • jsfiddle (see devtools console for the err)

Expected behavior

it should render a box and two spheres .. w/ reflection on their surfaces.

Platform:

  • Device: [Desktop]
  • OS: [Windows]
  • Browser: [Firefox]
  • Three.js version: [dev]

Thanks.

6 thoughts on “SSRPass: throws err for a simple scene.

  1. Yeah, I also found in this non-composer scene https://jsfiddle.net/gonnavis/hjgdrfv5/2/ , the instancedMeshes (two spheres) which probably caused this problem are rendered, but the ordinary mesh (the cube) not rendered. So it should be the error throwed in instancedMesh blocked the subsequent ordinary mesh render.

    After swap the creation in this non-composer scene https://jsfiddle.net/gonnavis/hjgdrfv5/5/ , I see one ordinary mesh and one instance rendered ( should be the first instance rendered ). So the normal infos still not all correct, this is why in https://jsfiddle.net/trch4517/ just one sphere has reflection.

  2. @ycw @Mugen87 The main problem may because of instancedMesh and regular mesh can’t share same material now.

    One obvious low-performance workaround is, at here

    insert

    	this.scene.traverseVisible( child => {
    
    		child._normalMaterial = new MeshNormalMaterial();
    
    	});
    

    and replace these codes

    this.scene.overrideMaterial = overrideMaterial;
    renderer.render( this.scene, this.camera );
    this.scene.overrideMaterial = null;

    with

    		this.scene.traverseVisible( child => {
    
    			child._SSRPassMaterialBack = child.material;
    
    			child.material = child._normalMaterial;
    
    		} );
    		renderer.render( this.scene, this.camera );
    		this.scene.traverseVisible( child => {
    
    			child.material = child._SSRPassMaterialBack;
    
    		} );
    

    then it works well. If do some type check, just create two MeshNormalMaterials for instanced or regular mesh seperately, would be better.
    image

    But the fundamental problem seems too in-depth for me to solve~~

  3. If it’s only about material sharing, #20135 should fix it.

    In any event, we should not start to add fixes per pass. The renderer should handle this internally.