awaking the cubemap catastrophe discussion

Discussion in 'Rendering Technology and APIs' started by nirradi, Jul 2, 2009.

  1. nirradi

    Newcomer

    Joined:
    Apr 1, 2009
    Messages:
    30
    Likes Received:
    0
    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
     
  2. DeanoC

    DeanoC Trust me, I'm a renderer person!
    Veteran Subscriber

    Joined:
    Feb 6, 2003
    Messages:
    1,469
    Likes Received:
    185
    Location:
    Viking lands
    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.
     
  3. Nick

    Veteran

    Joined:
    Jan 7, 2003
    Messages:
    1,881
    Likes Received:
    17
    Location:
    Montreal, Quebec
    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.
     
  4. nirradi

    Newcomer

    Joined:
    Apr 1, 2009
    Messages:
    30
    Likes Received:
    0
    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.
     
  5. Nick

    Veteran

    Joined:
    Jan 7, 2003
    Messages:
    1,881
    Likes Received:
    17
    Location:
    Montreal, Quebec
    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.
    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.
    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.
     
  6. CouldntResist

    Regular

    Joined:
    Aug 16, 2004
    Messages:
    264
    Likes Received:
    7
    Hmmm, I was under impression this was requirement since DX10?
     
  7. Bob

    Bob
    Regular

    Joined:
    Apr 22, 2004
    Messages:
    424
    Likes Received:
    47
    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.
     
  8. nirradi

    Newcomer

    Joined:
    Apr 1, 2009
    Messages:
    30
    Likes Received:
    0
    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.
     
  9. Bob

    Bob
    Regular

    Joined:
    Apr 22, 2004
    Messages:
    424
    Likes Received:
    47
    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.
     
  10. DeanoC

    DeanoC Trust me, I'm a renderer person!
    Veteran Subscriber

    Joined:
    Feb 6, 2003
    Messages:
    1,469
    Likes Received:
    185
    Location:
    Viking lands
    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...
     
  11. mczak

    Veteran

    Joined:
    Oct 24, 2002
    Messages:
    3,020
    Likes Received:
    115
    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.
     
  12. Simon F

    Simon F Tea maker
    Moderator Veteran

    Joined:
    Feb 8, 2002
    Messages:
    4,560
    Likes Received:
    157
    Location:
    In the Island of Sodor, where the steam trains lie
    I thought it was relatively simple but...:???:
     
  13. MfA

    MfA
    Legend

    Joined:
    Feb 6, 2002
    Messages:
    7,211
    Likes Received:
    609
    I fail to see the big deal hardware wise, it doesn't seem harder than repeated textures.
     
    #13 MfA, Jul 3, 2009
    Last edited by a moderator: Jul 3, 2009
  14. DeanoC

    DeanoC Trust me, I'm a renderer person!
    Veteran Subscriber

    Joined:
    Feb 6, 2003
    Messages:
    1,469
    Likes Received:
    185
    Location:
    Viking lands
    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.
     
  15. nAo

    nAo Nutella Nutellae
    Veteran

    Joined:
    Feb 6, 2002
    Messages:
    4,339
    Likes Received:
    163
    Location:
    San Francisco
    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.
     
  16. Bob

    Bob
    Regular

    Joined:
    Apr 22, 2004
    Messages:
    424
    Likes Received:
    47
    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
     
  17. CouldntResist

    Regular

    Joined:
    Aug 16, 2004
    Messages:
    264
    Likes Received:
    7
    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.
     
  18. TimothyFarrar

    Regular

    Joined:
    Nov 7, 2007
    Messages:
    427
    Likes Received:
    0
    Location:
    Santa Clara, CA
    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?
     
  19. nAo

    nAo Nutella Nutellae
    Veteran

    Joined:
    Feb 6, 2002
    Messages:
    4,339
    Likes Received:
    163
    Location:
    San Francisco
    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.
     
  20. Humus

    Humus Crazy coder
    Veteran

    Joined:
    Feb 6, 2002
    Messages:
    3,217
    Likes Received:
    77
    Location:
    Stockholm, Sweden
    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.

    Would that work for corner texels though?
     
Loading...

Share This Page

  • About Us

    Beyond3D has been around for over a decade and prides itself on being the best place on the web for in-depth, technically-driven discussion and analysis of 3D graphics hardware. If you love pixels and transistors, you've come to the right place!

    Beyond3D is proudly published by GPU Tools Ltd.
Loading...