FAQ
Cover
\
Build
\
Source
\
Bugs
\
Reference
\
Libraries
\
Tools
The bugs database has moved
here
.
Bug 602 : Single transparent pixel at end of textures in OpenGL
Last modified: 2009-10-18 10:52
P
roject:
processing
trash
Version:
unspecified
Co
m
ponent:
android
book
core
libraries
pde
reference
tools
web
Status:
ASSIGNED
Resolution:
-
Pr
i
ority:
P2
Severity:
normal
Platform
All
O
S:
All
Windows
Mac OS
Linux
Other
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
.