In version 118+, Three.js stops rendering when it shares a WebGL context with Pixi.js. In versions 117.1 and below, it works correctly.
Specifically, doing
threeRenderer.state.reset();
threeRenderer.render(myScene, myCamera);
pixiRenderer.reset();
is enough to cause the three.js renderer to not render anything on subsequent render attempts (although it clears the canvas correctly).
Codepen: https://codepen.io/andrewstart/pen/XWdybMw?editors=0010 (in settings, change the version of three.js to 117.1 to see a 3D ball correctly rendering behind the bunnies). This example doesn't seem to log any warnings, but in my actual project rendering a SphereBufferGeometry results in GL_INVALID_OPERATION: No element array buffer and no pointer.
Since r118 three.js uses a WebGL 2 rendering context by default. I could imagine that this breaks your usage pattern. You should be able to avoid a breakage by using WebGL1Renderer.
BTW: From my point of view, it is not recommended to share a WebGL context across different engines. three.js caches WebGL state information. If a cached information is changed by a different renderer, the final behavior is undefined.
Yes, it appears that while Pixi also uses WebGL2 by default, it doesn't correctly handle being given a WebGL 2 context and assumes that it is WebGL 1. I will dig on that a bit.
In regards to cached state information, doesn't threeRenderer.state.reset(); specifically clear that cached state (at the cost of some performance)?
In regards to cached state information, doesn't threeRenderer.state.reset(); specifically clear that cached state (at the cost of some performance)?
Yes, that's true. Although it's a bit unfortunate that this method is public accessible....
Hi @andrewstart,
Did you find out how to mix three.js with pixi.js in >= r118
Nope, sticking with 117.1
I have updated to r121 and do now use 2 canvas instead of sharing one. Works even better than before. _I'm using Phaser, not Pixi._
Most helpful comment
Nope, sticking with 117.1