I notice you can use GL_UNSIGNED_SHORT instead of GL_FLOAT in glTexCoordPointer.
Does this mean that if I know my texture width and height ahead of time, rather than putting in 0.5, 0.5, for UV coordinates, I can instead put the actual pixel offset like 256, 256 for a 512*512 texture?
This would save a lot of room considering a float is 4 bytes, and I could get away with 2 bytes each (or even 1 byte each if the texture width and height was 256 pixels.)
I tried it and it didn’t seem to work. I was just wondering if it was something I did, or if it is not possible.
Ultimately, I would love to have a single array of texture vertices, and be able to index them with an array like you can with regular vertices.
Actually, from what I understand, the way unsigned short works is that 0-65535 is equivalent to the range 0 to 1 in floats. So, if your texture coordinate in floats was 0.5, then your new one should be 32767. Basically, multiply your texture coordinates by 65535 and round to the nearest ushort. This makes texture wrapping rather difficult.
Um, I guess. It’s not good if you wanted the texture coordinate to hit the center of a pixel. This comes up on occasion, mostly with sprites.
I’d suggest, from a performance vs. quality standpoint, to stick with floats unless you start hitting vertex transfer bandwidth bottlenecks. Then, switch to VAR, display lists, or whatever else can enhance vertex transfer before dropping to unsigned shorts or lower.
Actually, you would expect it to work the way Korval describes, but from my own experience it doesn’t appear it works that way.
From my testing it appears that using integers 0-1 still maps into the equivalent float range 0-1. I’m not quite sure why it works this way. You wouldn’t think that it would. I just tested again and came up with the same results. I’m using the latest official Detonator drivers from nVidia.
So my question then is, how are you supposed to get fractional values using an int or short? It still works to do repeating textures if you don’t need fractional texcoords anywhere, but I’d stick with floats for most cases.
This section talks about how some quantities are range mapped to float, but others aren’t. Texture coordinates don’t appear to be. My suggestion would be to use the texture matrix if you need to remap the range.
I had actually checked the specs after noting that behavior but I guess I was explicitly looking for something that said if it was or wasn’t clamped to a specific range, not the absence of it saying that it was.
When you think about it from one perspective, it doesn’t make much sense for it to get clamped, actually. If you were using a short for example and it got clamped between 0 and the max value of a short, there would be no real way to specify repeating coordinates other than to use the texture matrix. As it is there is no good way to do fractional coordinates without using the texture matrix, so I guess either way there is a tradeoff.
Oh well… I still prefer to use floats for all my texcoords. It was just an interesting behavior that I noted at one time.
Sorry guys. I checked the specs but couldn’t make heads or tails from them. Heh heh. I am still kinda new to all this, and all I am looking for is an example or explanation on what the array data needs to look like when using GL_SHORT or GL_BYTE.
So is the short a smaller version of a float?
I just want to be able to use something smaller than a float to specify my texture coordinates. My object files are huge, and I really need to shrink them down some.
I am using non-repeating textures, so it wouldn’t have even concerned me if they were clamped. =)
Where width and height are the size of your image. That should, let you specify texture coordinates based on the actual image coordinates, though I haven’t tested it myself.
Where width and height are the size of your image. That should, let you specify texture coordinates based on the actual image coordinates, though I haven’t tested it myself. [/b]
You might consider using
glScalef(1./width,1/height,1.0), should actually work a little better
0.0 to 1.0 does not map to the leftmost pixel and the rightmost pixel. They both map to the edge between the leftmost pixel and the rightmost pixel (assuming repeat here). For pixel-to-pixel correctness, you want the leftmost pixel at (0.0+(1.0/texWidth)/2) and the rightmost pixel at (1.0-(1.0/texWidth)/2). That is, at the nearest mipmap level; once you start mip mapping out you will need to move progressively further in from the texture edge. It’s a royal pain (especially for whomever makes the art).
