awaking the cubemap catastrophe discussion

nirradi

Newcomer
I know i'm disturbing an old issue here but i see that the opengl spec (2009) persists in forcing implementations to choose one face of a cubemap according to the incoming vector (rx, ry, rz) - and continueing as if the texture was a regular 2d - well i don't need to explain - you guys know about this

but do implementations really do this? does nVidia adhere to this? do hardware implementations not mix up a few faces now and then - this would seem more correct.

ty, Nir
 
No hardware implementation I know textures across faces, its would be much more expensive.

IIRC ATI did some work on pre-sampling some cube maps to help solve the issue.
 
You can do this in a shader, if it's really worth it.

First, create a cube map where each face has an extra row/column of texels on each side, filled with the texels from the neighboring faces.

Then in your shader depending on whether the lookup vector's component x is larger or smaller than y you multiply one or the other by dim/(dim+2), with dim being the original dimension of the texture in texels.
 
first, 10x for the replies

Nick - when you say "You can do this in a shader" - are you telling me that game developers use tricks like this to overcome the HW setback? (i personally cant cause i'm not a shader-code guy) this would involve creating the textures differently - and might jepeordize performance- wouldnt' shader-code people rather the HW do the texture lookup like it ideally should

maybe the real question is - is it worth it - does this cause any visible artifacts that would cause shader-code ppl to write stuff like you described.
 
Nick - when you say "You can do this in a shader" - are you telling me that game developers use tricks like this to overcome the HW setback?
I don't know of any games that actually do this. I merely presented a solution in case you really need this to work the way you want.
...this would involve creating the textures differently - and might jepeordize performance- wouldnt' shader-code people rather the HW do the texture lookup like it ideally should
The problem is that it really requires a fair bit of extra logic. Like you mentioned the current specification allows to treat it like a 2D texture lookup once the cubemap face has been determined. That makes it relatively simple. If you want it to be able to filter texels from different faces, the entire texture sampler needs to be modified to support this. Since cubemaps are not used as frequently as 2D textures that's not really worth the hardware cost.
maybe the real question is - is it worth it - does this cause any visible artifacts that would cause shader-code ppl to write stuff like you described.
It might cause some of the cubemap's seams to be visible, if highly contrasting colors are used. And only if you really look for it. So in practice I don't know of any application that tries to fix this with a shader. Note also that it actually becomes less of a problem with higher resolution cubemaps.
 
If you use OpenGL, you can generate borders for your cube map such that the borders of each face contain data from adjacent faces. That was the intended usage of the functionality added to OpenGL.

Note that D3D10 has different requirements.
 
Bob - wow, really? thats what those silly borders are for? I put it to you that borders are extinct - yet cubemaps persist (opegl es spec from april 2009) - so it was maybe intended - but apparently not very popular at the khronos groups, what say you?

CouldntResist - i'm trying to cope with openGL for now, but if indeed DX10 has more strict requirements which demand the correct texture samples be brought from the correct face - than hats off and if you find any doc stating exactly that i would be so very grateful. ty.
 
nirradi said:
what say you?
Simple: The Khronos groups is wrong :) IMHO, implementations that don't support GL_ARB_compatibility will quickly find themselves without buyers (Edit: except perhaps if said implementation has the name of a popular fruit, apparently).

D3D10 required this new sampling behavior because cubemaps were essentially broken in D3D9 due to lack of borders, and D3D10 was not interested in adding borders.
 
Border have always been a nasty curse for the hardware and often are more expensive in some way (space or time) but this has always been hidden behind the driver.

Learn something new everyday, didn't realise Dx10 required new cubemap sampling rules! Can't find any official docs but several people on the interweb seem to agree so yay. Wonder if its required or just that ATI and NV do it now... Just curious what Intel IGP or S3 Chrome do in this case...
 
Hmmm, I was under impression this was requirement since DX10?
Yes, hardware can do that. I guess a new GL extension would be needed for that.
If you have a i965 the linux opengl driver will actually do it too - as per comment in the code non-cube coordmodes for cube maps tend to lock up so it will use this mode, even though it's not quite spec-compliant...

btw here's the description what this setting does, sounds like exactly what you asked for :).
4.2.4.6 TEXCOORDMODE_CUBE Mode
For cube map textures TEXCOORDMODE_CUBE addressing mode can be set to allow
inter-face filtering. When texel sample coordinates that extend beyond the selected
cube face (e.g., due to intra-level filtering near a cube edge), the correct sample
coordinates on the adjoining face will be computed. This will eliminate artifacts
along the cube edges, though some artifacts at cube corners may still be present.
 
I fail to see the big deal hardware wise, it doesn't seem harder than repeated textures.
 
Last edited by a moderator:
I could be wrong but I thought it was the bilinear sample that made it harder (clearly not as hard as I thought given its in Dx10).

With all other texture modes (repeat, clamp etc.) you still just altering a 2D texture coord. With a cubemap the bilinear address generator has to swap to another surface as well as altering a 2D texture coord.

But w00t is supported on Dx10 hardware.
 
All DX10 hw can sample across cube faces. The most interesting part of the whole process is how to compute a proper LOD when you need to fetch texels from two or even three faces.
 
Addressing bordered textures isn't harder than general non-power-of-2 textures. The tricky part is to support those weird border filtering modes in GL
 
I always thought this capablity came free with removal of power of 2 restriction for cube face size. Having that, all what driver needs to do, is to silently generate border texels.
 
From my understanding, DX10 ATI hardware had an extra instruction is required prior to cube texture lookup (regardless of edge filtering?). Is this extra DX10 cross cube edge filtering done via software emulation or does it have the same cost as the DX9 filtering?
 
From my understanding, DX10 ATI hardware had an extra instruction is required prior to cube texture lookup (regardless of edge filtering?). Is this extra DX10 cross cube edge filtering done via software emulation or does it have the same cost as the DX9 filtering?
It would be ridiculously slow if done in software. ATI is probably using the shader cores to normalize texture coordinates so that they can avoid to waste area in their texture units for something which is rarely used.
 
Can't find any official docs but several people on the interweb seem to agree so yay. Wonder if its required or just that ATI and NV do it now... Just curious what Intel IGP or S3 Chrome do in this case...

The DX spec is not public (don't ask me why, it contains no particular secrets). But yes, it's required. I guess sampling across faces is not much of an issue. I think sampling at the corner is what's nasty. Back in the R600/G80 days I noted that the G80 was quite broken in the corner, with a sharp edge between the faces and weird colors. Not sure if it was a driver bug or hardware issue. R600 on the other hand suffered somewhat from a small precision issue so that things didn't line up perfectly, although it was mostly invisible.

I always thought this capablity came free with removal of power of 2 restriction for cube face size. Having that, all what driver needs to do, is to silently generate border texels.

Would that work for corner texels though?
 
Back
Top