Sign in to follow this  
l0calh05t

Difference between non-power-of two and rectangular textures

Recommended Posts

l0calh05t    1796
Ok, what is the real difference between non-power-of-two and rectangular textures? Only that rectangular textures use non-normalized texture coordinates (which doesn't seem particularly useful)? And where would one be used instead of the other? I'm asking because I am currently using non-power-of-two textures for my screen-size offscreen buffers, and I'm wondering why everyone seems to be using rectangular textures instead.

Share this post


Link to post
Share on other sites
V-man    813
I think Geforce FX series doesn't support NPOT at all so you have to use RECT.
Radeon 9500 and up, Geforce 6100 and up support both but with various abilities.
For example, Radeon 9500 does not do mipmaps, border texels, you have to use CLAMP_TO_EDGE.

In principle, with GL 2.0, you are suppose to have full support for NPOT, including support for 3D and cubemap.

Sounds like you can use NPOT for your needs.

Share this post


Link to post
Share on other sites
Trenki    345
RECT textures don't use normalized coordinates and there are no border texels and mipmaps with them. They are supported on older hardware before NPOT textues were introduced.

NPOT texutes require normalized texture coordinates and the specification also requires mipmaps for these textures. Some hardware might not fully support this texture type in hardware even though it reports to support GL 2.0. This is the case for my Radeon X800 XT which only supports NPOT textures with some limitations, namely no mipmaps, no border texels, CLAMP_TO_EDGE.

Share this post


Link to post
Share on other sites
l0calh05t    1796
So for backwards compatibility Rectangular textures would be reccomended? Considering that I need no borders, no wrapping and probably also no mipmaps (except perhaps for quicker blurring...) I might switch to rectangular textures. OTOH, what I'm currently writing will probably not run correctly on anything older than Geforce 7300 (My current card is a Geforce 8600M), so it's probably a waste of time...

Share this post


Link to post
Share on other sites
Krohm    5030
Quote:
Original post by l0calh05t
So for backwards compatibility Rectangular textures would be reccomended?
Yes, it's the only good reason to use them but unluckly, it's a very important reason.

Share this post


Link to post
Share on other sites
l0calh05t    1796
In light of the fact that a very, very basic test (a sphere, a box, 3 directional lights) only ran at ~20fps on a friends laptop with geforce 7600 go. I see the importance of that reason fading quickly... but it should be only ~10 lines of code to change, so.. why not?

Share this post


Link to post
Share on other sites
l0calh05t    1796
Uh, that was on a friend's computer. And yeah 20 fps *is* slow, but I think it may be because of slow video memory. On my geforce 8600M I got ~130fps at a much higher resolution. (And *my* drivers aren't exactly new, dell doesn't update their drivers particularly often)

Share this post


Link to post
Share on other sites
Krohm    5030
Quote:
Original post by l0calh05t
...with geforce 7600 go. I see the importance of that reason fading quickly...
Believe it or not, 7600 is still to be considered pretty high-end. Especially for people with ATi, full NPOTD cannot be assumed to be widespread. Alot of people is still running PS2.0 hardware an this tipically employs RECT. I wouldn't say dropping RECT is a good idea for now, unless you run exclusively on last-gen ATi or sort-of-common NV.
Quote:
Original post by l0calh05t
but it should be only ~10 lines of code to change, so.. why not?
Unluckly, it doesn't just take to change the binding token. You must also scale TexCoords accordingly (just say you late-bind textures and you get the idea), prepare to have two code paths, change your shader source if you use shaders, get ready for another texture target priority if you don't... it may be about 10 lines for the techdemos on the net but complex apps will show an additional inherent level of complexity.

RECT is a real pain to support, especially if you let your users do their content AND you want them to be shader-enabled. Its use is pratically limited to managing your framebuffers. I would have dropped it the same day ARB_npot were annunced. I wish you the time has come to simply assume ARB_npot: it's much easier and way more orthogonal but I fear this to be still too much.


Share this post


Link to post
Share on other sites
l0calh05t    1796
Hm... since I don't really use anything RECT textures don't provide (I only use the NPOT textures for Framebuffers, I was planning on sticking to normal pow2 textures for pretty much everything else), wouldn't it suffice to simply switch to them (instead of NPOT)? In that case multiple codepaths would not be needed. (Although that is assuming that cards supporting NPOT textures *continue* to support RECT textures...)

Share this post


Link to post
Share on other sites
nb    172
i don't think anyone has touched on this, and perhaps this isn't what you were originally asking... but memory serving ^2 textures was originally to do with it lending itself to really simple continuous texturing code e.g. trying to access an x position of 300 in a texture only 256 pixels wide lends itself to simply ignoring a byte overflow and reading the resulting byte value (should be 45? with the overflow register set?).

Share this post


Link to post
Share on other sites
Krohm    5030
Quote:
Original post by l0calh05t
Hm... since I don't really use anything RECT textures don't provide (I only use the NPOT textures for Framebuffers, I was planning on sticking to normal pow2 textures for pretty much everything else)
That's a good idea. ;-)
Quote:
Original post by l0calh05t
wouldn't it suffice to simply switch to them (instead of NPOT)? In that case multiple codepaths would not be needed.
Yes, it would be just a few switches. It would be much easier because the machinery would be much more compact and restricted. Managing internal machinery is way different from allowing people put in arbitrary data. RECT is not so bad here.
Quote:
Original post by nb
i don't think anyone has touched on this, and perhaps this isn't what you were originally asking... but memory serving ^2 textures was originally to do with it lending itself to really simple continuous texturing code e.g. trying to access an x position of 300 in a texture only 256 pixels wide lends itself to simply ignoring a byte overflow and reading the resulting byte value (should be 45? with the overflow register set?).
This could have been a good reason 10 (or maybe 5) years ago but it isn't quite the reason. I'm not sure of whatever you mean to obtain by "wrapping" this way.

Share this post


Link to post
Share on other sites
l0calh05t    1796
I think nb means the normal texture wrapping (TexCoord (3.2,1.5)~(0.2,0.5)), but considering that pretty much everything is processed as floats nowadays that Argument isn't valid anymore. Unless maybe you are writing a software rasterizer and using integer texcoords... (yuck... no filtering)

Share this post


Link to post
Share on other sites
nb    172
yer texture wrapping e.g. a small square texture for a floor that gets repeated over and over each draw to actually cover the entire triangle / quad etc. if my math is right then any time you try to access a texture position that is out of the bounds of it's actual size then as long as it's a power of 2 sized texture then all you need to do is set the higher bits that represent above the texture size to zero and you instantly have the correct co-ord of where you need to look on the texture to keep the pattern repeating properly. another math example like my 256 width texture is say a 64 (0-63) wide texture... as you plod along reading the texture at whatever position then as soon as you try to ask for position 64 then as long as you have been setting the 2 leftmost bits to 0 then the position will automatically wrap to the correct position of 0 on the texture which is clearly what you want. same for when you ask to read position 65 it will resolve to a value of 1 etc etc.

i probably make no sense, and yes i'm sure nowadays it's irrelevant unless you are writing your own software texturing procedure, but my understanding is that that's how it all started because it lent itself to more efficient code both in terms of lines of code and processing time (doing one simple AND is faster than having to potentially repeatedly do minus operations for the cpu).

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this