PDA

View Full Version : displaying float buffers



sek
11-13-2003, 05:14 PM
Hi:

I have been using GL_NV_float_buffer for 32-bit multi-pass rendering on an FX5900 card. After doing several passes with off screen rendering targets, I then want to display the final pass. I just get a white screen when using the following code (where TexID is the last off screen rendering target bound to a GL_TEXTURE_2D):

glActiveTextureARB(GL_TEXTURE0_ARB);
glBindTexture(GL_TEXTURE_2D, TexID);
glEnable(GL_TEXTURE_2D);
glTexEnvf( GL_TEXTURE_ENV, GL_TEXTURE_ENV_MODE, GL_REPLACE );
glBegin(GL_TRIANGLE_STRIP);
glTexCoord2f(0,1); glVertex2f(-1,1);
glTexCoord2f(0,0); glVertex2f(-1,-1);
glTexCoord2f(1,1); glVertex2f(1,1);
glTexCoord2f(1,0); glVertex2f(1,-1);
glEnd();
glDisable(GL_TEXTURE_2D);
glutSwapBuffers();

Any help would be appreciated. I have read the GL_NV_fragment_program, GL_NV_float_buffer, WGL_ARB_render_texture, and WGL_ARB_pbuffer specifications, but am obviously missing something.

Thanks,

Sean.

[This message has been edited by sek (edited 11-13-2003).]

Ostsol
11-13-2003, 05:27 PM
http://oss.sgi.com/projects/ogl-sample/registry/NV/float_buffer.txt


Why must the NV_texture_rectangle extension be used in order to use floating-point texture maps?

RESOLVED: On many graphics hardware platforms, texture maps are stored using a special memory encodings designed to optimize rendering performance. In current hardware, conventional texture maps usually top out at 32 bits per texel. The logic required to encode and decode 128-bit texels (and frame buffer pixels) optimally is substantially more complex.

[This message has been edited by Ostsol (edited 11-13-2003).]

sek
11-14-2003, 07:58 AM
Thanks Ostsol:


Originally posted by Ostsol:
http://oss.sgi.com/projects/ogl-sample/registry/NV/float_buffer.txt

[This message has been edited by Ostsol (edited 11-13-2003).]


OK. I have tried using GL_TEXTURE_RECTANGLE_NV for my fpbuffer's texture target and I have made a fragment program active for the final pass as well as all the shading passes. Here is the new code for the final pass:

glBindProgramNV(GL_FRAGMENT_PROGRAM_NV, fpID_Display_RTT);
glEnable(GL_FRAGMENT_PROGRAM_NV);
glActiveTextureARB(GL_TEXTURE0_ARB);
glBindTexture(GL_TEXTURE_RECTANGLE_NV, TexID);
glBegin(GL_TRIANGLE_STRIP);
glTexCoord2f(0,1); glVertex2f(-1,1);
glTexCoord2f(0,0); glVertex2f(-1,-1);
glTexCoord2f(1,1); glVertex2f(1,1);
glTexCoord2f(1,0); glVertex2f(1,-1);
glEnd();
glDisable(GL_FRAGMENT_PROGRAM_NV);


where fpID_Display_RTT corresponds to:

!!FP1.0
TEX R0, f[TEX0], TEX0, 2D;
MOV o[COLR], R0;
END

However, I get a black screen.

[This message has been edited by sek (edited 11-14-2003).]

davepermen
11-14-2003, 08:23 AM
shouldn't it be TEX ..... RECT; instead of TEX ..... 2D; in the fp?

jra101
11-14-2003, 08:29 AM
Yes, you need to fetch from the rectangular texture like this:

TEX R0, f[TEX0], TEX0, RECT;

You also need to specify texture coordinates in the [0..textureWidth]x[0..textureHeight] range when using rectangular textures.

sek
11-14-2003, 10:13 AM
Thanks:


Yes, you need to fetch from the rectangular texture like this:

TEX R0, f[TEX0], TEX0, RECT;

OK. I have changed 2D to RECT.


You also need to specify texture coordinates in the [0..textureWidth]x[0..textureHeight] range when using rectangular textures.

I don't really get this. I understood that f[TEX0] was generated for all the fragments via interpolation and that I only had to put in the correct glTexCoord2f in range 0 to 1 before each glVertex call in the glBegin/End block. How do I get coordinates that are in [0..textureWidth]x[0..textureHeight] range? Do I just do

glBegin(GL_TRIANGLE_STRIP);
glTexCoord2f(0,textureHeight); glVertex2f(-1,1);
glTexCoord2f(0,0); glVertex2f(-1,-1);
glTexCoord2f(textureWidth,textureHeight); glVertex2f(1,1);
glTexCoord2f(textureWidth,0); glVertex2f(1,-1);
glEnd();

Thanks again.

jra101
11-14-2003, 10:24 AM
Yes, passing textureWidth and textureHeight in for your texture coordinates is what you are supposed to do.

From the GL_NV_texture_rectangle extension specification:




NPOTD textures are accessed by non-normalized texture coordinates.
So instead of thinking of the texture image lying in a [0..1]x[0..1]
range, the NPOTD texture image lies in a [0..w]x[0..h] range.

sek
11-14-2003, 10:35 AM
Originally posted by jra101:
Yes, passing textureWidth and textureHeight in for your texture coordinates is what you are supposed to do.

From the GL_NV_texture_rectangle extension specification:




NPOTD textures are accessed by non-normalized texture coordinates.
So instead of thinking of the texture image lying in a [0..1]x[0..1]
range, the NPOTD texture image lies in a [0..w]x[0..h] range.


Now, my textures are currently power of 2 (512x512), but I guess I would like to use NPOT textures in the future. Is the NPOT issue relevant my current problem?

Korval
11-14-2003, 11:14 AM
Now, my textures are currently power of 2 (512x512),

While it may happen to be a power-of-2 texture, the texture type you are using (texture_rectangle) doesn't require it. The texture_rectangle type does, however, require that rectangle textures pass in texture coordinates in denormalized form (ie, (0-width, 0-height), rather than [0.0-1.0]).

You can have your fragment program take the width and height as parameters and compute the denormalized texture coordinates for the fragment program.