New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Single transparent pixel at end of textures in OpenGL #115

Closed
processing-bugs opened this Issue Feb 10, 2013 · 13 comments

Comments

Projects
None yet
3 participants
@processing-bugs

processing-bugs commented Feb 10, 2013

Original author: b...@processing.org (June 07, 2010 01:00:24)

This bug automatically added from:
http://dev.processing.org/bugs/show_bug.cgi?id=602

Comment from ewjordan, 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.

Original issue: http://code.google.com/p/processing/issues/detail?id=76

@processing-bugs

This comment has been minimized.

Show comment
Hide comment
@processing-bugs

processing-bugs Feb 10, 2013

From b...@processing.org on June 07, 2010 01:00:25
Comment 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.

processing-bugs commented Feb 10, 2013

From b...@processing.org on June 07, 2010 01:00:25
Comment 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.

@processing-bugs

This comment has been minimized.

Show comment
Hide comment
@processing-bugs

processing-bugs Feb 10, 2013

From b...@processing.org on June 07, 2010 01:00:25
Comment from fry, 2007-08-28 19:18

hm, can you attach an image that describes it better?

processing-bugs commented Feb 10, 2013

From b...@processing.org on June 07, 2010 01:00:25
Comment from fry, 2007-08-28 19:18

hm, can you attach an image that describes it better?

@processing-bugs

This comment has been minimized.

Show comment
Hide comment
@processing-bugs

processing-bugs Feb 10, 2013

From b...@processing.org on June 07, 2010 01:00:26
Comment from ewjordan, 2007-08-29 21:10

Created an attachment (id=149)
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.

processing-bugs commented Feb 10, 2013

From b...@processing.org on June 07, 2010 01:00:26
Comment from ewjordan, 2007-08-29 21:10

Created an attachment (id=149)
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.

@processing-bugs

This comment has been minimized.

Show comment
Hide comment
@processing-bugs

processing-bugs Feb 10, 2013

From b...@processing.org on June 07, 2010 01:00:26
Comment 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?

processing-bugs commented Feb 10, 2013

From b...@processing.org on June 07, 2010 01:00:26
Comment 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?

@processing-bugs

This comment has been minimized.

Show comment
Hide comment
@processing-bugs

processing-bugs Feb 10, 2013

From b...@processing.org on June 07, 2010 01:00:27
Comment 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?

processing-bugs commented Feb 10, 2013

From b...@processing.org on June 07, 2010 01:00:27
Comment 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?

@processing-bugs

This comment has been minimized.

Show comment
Hide comment
@processing-bugs

processing-bugs Feb 10, 2013

From b...@processing.org on June 07, 2010 01:00:27
Comment 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?

processing-bugs commented Feb 10, 2013

From b...@processing.org on June 07, 2010 01:00:27
Comment 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?

@processing-bugs

This comment has been minimized.

Show comment
Hide comment
@processing-bugs

processing-bugs Feb 10, 2013

From b...@processing.org on June 07, 2010 01:00:28
Comment 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.

processing-bugs commented Feb 10, 2013

From b...@processing.org on June 07, 2010 01:00:28
Comment 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.

@processing-bugs

This comment has been minimized.

Show comment
Hide comment
@processing-bugs

processing-bugs Feb 10, 2013

From b...@processing.org on June 07, 2010 01:00:28
Comment 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.

processing-bugs commented Feb 10, 2013

From b...@processing.org on June 07, 2010 01:00:28
Comment 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.

@processing-bugs

This comment has been minimized.

Show comment
Hide comment
@processing-bugs

processing-bugs Feb 10, 2013

From andres.c...@gmail.com on November 20, 2012 17:35:29
I confirm this bug still happening in 2.0b6, when npot textures are not supported. The only solution I see so far is similar to that suggested by ewjordan:

"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."

processing-bugs commented Feb 10, 2013

From andres.c...@gmail.com on November 20, 2012 17:35:29
I confirm this bug still happening in 2.0b6, when npot textures are not supported. The only solution I see so far is similar to that suggested by ewjordan:

"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."

@processing-bugs

This comment has been minimized.

Show comment
Hide comment
@processing-bugs

processing-bugs Feb 10, 2013

From f...@processing.org on November 20, 2012 19:38:00
But that'll break when textureWrap(REPEAT) is in use (or at least require and even uglier special case). Will it not also cause a 256x256 texture to become 512x512?

What's the (rough) percentage of cards/drivers that don't support NPOT textures nowadays? I assume it's probably a lot of mobile devices.

processing-bugs commented Feb 10, 2013

From f...@processing.org on November 20, 2012 19:38:00
But that'll break when textureWrap(REPEAT) is in use (or at least require and even uglier special case). Will it not also cause a 256x256 texture to become 512x512?

What's the (rough) percentage of cards/drivers that don't support NPOT textures nowadays? I assume it's probably a lot of mobile devices.

@ghost ghost assigned codeanticode Feb 11, 2013

@codeanticode

This comment has been minimized.

Show comment
Hide comment
@codeanticode

codeanticode Jun 2, 2013

Member

@benfry I'd recommend closing this long-standing issue as npot support is widespread nowadays on desktop GPUs, and becoming so on mobile GPUs as well.

Member

codeanticode commented Jun 2, 2013

@benfry I'd recommend closing this long-standing issue as npot support is widespread nowadays on desktop GPUs, and becoming so on mobile GPUs as well.

@codeanticode codeanticode removed the high label Sep 1, 2014

@benfry benfry removed the bug label Nov 15, 2014

@codeanticode

This comment has been minimized.

Show comment
Hide comment
@codeanticode

codeanticode May 30, 2015

Member

fixed with b92dc04

Member

codeanticode commented May 30, 2015

fixed with b92dc04

@benfry

This comment has been minimized.

Show comment
Hide comment
@benfry

benfry Jun 1, 2015

Member

Nice! An oldie.

Member

benfry commented Jun 1, 2015

Nice! An oldie.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment