GLSL and non-power-of-two textures

Started by
8 comments, last by _the_phantom_ 19 years ago
Does anyone know how I can get non-power-of-two textures to work inside of GLSL? The sampler2D uniform and texture2D function are crashing when I'm sending in a rectangular texture. I've been doing some searching, and it seems like its 'not quite' supported yet, but I'm hoping I'm wrong about that.
Advertisement
sampler2DRect, texture2DRect
there is extension for non-power-of-two texturers if this extension doesn't supportted then try to edit your resize it to power-of-two even if you increase the size like
your old size 30*54
after the resize 32*64
i hope you get it :)
bye
Ya I discovered I was getting compiler errors with sampler2DRect and texture2DRect because I was using an ATI card. Not sure if the newest drivers fix that or not, but the ones on the computer I was using didn't recognize those commands. Just an FYI incase anyone else encounters it :)


The Cat5.3's might work with it, as the arb_texture_non_power_of_two extension is sort of supported (you wont see it in the extension string as the current generations of hardware cant fully support the extension)
I don't remember exactly but the OpenGL 2.0 or the OpenGL SHading Language specification has information regarding the rectangular textures. It also mentions the keywords they have reserved for rectangular textures for future use. Since ATI tries to promote GLSL better than NVIDIA, I am expecting they should have implemented it by now. Try some of these:-

texture2DRECT, sampler2DRECT
texRECT, samplerRECT
tex2DRECT, sampler2DRECT

Just different combinations or just try to find it in the specification.
There is a 3 kind of 2d textures:
- classic POT (power of two)
- RECT
- NPOT

Difference is:
POT - using normalized texture coordinates (0..1, 0..1)
In GLSL access via sampler2D, texture2D, texture2dProj
Bind as GL_TEXTURE2D

RECT - using unnormalized texture coordinates (0..w, 0..h)
In GLSL access via sampler2DRect, texture2DRect
Bind as GL_TEXTURE_RECTANGLE_ARB

NPOT - using normalized texture coordinates (0..1, 0..1)
In GLSL access via sampler2D, texture2D, texture2dProj
Bind as GL_TEXTURE2D


You must take care how you bind rectangular texture (as rect or as GL_TEXTURE_2D)

yooyo
NVIDIA's 60 series drivers and later implement texture2DRect and samplerRECT in GLSL. However these assume that the texture is created using GL_NV_texture_rectangle (or GL_ARB_texture_rectangle), not GL_ARB_texture_non_power_of_two. The main difference between these texture types is that a rectangular texture is addressed with non-normalized texture coordinates, i.e. s and t are in [0, WIDTH] and [0, HEIGHT], respectively, wheras non-power-of-two textures use normalized texture coordinates.

I'm not sure what, if any, solution is available on ATI hardware.
EDIT: I didn't see SlayerDave's post before I made this one. I believe he is correct, and the last I checked, ATI didn't support rectangular textures, and nVidia didn't support non-power-of-two textures.

Non-power-of-two features aren't supported as well on ATI cards as they do on nVidia, and they definitely don't work the same way. It's been a number of months since I worked on it, and I don't have the code in front of me, but I believe that GL_TEXTURE_RECTANGLE_ARB is required on nVidia cards but doesn't work on ATI cards (I believe you use GL_TEXTURE_2D on ATI). ATI cards don't support rectangular floating-point render targets, but nVidia cards do. I also had different issues in Cg than I had in GLSL. There may have even been a difference in how texture coordinates are handled, but I don't remember.

I should be more specific about the cards. I was testing a GeForce FX card and a Radeon 9600 card. I imagine the Radeon X series and GeForce 6 series support more options in this area, and things may change with driver updates. I have a project I did in GLSL and Cg using rectangular textures, and I remember going to a lot of trouble to get it working on both cards. Since I don't have the code in front of me, I can't remember all of the specifics. If you can't get it working by this evening, let me know which card you're using, and I'll try to find time to check my code tonight to see if I can shed some light on it.
As I said above, the NPOT extension is kinda supported on ATI hardware, it has some limits due to the hardware of the current generations.

this thread has some infomation on the kinda limits you can expect (Humus' replies)

This topic is closed to new replies.

Advertisement