Hi,
I just searched through my extensions (Catalyst 4.6) and found GL_EXT_texture_rectangle. But it is not listed in the Extension Registry. I guess, its the same like GL_NV_texture_rectangle. But why is there no support for ARB_texture_non_power_of_two?
Bye Enrico
Yes, the EXT and the NV version are the same.
But npot-textures are much much harder to work with (for the hardware), so it needs dedicated hardware. Current hardware is not capable of handling them, so only the texture-rectangle extension is supported.
If you want to know the differences between rectangle and non-power-of-two textures, just read their specs. You will see, that rectangle textures were the first step to npot textures, but with a lot of limitations. ARB_non_power_of_two simply supports everything without limitations, but therefore only the Geforce 6 supports it yet.
Jan.
ARB_texture_non_power_of_two requires mipmap-support for npot textures which is currently only supported by GeForce series 6.
Only 6xxx Geforces? What about R4xx cards? Did ATi do nothing to add functionality to their cards this go-around?
I think the only new ATI feature is 3Dc compression (which is not exposed in OpenGL yet)
Originally posted by Korval:
Only 6xxx Geforces? What about R4xx cards? Did ATi do nothing to add functionality to their cards this go-around?
Except for the 3DC compression, yes.
But, well, as they said themselves, for gamers that doesn´t mean anything. They only need more speed, which the X800 delivers.
However, i am quite sure, that most developers will change to the Gf 6 in the near future, because of lots of new cool features. I will.
Jan.
And 3DC can theoretically be used on every DX9 hardware… So the only new on R4xx hardware is the lenght of the shaders (as far as i remember 1532 including vector ops, scalar ops and texture ops).
So the only new on R4xx hardware is the lenght of the shaders (as far as i remember 1532 including vector ops, scalar ops and texture ops).
That’s all well and good, but they forgot one thing: they still have the 4-indirection limitation. Odd is the shader indeed that uses 1532 opcodes, but still fits within the 4-indirection limits.
ATi seriously slacked off this generation. I can understand that adding looping in the fragment programs would have required rearchitecting the entire fragment pipeline (as I mentioned last year, btw). But not even bothering with “minor” features like NPOT, full float-texture support, and floating-point blending, all of which are not that difficult seems lazy. But they did have the time to apply their little 3Dc format. I would have preferred floathing-point blending instead.
Originally posted by sqrt[-1]:
I think the only new ATI feature is 3Dc compression (which is not exposed in OpenGL yet)
There’s a GL_ATI_texture_compression_3dc extension coming soon.
Originally posted by Corrail:
And 3DC can theoretically be used on every DX9 hardware…
No, 3Dc require hardware support that’s only available on the X800.
Originally posted by Humus:
[quote]Originally posted by Corrail:
And 3DC can theoretically be used on every DX9 hardware…
No, 3Dc require hardware support that’s only available on the X800.[/QUOTE]You can write your own algorithm with “compresses” a 3-channel normalized Normal-Map to a 2-channel Texture Map assuming the vector has a lenght of 1. This texture can be saved as a simple 2-channel texture map. In pixel shader you then have to recompute the 3rd component. That’s exactly what ATI 3Dc does, so why can’t this be done on every DX9 hardware?
I would have preferred floathing-point blending instead.
Indeed. Floating-point blending alone would be worth the price of admission. But even with the GF6 it’s bittersweet, since one can’t easily build an engine around it unless everyone (ATi) gets onboard. Without the extra features, ATi will need some scary speed up its sleeves.
Originally posted by Corrail:
You can write your own algorithm with “compresses” a 3-channel normalized Normal-Map to a 2-channel Texture Map assuming the vector has a lenght of 1. This texture can be saved as a simple 2-channel texture map. In pixel shader you then have to recompute the 3rd component. That’s exactly what ATI 3Dc does, so why can’t this be done on every DX9 hardware?
Of course you can compute the third component yourself with any format, but that’s not what 3Dc is. 3Dc is a texture compression format that packs two high-quality channels into 8bits. To decode that texture format you need hardware support.
If you have 8 bits of data, then you can look up that data in a 256-element texture, no? No matter what the quality?
And if you have two 8-bit channels, then you can map those to u,v, at the cost of one indirection, and look those up in one 256x256 texture.
In fact, going from two 8-bit values to one three-component normalized float value is a single texture look-up into a float texture with point filtering, or, if you want to avoid banding, you need another two instructions for the normalize, and you need to do four look-ups and filter yourself (because only GeForces do filtered float textures).
Anyone have a good link for reading up on 3Dc? I’ve only found marketing speak sofar, but would like to know the actual details.
Humus, are you trying to suggest that 3Dc makes the complete and total lack of any other significant advancement in their product line OK?
As Jwatte pointed out, if we really wanted some form of vector texture compression, we could build it into our fragment programs. I can’t build floating-point framebuffer blending into a fragment program; I have to device a gigantic (and slow) system to get around that lack of functionaity.
Did ATi at least add PCF lookups for shadow textures? If they added 3Dc and not a truly useful feature like PCF, screw them; I’m buying nVidia.
Originally posted by jwatte:
[b]If you have 8 bits of data, then you can look up that data in a 256-element texture, no? No matter what the quality?
And if you have two 8-bit channels, then you can map those to u,v, at the cost of one indirection, and look those up in one 256x256 texture.
In fact, going from two 8-bit values to one three-component normalized float value is a single texture look-up into a float texture with point filtering, or, if you want to avoid banding, you need another two instructions for the normalize, and you need to do four look-ups and filter yourself (because only GeForces do filtered float textures).
Anyone have a good link for reading up on 3Dc? I’ve only found marketing speak sofar, but would like to know the actual details.[/b]
The point is that it compresses a normal map. Very much like DXTC compression. 3Dc is useful, just like DXTC is useful. DXTC isn’t turned useless just because you can use RGBA8 anyway. 3Dc reduces storage space and bandwidth needs, so it will be faster than any other trick.
There are some technical details in this white paper:
http://www.ati.com/products/radeonx800/3DcWhitePaper.pdf
Or to make it short, it’s like DXT5 alpha compression, but twice to get two independent channels.
Korval,
I’m merely correcting the info on what 3Dc is and what it’s not.
OK, so you get a pair of 4-bit palettes per block, instead of a single 8-bit palette for a whole texture. For low-frequency normal maps, I think that’ll work swell.
However, I really encourage you to look into two separate normal map representations that also give you the same storage savings:
What I suggested above: use a palette of 256 normals, stored in a 256x1 RGBA texture; look up in that texture using a single channel (A8) texture. A lot of games ship normal maps like this, because with the right palette, it can look really good!
Store a height map, instead of a normal map, and derive the normal using finite differences. This has the nice feature that it can double as fake displacement map (for parallax mapping), and you can compose/add these really easily.
The white paper you point at claims that storing bump maps is inferior in detail to storing normal maps, but I argue that, with the right shader, that’s not true – in fact, the normal map was probably generated from a bump map (explicit, or implicitly created by mesh differences).
Well, even if you can get down to the same storage space you’ll still not get the same performance since you’ll have to do two texture look-ups, of which one is a dependent texture look-up. Plus, that way you’ll get worse quality. It would be comparable to using a normalizing cubemap, as opposed to normalizing with math, since the texture is limited to 8bits.