Shader texture2D issue

hey there,

i’m working on a shader that uses a lot of customizations and combinations,

all these different effects require textures to help stylize them, and ive ran into an error: after a bunch of texture2D() calls something breaks behind the scenes,
i’m not sure what exactly happens but i’ve made a minimum reproduction project here, you just have to enable at least 7(seven) additional texture2d calls in the frag shader code, it’s pretty straight forward

you will see that with less than 7 additional calls to different textures into memory, the effect plays out as it should a distorted wiggly effect across the whole image, with more than 7 additional cans calls, the effect breaks and looks more like a watery outline

after some testing -

the broken effect is the same as if the input texture is missing, so that’s probably what’s happening is the DistortTex gets removed from memory but why this texture specifically?

order of operations doesn’t seem to matter as moving around the additional call to before/after/random doesn’t change the DistortTex breaking with 7 additional calls
@Simeon @John

i can try to move forward by keeping track of the shaders calls, but if you can take a look and fix this or at least let me know what the exact behaviors is that would be really helpful

It looks like we had the maximum texture count in shaders set to 7. I’ll update this to 16 since that’s what modern hardware supports

awesome thank you! this will help out a lot to have a higher threshold

@John do you know if there’s a maximum texture size? trying to see what my limits are and if i can do something like load in a texture atlas with multiple textures in case i need more than 16 instances

This should give you a rough idea:

So basically between 8k and 16k depending on the device

hi @John i’ve recently been seeing this issue again, have the latest Codea beta builds changed this texture limit again?

also just a random question but do bools get turned into vec4s on the gpu side?

I’ll have to check if the limit got reverted somehow.

As for bools they technically take up the same amount of space as a vec4s because of memory alignment on GPUs

thanks for the feedback, if you don’t see any difference on your side it might be on my end as i was playing around with changing all uniforms to different types, it seems like it’s better to use a combined vec with one of them being a representation for the bool - e.g.

uniform float TwistAmount
uniform float TwistRadius
uniform bool TwistLeft


uniform vec3 Twist // amount, radius, left

Yeah it’s more efficient to pack everything into blocks of vec4’s if you want to reduce wasted space in uniforms (plus its less work for codea to upload them each time you draw something)

1 Like