This issue will occur only in Chrome on Mac.
Chrome on Windows works fine.
macOS 10.14.6
Chrome 80.0.3987.149
Chrome Canary 83.0.4099.2
https://codepen.io/novogrammer/pen/VwLqywr?editors=0010
https://www.youtube.com/watch?v=dKl4kenkIYY
I have confirmed the issue on my Windows (Razer Blade 15, GTX1060 Max-Q) and Mac (MBP13 Mid 2014, Iris Graphics)
I can reproduce the issue with Chrome 80.0.3987.149 and Chrome Canary 83.0.4100.0 on maxOS. However, it works with latest Firefox and Safari.
I did not find open issue at https://bugs.chromium.org/p/chromium/issues/list so it probably makes sense to report it there.
@novogrammer Do you mind filing a bug at the Chromium bug tracker?
thank you, @Mugen87.
I reported this issue.
https://bugs.chromium.org/p/chromium/issues/detail?id=1066413
If you can still edit the issue, please ensure it's added to the component Blink>WebGL
. This will make it easier for the Chromium team to analyze the issue.
Besides, I suggest you change the title since it also happens on Windows (see this comment https://github.com/mrdoob/three.js/issues/18999#issuecomment-606384339).
Could the Chrome team get a little more help from the Three.js team reducing this test case? The problem seems to be specifically the use of InstancedMesh per http://crbug.com/1066413 . I don't know whether there's an emulation path for InstancedMesh that might be being taken in Safari and maybe even Firefox. Any help from the Three.js experts in identifying the problematic code paths and WebGL API calls in Three would be greatly appreciated.
I don't know whether there's an emulation path for InstancedMesh that might be being taken in Safari and maybe even Firefox.
The underlying code path of InstancedMesh
is equal for all browsers. It seems the problem is the usage of a video texture in combination with instanced rendering.
Maybe it would be a good idea to enhance the following unit test for instanced rendering with two additional testes using textures (a normal and a video texture).
BTW: An instance of VideoTexture
is just a normal texture that indicates a texture upload like so:
if ( video.readyState >= video.HAVE_CURRENT_DATA ) {
this.needsUpdate = true;
}
This check is performed per simulation step. video
is the internal video element and the needsUpdate
notifies the renderer to perform the texture upload. Apart from that, there are no differences to ordinary textures.
Most helpful comment
The underlying code path of
InstancedMesh
is equal for all browsers. It seems the problem is the usage of a video texture in combination with instanced rendering.Maybe it would be a good idea to enhance the following unit test for instanced rendering with two additional testes using textures (a normal and a video texture).
https://www.khronos.org/registry/webgl/sdk/tests/conformance/extensions/angle-instanced-arrays.html?webglVersion=1&quiet=0&quick=1