1
\$\begingroup\$

i have been struggling with this problem on and off for a few years now - making a seamless stereographic projection texture mapping on a sphere where the two halves of the sphere use the projection onto planes touching the poles as appropriate.

intuitively it seems possible provided that the right data is in the texture and i've taken many approaches, but i always get a nasty seam around the equator.

example image

i've tried smearing the colours out along the path i imagine the interpolator would take to try and get between the distant texels, but this still leaves a seam (though it makes it less objectionable).

i thought it might be to do with mipmapping, but forcing the lod in a shader does nothing.

i've tried overriding the derivatives (although this isn't always possible) and that doesn't fix it either (and i wouldn't expect it to because forcing the lod didn't).

i figured i might be able to get around this by wasting lots of texture space and making a sort of tiling texture that contains flipped versions of the projection at the top and bottom so that the interpolation path passes through something sensible-ish...

tiling projection

i've also tried limiting the interpolation paths along the x-axis/u-axis in the texture, since it also naively seems like this should have the right colours for the interpolator to run over inbetween the two halves.

i've also tried the very simple thing of multiplying by 0.9999 to remove rounding errors, as well as clamping the samples onto the circles.

i should point out that the same problem occurs with any texture addressing mode (wrap, mirror, clamp) and even if i manually clamp the texture coordinates in the shader.

also that i have debugged the uvs by putting them out through the shader and there is only the expected sharp seam in them:

uvs as red/green

none of this stuff properly gets rid of the seam, and its exceptionally objectionable compared to the usual kinds of seams.

does anyone have any other ideas for how to approach this? i can't find anything online about this. perhaps my approach is too novel...

now i know i can cheat, expand the projection and blend between the two across the equator, but i'd really, really, like to not double the number of texture samplings i'm doing per pixel for this.

(also i can avoid the problem with a cylindrical mapping, but thats no fun at all :D)

thanks in advance.

\$\endgroup\$
7
  • 1
    \$\begingroup\$ What texels are being read at the seam? It looks like you might be using wrap-mode addressing and end up blending with a color on the opposite side of the hemisphere. Using clamp-mode addressing should make the seam much less visible, but there will still be some inaccuracy because fundamentally some pixels should be blending between the edge of one hemisphere's projection texture and the corresponding edge of the other hemisphere's texture. \$\endgroup\$
    – MooseBoys
    Commented Nov 5, 2015 at 0:51
  • \$\begingroup\$ nothing that simple i'm afraid. i get the same problem with clamp to edge and even if manual clamp in the shader. \$\endgroup\$
    – jheriko
    Commented Nov 5, 2015 at 1:10
  • 1
    \$\begingroup\$ So what texels are being accessed that contribute to the darker color? If you don't have a graphics debugger, it would be helpful to see a view that maps red/green to UV coordinate and blue to 0 for the top hemisphere or 1 for the bottom hemisphere. \$\endgroup\$
    – MooseBoys
    Commented Nov 5, 2015 at 1:12
  • \$\begingroup\$ the uv mapping looks exactly correct when i do this. there is a seam, but its the usual sort of hard transition like you would expect. not as ugly as once i start sampling textures. is it worth editing the question with a picture of this? its already feeling a bit long and full of pictures \$\endgroup\$
    – jheriko
    Commented Nov 5, 2015 at 1:58
  • \$\begingroup\$ ok. so i added it anyway - easy to take away later if i end up adding far too many things. \$\endgroup\$
    – jheriko
    Commented Nov 5, 2015 at 2:02

1 Answer 1

Reset to default
1
\$\begingroup\$

turns out that my understanding of GLSL was at fault, and my theory about miplevels due to it lerping across large swathes of texture was correct.

the third parameter for texture2D is a bias for the mip level, not the lod, and i had assumed incorrectly it was the lod.

unfortunately texture2DLod is missing under my driver (and others) but i've been able to come up with a little hack using that bias parameter to remove the problem in a visually acceptable way.

hopefully this information proves useful to someone else in future.

solved problem

\$\endgroup\$
1
  • \$\begingroup\$ (if anyone else say anything more useful i'll give them correct answer, e.g. if they can explain why i have trouble using texture2DLod despite it being mentioned in the GLSL 1.2 spec - otherwise i'll come back and mark it as this in a few days) \$\endgroup\$
    – jheriko
    Commented Nov 5, 2015 at 2:46

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .