Problem using ofShader with textures

I’m having problems using the ofShader addon (using the latest from Basically i just get a black screen.

My code is below, am I missing something?

void testApp::setup(){  
	shader.printActiveUniforms();	// can confirm "texture"   
void testApp::draw() {  
	shader.setUniform("texture", 0);  
	glColor3f(1, 1, 1);  
	pic.draw(0, 0);  

and these are my super basic shaders (which work as I’ve tested them elsewhere)

// VERTEX:  
varying vec2 textureCoords;  
void main() {  
	gl_Position = gl_ModelViewProjectionMatrix * gl_Vertex;  
	gl_FrontColor = gl_Color;  
	textureCoords = vec2(gl_MultiTexCoord0);  
varying vec2 textureCoords;  
uniform sampler2D texture;  
void main() {  
	gl_FragColor = gl_Color * texture2D(texture, textureCoords);  

Have you tried this?

To get basic texturing using GLSL in OF 0.04 you have to do the following:

Comment out all references to code that would normally reference GLEE_ARB_texture_rectangle and also make sure that the default “textureTarget” is GL_TEXTURE_2D.

Then you need load your shader and activate it in setup() and all should work fine.

I wrote that a while back in this thread:…-ght=shader
Maybe it still applies…

Hey Pierre, that worked!

Sparked by this interesting hack I did some research and came to the (obvious in restrospect) answer that you can use GL_TEXTURE_RECTANGLE_ARB textures with GLSL as long as in the shader the texture is defined as sampler2DRect instead of sampler2D, and you sample it with texture2DRect instead of texture2D (though this is on my ATI, god knows whatll happen on other cards).

So this brings up the sensitive issue of whether or not to write 2 sets of shaders, one for RECT one for 2D and use the correct shader depending on whatever the ofImage is using… or just hack ofTexture to always use TEXTURE_2D… I think I"ll do the latter for now :stuck_out_tongue: thanks for the tip!

Yeah I think in that thread I mentioned sampler2DRect…

Honestly I don’t mind where the fix takes place…as long as there is a fix in the future, because that’s a real stumbling point for people trying shaders and textures for the first time!

Yea it is a pretty ugly topic, it all depends on what your hardware supports as well!. i think for non power of two textures ARB_texture_non_power_of_two (NPOT) would be ideal. It seems they are bound with TEXTURE_2D, the texture coordinates are normalized 0…1 and support nonpower of two textures! sounds too good to be true!

I agree - this is a huge stumbling block – in 0.06, you will be able to manually specify the texture target, so you can know your code will work (just use the gaurenteed format) and you could, as you say, use the GLEE logic (that’s in OF) to load one of two shaders.

will take a look at that arb extension. I wonder how common it is compared to what we are using - we would like to be supporting as many people as possible for non pow 2 textures, since the pow2 textures have some artifacts and issues making them an unfriendly choice.

I’m sorry that’s tripped you up and hopefully we can support this more moving forward.

take care!!

Hey Zach that sounds great. Looking back at the situation the problem really came about from me being stupid, not a problem with OF. Trying to use sampler2D shader with TEXTURE_RECT texture is never gonna work :oops: but having control of the texture target in OF would be ace… looking forward to 006! (any ball park estimates on when we can expect it?)

I think this has been mentioned before, but in response to memo’s remark about npot2 textures having [0, 1] coordinate range, it’s possible to do the same with rectangular textures by scaling the GL_TEXTURE_MATRIX appropriately. It is definitely a huge issue that texture2D and texture2DRect require writing duplicate shader code, but you can at least get them all into a uniform coordinate system by manipulating the texture matrix so all it is is a copy and paste operation and find/replace as opposed to having to redo some of the maths for tex coords.

(any ball park estimates on when we can expect it?)

always takes way longer then we;d like. We worked crazy hard for pre-ars, but didn’t make it, and also for pre-japan workshop, same thing. After this show theo and I have been working on now (which opens tomorrow), we will be working full time on the release so it should be relatively soon.

take care!!

As of now, what’s the best approach to this? Seeing how many of us faced the same issue, are you all guys working on a custom-hacked version of OF? I love how easy I have it now to draw on FBO’s and run shaders on them, but I don’t want to see all my stuff breaking on the next OF release.

For now I’m running on a modified ofxFBOTexture and ofxTexture so that it doesn’t use GL_TEXTURE_RECTANGLE_ARB.

Is there a way to the GL_TEXTURE_RECTANGLE_ARB flexible enough to allow shaders to work nicely without adding extra confusion to users who don’t need/want shaders?

Hey, you can use ofDisableArbTex(); that makes any texture allocated after the call be GL_TEXTURE_2D.

yep but that flag isn’t checked in ofxFBOTexture allocate()…

void ofxFBOTexture::allocate(int w, int h, bool autoClear) {  
        _isActive = false;  
        texData.width = w;  
        texData.height = h;  
    if (GLEE_ARB_texture_rectangle){  
        texData.tex_w = w;  
        texData.tex_h = h;  
        texData.textureTarget = GL_TEXTURE_RECTANGLE_ARB;  
    } else {  
        texData.tex_w = ofNextPow2(w);  
        texData.tex_h = ofNextPow2(h);  

it uses GL_TEXTURE_RECTANGLE_ARB regardless; do I not have the latest version? I’m using the one in

It would make sense to me to check for that flag ( ofGetUsingArbTex() ) to decide which texturing mode to use here too, right?