instanceColor attribute is not defined when InstancedMesh is populated asynchronously

Just as the title says. It all boils down to this line https://github.com/mrdoob/three.js/blob/dev/src/renderers/webgl/WebGLPrograms.js#L171. Setting any color for any instance just after the instanced mesh is created, solves the issue. But this is not obvious and looks like it’s not documented.

To Reproduce

1. Prepare a scene with InstancedMesh
2. Render it
3. Populate the instanced mesh asynchronously

Live example

jsfiddle

Expected behavior

When setColorAt is called, the shader should be recompiled to include the instanceColor. Or there should be a valid and documented way to make sure that this attribute is always defined.

Platform

• Device: Desktop
• OS: Windows
• Browser: Chrome
• Three.js version: r128

[mrdoob]

Hmm, I wonder… what would happen in this case?

const material = new THREE.MeshBasicMaterial();

const mesh1 = new THREE.InstancedMesh( geometry, material, 10 );
scene.add( mesh1 );

const mesh2 = new THREE.InstancedMesh( geometry, material 10 );
scene.add( mesh2 );

And asynchronously we did:

mesh2.setColorAt();
material.needsUpdate = true;

Because material is shared between mesh1 and mesh2 then it’s possible that WebGLRenderer will handle mesh1 first and set material.needsUpdate to false and by the time it handles mesh2 (which now has instanced colors) it won’t know that it needs to update because material.needsUpdate was set to false…

[Mugen87]

@mrdoob It does not crash when a built-in material is used. https://jsfiddle.net/we76xsvr/1/

The OP also missed to set material.needsUpdate = true;. InstancedMesh is created without instanceColor. When added, the shader program needs a recompile. If the renderer should hide this, it would be necessary to check each frame if colors are present or not. For performance reasons, I do not vote to do this since the presented use case seems rare to me.