Bug 602 : Single transparent pixel at end of textures in OpenGL
Last modified: 2009-10-18 10:52




Status:
ASSIGNED
Resolution:
-
Priority:
P2
Severity:
normal

 

Reporter:
ewjordan
Assigned To:
fry

Attachment Type Created Size Actions
Picture illustrating bug in Textured Sphere example image/png 2007-08-29 21:10 124.71 KB

Description:   Opened: 2007-07-27 15:05
In OpenGL mode, the edge pixels of an image are coming out partially
transparent, thus making exact matching of edges impossible for tiled (or
cylindrical/spherical) images. This is apparent in the included example
with 0125 under Examples->3d and OpenGL->OpenGL->TexturedSphere, and it
shows up as a seam on the far side of the sphere. It disappears if you
switch to P3D.

The reason this is happening is that in the process of creating the texture
for the graphics card, Processing has to increase the dimensions to powers
of 2 and I assume it is filling the extra spaces with 0s - this means that
when texture filtering is used, the edge pixels of the true texture are
blended with fully transparent pixels. The fix would probably be to fill
in the filler pixels with the edge pixel colors in the actual texture, or
at least fill one extra row/column like that.

For the moment, a temporary workaround is to remap your texture coordinates
using something like:

u = map(u,0,1,0.01,0.99);
v = map(v,0,1,0.01,0.99);

(at least if you're in 0->1 texture mode), but this will slightly alter the
texture's appearance, so it's not a great fix.
Additional Comment #1 From fry 2007-07-27 19:33
actually we just need to set glEdgeFlag so that shapes can line up
properly, afaik this is the same as bug #200.

*** This bug has been marked as a duplicate of 200 ***
Additional Comment #2 From ewjordan 2007-08-03 23:18
I'm not sure that this is the same as bug 200, unfortunately - if I
understand correctly, that one seems to have something to do with
smoothing, whereas this persists even with smooth disabled (I think OpenGL
filters the textures no matter what). I'm almost certain that this one is
showing up because of a very slight read off the end of the true texture
(which is buffered by transparency internally, hence the gapping), mainly
because by altering the texture coordinates I can hack around it. Or am I
perhaps misunderstanding what exactly glEdgeFlag does, or what's going on
in bug 200 (the explanations there weren't entirely clear)?

In any case, I think I have an idea about how to fix this, though let me
know if you're fairly sure it's something else causing it.
Additional Comment #3 From fry 2007-08-28 19:18
hm, can you attach an image that describes it better?
Additional Comment #4 From ewjordan 2007-08-29 21:10
edit]
Picture illustrating bug in Textured Sphere example

Absolutely - in this picture you can see the seam on the globe. This is the
back edge of the globe compared to where the example starts out.
Additional Comment #5 From ewjordan 2007-08-29 21:35
BTW, I did work out a way to fix this, at least on my system (Powerbook G4
with an ATI Mobility Radeon 9700). First of all, in PGraphicsOpenGL all
occurences of GL_CLAMP should be replaced with GL_CLAMP_TO_EDGE, as I think
that's generally a safer default behaviour (see
http://www.devmaster.net/forums/showthread.php?t=5521 for an explanation of
the difference, which is relevant in this case). Second, the
ImageCache.rebind() for-loops need to be altered so that an extra
row/column is filled with the clamped pixels. I don't have that part quite
finished yet (I fixed up the seams on the right edge but not the bottom),
so I'll need a bit more time to get it fixed up right.

Am I correct to assume that this bug isn't showing up on all systems?
Additional Comment #6 From fry 2007-09-13 17:34
i see, i guess it probably is a different issue.

the solution is tough since the glEdgeFlag() stuff is gonna be the dominant
issue at this point. i'd say we revisit this once we get bug #200
straightened out. that make sense?
Additional Comment #7 From splat 2007-11-26 12:31
EWJORDAN-
Would you be interested in releasing your patched openGL.jar with these
mods? In the past this has been done for other features (such as forced 2x
smoothing before it was integrated). I think some of us would benefit from
a GL_CLAMP_TO_EDGE mod like you describe here (myself included).

(apologies for adding this to the bug train, just wanted you to see it).

(In reply to comment #5)
>
>
>
> Additional Comment #5 From
> ewjordan
> 2007-08-29 21:35
>
> <!--
> addReplyLink(5); //-->[reply]
>
>
>
>
> BTW, I did work out a way to fix this, at least on my system
(Powerbook G4
> with an ATI Mobility Radeon 9700). First of all, in PGraphicsOpenGL all
> occurences of GL_CLAMP should be replaced with GL_CLAMP_TO_EDGE, as I think
> that's generally a safer default behaviour (see
> http://www.devmaster.net/forums/showthread.php?t=5521 for an explanation of
> the difference, which is relevant in this case). Second, the
> ImageCache.rebind() for-loops need to be altered so that an extra
> row/column is filled with the clamped pixels. I don't have that part quite
> finished yet (I fixed up the seams on the right edge but not the bottom),
> so I'll need a bit more time to get it fixed up right.
>
> Am I correct to assume that this bug isn't showing up on all systems?
>
>
Additional Comment #8 From fry 2009-10-10 18:07
I think there's something broader with the math that needs to be
straightened out, but an additional workaround is to use non-power-of-2
textures, so I may switch to that as the default. But this seems to be a
problem with P3D as well, though not as pronounced.
Additional Comment #9 From fry 2009-10-18 10:52
A partial fix for this bug is part of 1.0.8, which enables non-power-of-2
textures when they're available on the graphics card.
This bug is now being tracked here.