You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
All of the above is done in the constructor of the containing class, so all parts are done before first usage.
The texture is bound to two custom shaders:
here's what that looks like in r144:
Nothing special there really, but perhaps important is the fact that these two use different ShaderMaterials, because if I comment out uniform assignment for one of the shaders (the one used for central element), the error goes away:
The console is clean too.
My best guess is that when textures.setTexture2D( dstTexture, 0 ); is being called inside copyTextureToTexture, it binds / activates the wrong texture. Why? - no idea.
Version
r167.1
Device
Desktop
Browser
Chrome
OS
Windows
The text was updated successfully, but these errors were encountered:
@Usnul I was so excited about your virtual texture project that I got to work and also developed a system like that. I started this on r160 and it works fine. Thanks for the inspiration
Therefore copyTextureToTexture and DataTexture work. Of course I can only speak for r160 upwards, as I had never used copyTextureToTexture in three.js before r160. Your DataTexture looks completely normal 🤔 strange that it doesn't work.
P.S. I tried using your DataTexture setting in codePen, i.e. the filters without THREE. to use. Then it doesn't work anymore. Maybe that's the cause. This is how the codePen example works again:
Description
I was upgrading my virtual texture system to the latest revision up from r136, going directly to current version (r167.1) yielded a curious error:
WebGL: INVALID_OPERATION: texSubImage2D: no texture bound to target GL_INVALID_OPERATION: Invalid combination of format, type and internalFormat.
I looked deeper and found that the problem was coming from
copyTextureToTexture
:So I started looking for the point where the breakage occurs, r144 is fine, r145 breaks.
Looking through the patch notes yield little of interest except for:
and possibly
#24637
Here's the actual code that sets up the offending texture:
All of the above is done in the constructor of the containing class, so all parts are done before first usage.
The texture is bound to two custom shaders:
here's what that looks like in r144:
Nothing special there really, but perhaps important is the fact that these two use different
ShaderMaterial
s, because if I comment out uniform assignment for one of the shaders (the one used for central element), the error goes away:The console is clean too.
My best guess is that when
textures.setTexture2D( dstTexture, 0 );
is being called insidecopyTextureToTexture
, it binds / activates the wrong texture. Why? - no idea.Version
r167.1
Device
Desktop
Browser
Chrome
OS
Windows
The text was updated successfully, but these errors were encountered: