fredsa / forplay

Automatically exported from code.google.com/p/forplay
Apache License 2.0
12 stars 4 forks source link

Source rects and clamping cause texture bleeding under scale in WebGL #44

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago
We currently use linear filtering for scaling textures in WebGL. If a source 
rect is set (such as sub-images for sprites) AND the image is scaled, this 
filtering will cause texture bleeding. (See the attached image where a flag is 
surrounded by a checkerboard pattern, but only the flag 'src rect' is supposed 
to be drawn).

There are a couple of approaches I can think of:
1) Use a mask that causes the outer pixels to blend to alpha=1
2) Create a new texture for each source rect
3) Simply doc that sprites should be surrounded by a 1px transparent border if 
they are going to be drawn under scale
4) Locate the elusive TEXTURE_{MIN,MAX}_FILTER OpenGL flag for clamp at edges, 
linear blend elsewhere

I'm not sure the best way to handle this. Any ideas?

Original issue reported on code.google.com by pdr@google.com on 7 Jun 2011 at 2:47

Attachments:

GoogleCodeExporter commented 9 years ago
I'm afraid this is a common problem with sprite sheets. There is no flag I'm 
aware of that can make OpenGL *not* behave this way -- the sampler's only job 
is to produce a color value for a given (s,t) location, and has no knowledge 
that the fragment being rendered is at the edge of anything. The CLAMP option 
works entirely in terms of texture coordinates, which only works for the 
single-image-per-texture case.

If you think about it a bit, the only reason our intuition tells us this 
problem should be soluble is that we're looking at the mapping of a rectangle 
into texture space. But if you think about it in terms of non-rectangular 
shapes, the idea of clamping the texture at the border of the rendered 
primitive really doesn't make much sense.

Given all that, I don't think we can do much more than document the need for 
"guard pixels".

Original comment by jgw@google.com on 7 Jun 2011 at 3:07