I’ve read through a lot of threads and there seems to be a lot of conflicting information (and a lot of it very old), so I am trying to understand what I might be doing wrong.
I took the 2D GL example and started expanding on it, which uses:
I also understand that this is limited in what functionality it has. I was under the impression that given “when” this gets rendered, that a lambda function could be defined and attached to onShaderActivated so that I could do uniform assignments at the appropriate place.
Inside paint() this is getting called:
p = shader->getProgram(g.getInternalContext());
shader->onShaderActivated = (juce::OpenGLShaderProgram& p)
printf("LAMBDA PROGRAM ID: %d\n",p.getProgramID());
printf("LAMBDA TEX: %d\n",p.getUniformIDFromName("tex"));
shader->fillRect (g.getInternalContext(), getLocalBounds());
and the p.getUniformIDFromName(“tex”) is always returning -1
In the fragment shader, I added:
"uniform sampler2D tex;\n"
Not sure what else to do here.
This is classic GLSL behavior. If a uniform is unused, it will get optimized out. The glGetUniformLocation will then report -1 as location.
This function returns -1 if name does not correspond to an active uniform variable in program
Seems like the CustomShader class was never intended to be used with textures. Only fills that specifically use the predetermed fragmen shader layout. Unless you want to restore everything manually, which is a bit hacky since there is no onShaderDeactivated, or another way to easily intercept after the fillRect was drawn.
Since you probably want to glActiveTextureUnit and glBind to your custom texture, you have to ensure that after the CustomShader is drawn, the values are reset. You can query them beforehand with glGet*()
How to enforce the shader drawing? Probably glFlush after the fillRect (which is kinda bad), then immediately restore them before issuing other calls to the juce::Graphics context.
That was it! Thank you! I guess what is weird is that I have set uniforms before on other architecture when the values weren’t used and I am not sure now what was happening. On iOS if a -1 gets passed into the uniform set command it crashes. I’m guessing on other implementations that does not happen. (A perfect example is the raspberry pi). I’ll have to experiment and see wha is going on there because I am curious.
Yeah, it’s too bad there isn’t a onShaderDeactivated so we could just wrap around what we want it to do. Right now I am just not clearing it after. I’ll likely just use glFlush for now as I play around with this code.
Is there a place t make a request for something like “onShaderDeactivated”? I guess I could dig through the source and see what it is doing when it calls that.