Ok, I was reading the spec for the NV_texture_rectangle extension, and it says that you have to use a clamp mode (no repeat), and no mipmapping. What is the point of this extension?
Why not just use the glTexSubImage2D trick, you still can’t use repeat, and at least you can get mipmapping.
Not to rag on nVidia, but I don’t really seen the point of the extension…
Saves texture memory. Say you’re subimaging the contents of a non-pow2 sized window into a texture - your texture would have to be significantly bigger than the window…this extension means it doesn’t. Not sure why texture coordinates have to be in actual image dimensions, though (I haven’t thought the reasoning through).
lol, I forgot about that (been using a 64MB card too long 
)
[This message has been edited by NitroGL (edited 07-16-2002).]
Trust me, a 64 MB card is no solution for running out of texture memory. 128 is only a marginal improvement.
Anyway, I too am curious why they chose to use non-normalized texture coordinates for rectangular textures. Anyone know?
– Zeno
Anyway, I too am curious why they chose to use non-normalized texture coordinates for rectangular textures. Anyone know?
It’s probably something that anyone who knows can’t talk about. I would guess, however, that it could be that the way they implement rectangular textures is with some odd hardware hack. One of the limitations of the specific hack may simply be that one can not utilize normalized texture coordinates.
One thing to remember is that render-to-texture will usually be faster when rendering to a texture rectangle.
As for the unnormalized coordinates, there have been some numerical arguments made that I have never found extremely compelling one way or the other. I will say that this indexing scheme will turn out to be handy in the future.
Cass
Think of a texture as a ‘lookup table’ (or maybe, a framebuffer), eh cass?
[This message has been edited by knackered (edited 07-17-2002).]
NV_texture_rectangle can be good for rendering fonts for example. No mipmaps or repeating needed there.
Originally posted by cass:
[b]
As for the unnormalized coordinates, there have been some numerical arguments made that I have never found extremely compelling one way or the other. I will say that this indexing scheme will turn out to be handy in the future.
Cass
[/b]
Tex coordinates can be scaled easily, but why the weird restrictions like no mipmaping, clamp only and I think no anisotropic filtering either.
Besides, to prevent waste, tile textures!
V-man
Well, the no-mipmapping restriction is obvious: if I have a 201x201 texture, what is the next mipmap size? 100 or 101? Not only that, mipmaping works great and fast as-is because it is dividing numbers that are powers of 2 by 2 each time; this is just a bit-shift. Dividing a real float by 2 is a more expensive operation. The lack of anisotropic stems from the lack of mipmapping, most likely.
As for clamp-only, that is also a fairly reasonable restriction. Having to wrap denormalized texture coordinates may not be a simple task with nVidia hardware. The registers that know the width/height of the texture may not be easily/quickly accessible in the wrapping logic, since wrapping is done in normalized texcoords.
anysotropic filtering works i thought… and once again, its mostly for rendering onto a fullscreenquad, bind this again as texture and rerender it onto screen with some image post processing. and for this you need only a bilinear filter, if at all… (yes sure you can need more depending on what you do, but for the simple tasks…)
Originally posted by NitroGL:
[b]Ok, I was reading the spec for the NV_texture_rectangle extension, and it says that you have to use a clamp mode (no repeat), and no mipmapping. What is the point of this extension?
Why not just use the glTexSubImage2D trick, you still can’t use repeat, and at least you can get mipmapping.
Not to rag on nVidia, but I don’t really seen the point of the extension…[/b]
It’s handy for things like creating shadow maps that are matched to odd window sizes…
Originally posted by Korval:
As for clamp-only, that is also a fairly reasonable restriction. Having to wrap denormalized texture coordinates may not be a simple task with nVidia hardware. The registers that know the width/height of the texture may not be easily/quickly accessible in the wrapping logic, since wrapping is done in normalized texcoords.
I think the reason is much simpler. Doing a modulo x where x is a power of 2 is just bit masking. Doing it where x is general needs division…
[This message has been edited by Moshe Nissim (edited 07-17-2002).]
Wouldn’t it be possible to turn the textures into power of 2 internally if it’s a question of performance.
This extension would be much more interesting if it solved the old “must be power of 2” problem with no restrictions
Anyway, I’m sure nvidia considered things and had to make restrictions. Too bad …
V-man
[This message has been edited by V-man (edited 07-18-2002).]
I would guess that one difference between normal textures and rectangle textures is that rectangle textures aren’t swizzled so, (in general) have worse texel coherence. The cases of render to texture, and using the texture so that it’s orientation matches the screen would be notable exceptions.
I suppose it would be easy enough to test if this were so. Then again, I don’t work for a company that makes PC video graphics boards, so I’m not necessarily clued in on the nitty-gritty internal workings.
-Won