Wrong material (wrong color) renderer bug?

I need to spend some time to make a reproduction. Also I should update from r125 to latest, maybe it’s been fixed already.

In this video, the long mesh should be teal, and the ear piece should be gray.

However, based on the camera angle, both objects render with one material or the other, which makes it seem like a resource tracking bug in WebGLRenderer:

Have you seen this sort of thing before? I thought at first maybe I had duplicate objects, and perhaps they were “popping”. But after triple checking, using three-devtools, that is not the case.

1 Like

Look into console what content scene in childrens.

Correct. If the issue is still present with the latest version, please share a live example for debugging.

I was able to reproduce the above bug consistently with r124. I have upgraded to r139, and now the bug (or similar bug) still exists, but it changed, and now it happens with different geometry/material combos at different camera angles, though it seems to happen less often (at least in my cases).

Here is the previous demo, which now works as expected (the green stick was always supposed to be green):

Now here is a case where it breaks, and color changes from gray (correct) to white (incorrect):

These are fairly simple scenes. However, I don’t have a simple enough reproduction yet, because I’m using LUME’s custom 3D HTML elements. I will post a demo soon, along with how to view the Three.js scene in console. I have Three Devtools, and I don’t see anything odd.

May be you have two models - gray and white and they have z-fighting because placed very close.
If you have shadows, maybe its artifact because bias options setted 0.
Can you upload weapon model file here?

@Chaser_Code It’s not the case unfortunately. The parts that have the issue randomly change depending on what’s in the scene. For example, in the following video it’s the ground, which is just a simple mesh with PlaneGeometry:

scene.toJSON() is too big to post here, but it shows there is only a single PlaneGeometry used by only one Mesh.

I also know things aren’t being recreated because when I move the camera so things are a different color and record a new scene.toJSON() output, there is still only one PlaneGeometry with the same UUID assigned to the same Mesh having the same UUID.

It seems to me like an issue in WebGLStates or similar class.

@Mugen87 @Chaser_Code Here is a reproduction (requires Meteor). It isn’t shadow acne or geometry popping, the behavior is too strange. I think I’ve triggered some different code path inside WebGLRenderer's largely-untested code:

# first install Meteor:
curl https://install.meteor.com/ | sh

git clone https://github.com/LUMECraft/first-person-shooter.git
cd first-person-shooter
git checkout threejs-discourse-34839

# run the server
meteor --exclude-archs "web.browser.legacy, web.cordova"

Now open http://localhost:3000

Alternatively if you wish not to install Meteor, I will publish a demo online by tommorrow. I can also make a zip file containing a standalone Node.js app later.

You will see the following, and if you click the app to lock the mouse, and then look around, you will see sometimes an object changes color (which object is random, depending on what is in the scene, in this case the floor):

Try moving around with WASD keys.

Every time you refresh the app, a player is left behind in your last known position, so after each refresh you will see a player standing still at your last location.

Keep trying to walk/look around. As you refresh more times, each time you will notice that the material of an object changes to any of the materials used in the existing objects, and the affected object is not always the same depending on the current set of objects and the camera position.

It appears that the object material that was used for rendering an object fluctuates erroneously within WebGLRenderer.

The floor is supposed to be red and should receive shadows (try firing the gun, and if the floor is red, you’ll see the shadow for the occasional bullet tracer across the red ground), however if the view shows another color, it will be using another material from the models which do not receive shadow, and in that case the ground will not receive a shadow.

Here is the ground with the intended red material and shadow is visible whenever the occasional tracer appears:

Note that when the shadow is visible on the ground, the tracer is visible behind the yellow explosion of the barrel.

Here is a slightly different angle, and in this case although we see the tracer behind the explosion, there is never a shadow on the ground, because the material being used by WebGLRenderer is from the player model:

I believe that WebGLRenderer state tracking has an issue that I’ve somehow triggered.

To see the Scene object and to verify it is not changing while you are in different positioins:

  • open browser devtools
  • find the <lume-scene> element
    • either find and select it in the element inspector
    • or run let $0 = document.querySelector('lume-scene') in the console
  • now run $0.three and this gives you the Three.js Scene object. You can see the whole Three.js tree in $0.three.children
  • similarly, find any element in the DOM such as the <lume-perspective-camera>, and run el.three to get its corresponding Three.js object.

@Mugen87 @Chaser_Code My hunch is this has to do with the fact that the imported FBX models have, for example, arrays of materials for mesh.material, not just a single material, and that this is somehow confusing WebGLRenderer state.

1 Like

@Mugen87 I wonder if the issue here is related to this:

So far, now that I think about this, I have only experienced this issue in scenes that use FBXLoader.