Fixed uniform shader reset
Keeping track of bounded textures for later reuse thus , fixing uniform shader reset
Resolves #7030
Changes:
Screenshots of the change:
Before:
https://github.com/user-attachments/assets/973a8c6d-7003-4bbc-ac5f-608823271261
After:
https://github.com/user-attachments/assets/9c11845b-1287-4bd1-b88d-449220014e07
PR Checklist
- [x]
npm run lintpasses - [ ] Inline documentation is included / updated
- [ ] Unit tests are included / updated
Hello @davepagurek . I am using a set data struckure to keep track of bounded textures. Please have a look at my PR. I also tested it on 5921 and it works as expected. There are some recordings of the changes in both cases.
I think we still want to be setting the bound texture back to an empty texture in most cases (like you mentioned in https://github.com/processing/p5.js/issues/7030#issuecomment-2309095086, this could just when a framebuffer is bound, but we can do it in all cases to be safe too.) With the current code, I made a copy of the test case from #5921 and it shows the same behaviour in Firefox on my mac where it just shows wireframes: https://editor.p5js.org/davepagurek/sketches/CMFeoUlHE
The problem is pretty platform- and driver-dependent, so it might be a harder one to test depending on your hardware. For me, Chrome displays that sketch just fine, but Firefox shows just wireframes and logs this warning:
WebGL warning: drawElementsInstanced: Texture level 0 would be read by TEXTURE_2D unit 0, but written by framebuffer attachment COLOR_ATTACHMENT0, which would be illegal feedback.
I think the challenge here will be to store two separate values on the uniform:
uniform.texture, the thing bound by WebGLuniform.userTexture(as an example name), the thing the user last tried to store there
Some logic to do that:
- set the texture back to an empty texture in
unbindTextures(maybe only if the texture was a framebuffer, or just doing it all the time is fine too) - Somehow distinguish between
setUniformfrom that unbind andsetUniformcalled by the user, and only when the user calls it, record the bound texture- The thing to store is the value we would be putting in
uniform.texture, which contains the texture data itself, not the texture index, which is just the slot it's being put into - By storing this as a property on the uniform itself, maybe as
uniform.userTexture, we don't need to store the slot because the uniform itself represents that - One way to distinguish those two is to make a different copy of the method to be used by
unbindTexturesso it can have different logic
- The thing to store is the value we would be putting in
- In
bindTextures, applyuniform.userTextureif it exists, oruniform.textureotherwise
uniform.userTexture (as an example name), the thing the user last tried to store there
Hi @davepagurek, it's been hard for me to get this value . Please for a few hints