Strange Radeons

Hello

I’m having some problems with cubemapping on radeon cards (8500).
When I use the 0 cubemap (when you bind with 0 as texture object) I seem to get black borders at the edges of the cubemap faces.
You can see it in action at http://studwww.rug.ac.be/~cholleme/lines.jpg
I’m using GL_CLAMP as GL_TEXTURE_WRAP_(S/T) param.
“The” problem now is that it looks perfectly normal on NVIDIA cards but all radeon users seem to experience this.
(Also if anyone has an idea why this is caused on radeon http://studwww.rug.ac.be/~cholleme/seethrough.jpg
It seems my depth fill pass is just skipped for some objects and only my light acummulation pass is done, again perfectly normal on nv cards.)

Charles

[This message has been edited by Pentagram (edited 08-25-2002).]

Use should use CLAMP_TO_EDGE for cubemaps. The Radeons actually do it the correct way, NVIDIA does not ( a choice they made to support “broken but popular” apps ).

Originally posted by Pentagram:
[b]Hello

I’m having some problems with cubemapping on radeon cards (8500).
When I use the 0 cubemap (when you bind with 0 as texture object) I seem to get black borders at the edges of the cubemap faces.
You can see it in action at http://studwww.rug.ac.be/~cholleme/lines.jpg
I’m using GL_CLAMP as GL_TEXTURE_WRAP_(S/T) param.
[/b]

If you want proper filtering at the cubemap edge (i.e. filtering texels from different faces), you have to download the cubemap with borders and replicate in the border texels the texels from the neighbour faces.

The artifacts he’s seeing is from using GL_CLAMP with his normalization cubemap, right Charles ? I had the same artifacts when I tried an old test ( using ARB extensions ) on a Radeon . It was initially developer on a GeForce1.

Originally posted by PH:
The artifacts he’s seeing is from using GL_CLAMP with his normalization cubemap, right Charles ? I had the same artifacts when I tried an old test ( using ARB extensions ) on a Radeon . It was initially developer on a GeForce1.

Sure, using GL_CLAMP_TO_EDGE is a partial solution. I’m just telling him that if he needs proper inter cubemap face filtering, he has to use a cubemap with borders.
Clamping to the edge may be the solution you applied, but the real solution is to provide a cubemap with borders so the filtering of adjacent faces is done properly (otherwise you are changing the way you calculate the value at the border, with regard of the way you calculate the value at non-border texels). Don’t you think?

Yes, I agree.

EDIT: CLAMP_TO_EDGE is sufficient for this particular case though.

[This message has been edited by PH (edited 08-25-2002).]

Tnks for all the suggestions.
Well I don’t really know what cubemap is causing the error, I use 2 cubemaps “per pixel”, one normalization cubemap and one “light filter” cubemap (the light filter thing is what that huge discussion was about, call it a shadow map, a light map whatever)
I somehow supposed it was my light filter cubemap (from the way the lines are positioned on my sufaces) but now you mention it it may also be the normalization cubemap.
Anyway all my cubemaps use CLAMP_TO_EDGE now. (hope this fixes the line problem at least)
And why doesn’t nvidia fix that those old apps are not my problem, those 10’s of people who mailed me about radeon problems are.

Charles

Originally posted by evanGLizr:
Clamping to the edge may be the solution you applied, but the real solution is to provide a cubemap with borders so the filtering of adjacent faces is done properly (otherwise you are changing the way you calculate the value at the border, with regard of the way you calculate the value at non-border texels). Don’t you think?

I’d guess in 99% of the cases the difference isn’t discernable. I’m not sure how widely cubemap borders are supported in hardware either.

I have one more suggestion - I think it’s safer to use glGenTextures rather than to bind to 0. In fact, if I remember correctly id = 0 is somewhat special, meaning “no texture” ( don’t quote me on that ).
Maybe that’ll fix the other problem you have ( you never know ).

I’ll try your q1 mod and see if I can find something ( I have a Radeon 8500 ).

Hmm, strange. You should change your ‘nudge’ value to 0.995 ( or thereabouts ). The one that Cass originally used doesn’t work on Radeon 8500 ( the value is too small, so there’ll be some shadow artifacts ).

The volumetric particle smoke is awesome btw.

Originally posted by Humus:
I’d guess in 99% of the cases the difference isn’t discernable. I’m not sure how widely cubemap borders are supported in hardware either.

It may not be discernible in a normalisation cubemap, but you will probably get artifacts on an environment cubemap, although the spec itself agrees that CLAMP_TO_EDGE works ‘reasonably well in most circunstances’ (whatever that means).

Just to roundup, I’ll paste the significant paragraphs from the ARB_texture_cubmap spec:

Does it make sense to support borders for cube map textures.
  Actually, it does.  It would be nice if the texture border pixels match the appropriate texels from the edges of the other cube map faces that they junction with.  For this reason, we'll leave the texture border capability implicitly supported.

Should there be limits on the supported border modes for cube maps?
RESOLUTION: NO. The specificiation is written so that cube map texturing proceeds just like conventional 2D texture mapping once the face determination is made.
Therefore, all OpenGL texture wrap modes should be supported though some modes are clearly inappropriate for cube maps. The WRAP mode is almost certainly incorrect for cube maps. Likewise, the CLAMP mode without a texture border is almost certainly incorrect for cube maps. CLAMP when a texture border is present and CLAMP_TO_EDGE are both reasonably suited for cube maps. Ideally, CLAMP with a texture border works best if the cube map edges can be replicated in the approriate texture borders of adjacent cube map faces. In practice, CLAMP_TO_EDGE works reasonably well in most circumstances.
Perhaps another extension could support a special cube map wrap mode that automatically wraps individual texel fetches to the appropriate adjacent cube map face. The benefit from such a mode is small and the implementation complexity is involved so this wrap mode should not be required for a basic cube map texture extension.

I would say that all the cards which support cubemapping, also support cubemaps with borders.

With regard to the texture 0 (texture id 0), it’s OpenGL’s default texture (the one current when you haven’t bound any texture object, when you delete the current texture object … or when you bind texture 0 ) and it’s a completely valid texture to work with.

[This message has been edited by evanGLizr (edited 08-25-2002).]

Originally posted by evanGLizr:
It may not be discernible in a normalisation cubemap, but you will probably get artifacts on an environment cubemap

In an environment cubemap (well, in fact pretty much any kind of cubemap) the colors will match each other well over cubemap edges so you wont get any visible artefacts.

> I would say that all the cards which
> support cubemapping, also support cubemaps
> with borders.

GeForce and GeForce2 support cube maps, but not borders. Seeing as that’s one of the larger individual market segments, I don’t think you want to degrade to software there :slight_smile:

Yea but it’s a royal pain in the ass to supply the border from the adjcent faces, bearing in mind that you often render for those faces.

It would be nice if you could supply a cube face and border with the single subload just by supplying an oversized image. glTexImageWithBorder or something like that. I’ve never really trusted texture borders to be fast, efficient or functional across multple platforms though.

[This message has been edited by dorbie (edited 08-26-2002).]