JOGL Texture API, multiple texture units, & GLSL Samplers

OpenGL Development JOGL Development
#1

I am doing a number of things, which by themselves I can find examples for, but I am not sure how they fit together combined. Here is some psuedo code. Is this how to fit it all? Thanks in advance.

TextureData td0 = new TextureData(...); TextureData td1 = new TextureData(...); Texture tex0; Texture tex1; int loc0; int loc1;

later in GLEventListener init():
`tex0 = TextureIO.newTexture(td0);
tex0.enable();
tex1 = TextureIO.newTexture(td1);
tex1.enable();

compile & linking code for programObject

loc0 = gl.glGetUniformLocationARB(programObject, “db_table”);
loc1 = gl.glGetUniformLocationARB(programObject, “db_index”);`

in Display():
`glActiveTexture(GL.GL_TEXTURE0);
tex0.bind();
gl.glUniform1iARB(loc0, 0);

glActiveTexture(GL.GL_TEXTURE1);
tex1.bind();
gl.glUniform1iARB(loc1, 1);

gl.glUseProgramObjectARB(programObject);

gl.glBegin(GL.GL_QUADS);
…
gl.glEnd();`

In the shader itself:
`uniform sampler2D db_table;
uniform sampler2D db_index;

void main(){…}`

#2

I think you need the Texture.enable() calls after the glActiveTexture() calls in addition to the Texture.bind()s, so that you enable each of the texture units.

#3

I’m not 100% certain, but I’m fairly sure that you don’t need to call glEnable(GL_TEXTURE_nD) when using GLSL. It’s just a remnant from controlling the various units when using stuff like the original fixed function pipeline and arb_texture_env_combine and the likes.

#4

Oh and to the original poster, as far as I can see everything looks pretty good. The only suggestion I’d make is that if your texture units don’t change, set the uniform variables in the init() function.

#5

Thanks guys:

It is going to be days before I can get all the parts together to try this. Really needed to know I was on the right track. Will report back when up & running.

Chris, your 2 comments are exactly what I was thinking. I have even seen a GLSL example with all these glTexParameteri() calls, and I am wondering why? Same with the enable(). I thought my glUseProgramObjectARB() call was my enable(), but was afraid not to put at least 1 in init() anyway. If OpenGL is a state system, then I should be able to set my uniforms in init(), if they are not going to change.

But never actually building one of these before, I was kind of gun shy to try, when GLSL posts have this stuff.

#6

I hope you mean glTexEnv() calls. The glTexParameter() calls are going to stick around for a fair while longer, as texture addressing and filtering are two operations which specialized hardware give an order of magnitude or more speedup for.

Now hopefully GL 3.0 will clear up a lot of the confusion and ambiguity that a couple of decades of legacy has left in the spec.

#7

I did mean and see glTexParameteri() calls in a fragment GLSL example called “helloGPGPU for JOGL”. Strange URL, since japanese.

http://m-forest.ddo.jp/wiki_college/wiki.cgi?page=��������(GLSL)�Υ����ץ��ץ�������

I was only implying that I thought glTexParameteri() calls were un-neccessary & ignored (unless being use to set the textures priority) when a fragment shader, itself, directly addressed the texture with texture*D() calls. They can exist forever for fixed pipeline rendering for all I care, but it is confusing seeing examples like this.

My assumptions about un-neccessary & ignored are correct, right?

#8

After I hit the Post button, I thought I could have just commented them out and see what happens, so I did. With them a teapot is surrounded by loops with some visual garbage at the top shows, which I assumed was the real output. Comment them out and you just get white.

So, does it not work because the shader needs it, or is it because of this pointless teapot? My psuedo code example of a database table and index seem infinitely better as a GPGPU helloworld example.

#9 
drawable.getGL().glTexParameteri(GL.GL_TEXTURE_2D, GL.GL_TEXTURE_MIN_FILTER, GL.GL_NEAREST); 
drawable.getGL().glTexParameteri(GL.GL_TEXTURE_2D, GL.GL_TEXTURE_MAG_FILTER, GL.GL_NEAREST); 
drawable.getGL().glTexParameteri(GL.GL_TEXTURE_2D, GL.GL_TEXTURE_WRAP_S, GL.GL_CLAMP); 
drawable.getGL().glTexParameteri(GL.GL_TEXTURE_2D, GL.GL_TEXTURE_WRAP_T, GL.GL_CLAMP);

I guess you could actually state that they are unnecessary as you can duplicate the effects in the shader, though you wouldn’t want to. Additionally they are not ignored, with the possible exception of the priority (the driver and OS tend to think they know better than the app these days).

To duplicate setting the filter to GL_LINEAR you would have to make 4 textureD() calls, compute the weight and then perform the interpolation yourself. Where as setting glTexParameteri(GL.GL_TEXTURE_2D, GL.GL_TEXTURE_MIN_FILTER, GL.GL_LINEAR); sets-up the hardware to perform this operation for you in a single textureD() call and does all the weight computation and interpolation effectively for free. Things get even uglier when you start to take mipmapping (GL_LINEAR_MIPMAP_LINEAR) into account, the number of interpolations increases, and an lod is needed. And all of that only takes into account the arithmetic of doing texture filtering, the hardware also does some nifty things with caching and prefetching that makes doing those operations in the shader a not so terribly fantastic idea.

As for the wrap s and t modes, that might not cost much performance to do in the shader, but the hardware to implement that is also quite tiny and doesn’t cost much.