three.js: Renderer state.reset() no longer resets attributes

Unfortunately we need to be careful to add this type of API as written in the above. So I’d like to suggest making your fork for now and revisiting in the core if we get the same feature request more.

I agree with @Mugen87. The Renderer inside (WebGL resource management) is complex. Exposing an API which affects internal WebGL resources can make it harder to maintain. Once we expose an API, we should keep the API unchanged as much as possible, then I think there my be a chance that exposing such an API can block the change (optimization) of the renderer inside.

But, on the other hand, I know we sometimes have requests from users that they want to finely control WebGL resources by themselves. So I think it might be acceptable if the change is very simple and easy, and many users want this feature.

To me, it’s okay if a reset operation potentially takes some time.

Yeah, I think so, too. But just in case I want to hear @cgauld 's comment because I’m not sure the use case.

Hi, I’d like to vote for resetting the binding state since I also encountered an issue with binding state not being reset after an upgrade to three.js 123.

In Potree, I’m rendering point clouds with custom WebGL code using the same context as three.js. Previously, renderer.state.reset();did the trick. Now, I also have to call bindingStates.reset() but the main issue for me is that bindingStates is not accessible without modifying the three.js source code.

As a workaround, I’ve added this.bindingStates = bindingStates; to the WebGLRenderer so that I can use renderer.bindingStates.reset().

var xr = new WebXRManager(_this, _gl);
this.xr = xr; // shadow map

this.bindingStates = bindingStates;

var shadowMap = new WebGLShadowMap(_this, objects, capabilities.maxTextureSize);
this.shadowMap = shadowMap; // API

Would it be okay to make bindingStates publicly accessible like that? It’s still up to me to make sure that whatever I do with custom WebGL code doesn’t break three.js, but at least it would allow me to do custom stuff.

Edit: Btw, a workaround that doesn’t require changes to three.js is to render a dummy scene with at least one object, just to make sure that the vertex array object state gets reset. This requires that the object is actually renderer to work, i.e., no frustum culling.

// render dummy scene to reset vertex array object state
let dummyScene = new THREE.Scene();
let geometry = new THREE.SphereGeometry(0.0001, 2, 2);
let mesh = new THREE.Mesh(geometry, new THREE.MeshBasicMaterial());
dummyScene.add(mesh);
renderer.render(dummyScene, camera1);

// render actual scene
renderer.render(scene, camera2);

// do custom WebGL rendering into same three.js context

Indeed - I agree 🙂 We’d only expose it on WebGLRenderer/WebGL1Renderer so there’s no expectation it would be a concept that applied to or was exposed by other renderers.