Rendering ladders and fences - problems with bilin. filtering
Carsten Fuchs
I'm trying to render some ladders, fences and other things
where one can "look through" parts of a texture.
In order to do so, I set the alpha value to 0 where one
can look through the texture (i.e. the spaces between two
steps of a ladder or the holes in a fence), and to 1.0
where the actual texture is.
Everything works as expected, including the fact that the
color of the parts with an alpha==0 value "bleeds" into
the parts that have alpha==1.0, due to the linear filtering.
The effect varies, depending on if GL_BLEND and/or GL_ALPHA_TEST
is enabled at the same time or not,
but whatever I do, it seems I cannot get it done such that it
yields the same results as in most computer games,
where in spite of bi- or tri-linear filtering,
there seems to be no "bleeding" of colors.
I might imagine some tricks that help a little, but not much.
Usually, there is always a new problem introduced,
and apparently, I am doing something wrong, or missing
something elsewhere.
Any combination of GL_BLEND and GL_ALPHA_TEST I can think
of has problems, and I tried them all.
(GL_BLEND is not very useful at all, because in the range
where the alpha is interpolated from 0 to 1.0 there is
the usual translucency fade. Unwanted, in this case,
thus I usually turn GL_BLEND off.)
The GL_ALPHA_TEST helps with the translucency, but
the color of the holes does still in nearly all cases bleed
into the visible parts of the texture, or there are problems
with filtering:
Letting only high alpha values pass (near 1.0) minimized
the bleeding effect, but the visible parts become smaller
and the bi/trilinear filtering causes the texture to disappear
entirely when the view distance becomes too large
(because also the alphas are filtered, and then fall through
the test).
Letting also smaller alpha values pass (e.g. alpha>0.5)
minimized the "disappearance" problem, but increases the
color bleeding problem.
I'd be very grateful for any suggestions how to get this going.
Would be really great if someone could point me into the
right direction.
Thank you very much!
Best,
Carsten
--
Ca3D - Engine http://www.ca3d-engine.de
Carsten Fuchs http://www.ca3d-engine.de/carsten
WTH
doing that, but only in certain situations (where I just needed the transparency [meaning no levels of opacity, just total
transparency].)
WTH
"Carsten Fuchs" <Carste...@T-Online.de> wrote in message news:3D85291A...@T-Online.de...
zed
use NO blending ie disable it, just enable alphatesting with GL_GREATER 0.0
with alphatest a pixel passes or fails theres no in between
Carsten Fuchs
> Have you tried skipping blending and using colorkey for the transparent portion?
By "colorkey" you mean to consider each pixel of the input texture,
and set the alpha=0 where the pixel matches a colorkey,
like for example pure blue, (0 0 255) ?
This is what I'm doing.
Please see my other post where I have a small screen shot included
that demonstrates the problem.
Carsten Fuchs
> use NO blending ie disable it, just enable alphatesting with GL_GREATER 0.0
> with alphatest a pixel passes or fails theres no in between
Of course a pixel fails or passes, but the alpha value is also interpolated.
When I set alpha=0 in one texture input pixel, and alpha=1.0 in the next,
there are alpha values in the entire range 0...1.0.
Please see my other post that demonstrates what happens with GL_GREATER 0.0.
Carsten Fuchs
please have a look at the following screen-shot
http://www.Ca3D-Engine.de/Downloads2/sc1.png
The screenshot demonstrates the problem:
The input texture was a "fence", stored in RGB format.
The holes were colored blue (0 0 255).
Before constructing the texture object, I thus turned
RGB to RGBA with all alphas=1.0 (or 255 as unsigned byte),
except where the color was blue, I replaced with RGBA
(255 0 255 0), which is an "invisible purple".
(I changed the color just for debugging purposes
to see that it works, could have also been (0 0 255 0) ).
With blending turned off and GL_ALPHA_TEST on
(GL_GREATER 0.0), the screen-shot was made.
It is clearly visible that the pixels with the
(255 0 255 0) are interpolated into the (r g b 255)
pixels. With the alphatest being GL_GREATER 0.0,
the result is somewhat expected,
but not wanted. ;-)
As mentioned earlier, a way is wanted to
avoid the purple fading into the other parts.
I have found a way to alleviate the problem
by choosing the invisible color more carefully.
Instead of purple, a neighboured *visible*
color could be set (or a filtered color of several
visible neighbours). The effect would still be there,
but not visible anymore, because the invisible
colors and the visible colors would be similar
or equal.
However, I might imagine that there are better solutions...
argh
But in looking at the picture I have to ask... is this a rendering problemn
or a problem with the source texture? If your source texture's transparent
areas (purple/pink) are not absolutely distinct, but rather blended slightly
into the rest of the image via anti-aliasing or some such mechanism... well,
you'll never get a clean hole when rendering.
I only bother to mention this because I've had Paint Shop Pro do this to me
a number of times. Seems it set anti-aliasing to ON by default for a number
of tools, some that you wouldn't expect it.
If I'm right off, well just ignore me.
:-)
"Carsten Fuchs" <Carste...@T-Online.de> wrote in message
news:3D85A2DD...@T-Online.de...
Ruud van Gaal
<Carste...@T-Online.de> wrote:
>Hi all
>
>please have a look at the following screen-shot
>http://www.Ca3D-Engine.de/Downloads2/sc1.png
>
>The screenshot demonstrates the problem:
...
>With blending turned off and GL_ALPHA_TEST on
>(GL_GREATER 0.0), the screen-shot was made.
...>I have found a way to alleviate the problem
>by choosing the invisible color more carefully.
Right, I choose black normally, although you'd indeed want to keep as
close to the pixel as possible.
I think the ultimate best would be to keep a spare pixel of space in
all invisible areas. So a pixel near-brown (as in your ladder) with
alpha=0. Then instead of doing software keying on a magic color, use a
format which supports an alpha channel (like .tga).
I've seen commercial games having a threshold (perhaps even per
material) which defines the alpha threshold (the alpha func's on/off
value). So it seems like it was a compromise there as well.
Whatever you do, don't use purple in the end-texture, perhaps
anisotropic filtering will get it back into your texture whatever you
try to do.
Or in certain cases, you might be able to switch to 'nearest'
filtering (no bilinear). But I don't know if we ever want to go back
to that. ;-)
Also, take care with mipmapping, which will bleed purple pixels into
your texture.
Ruud van Gaal
Free car sim: http://www.racer.nl/
Pencil art : http://www.marketgraph.nl/gallery/
Carsten Fuchs
> I'm probably stating the obvious here... so please nobody stomp on me...
>
> But in looking at the picture I have to ask... is this a rendering problemn
> or a problem with the source texture? If your source texture's transparent
> areas (purple/pink) are not absolutely distinct, but rather blended slightly
> into the rest of the image via anti-aliasing or some such mechanism... well,
> you'll never get a clean hole when rendering.
The distinction is exact and correct for the input texture,
the texture filtering (bilinear/mipmaps) causes the
purple to fade into the other colors.
Carsten Fuchs
> [...]
> Whatever you do, don't use purple in the end-texture, perhaps
> anisotropic filtering will get it back into your texture whatever you
> try to do.
>
> Or in certain cases, you might be able to switch to 'nearest'
> filtering (no bilinear). But I don't know if we ever want to go back
> to that. ;-)
>
> Also, take care with mipmapping, which will bleed purple pixels into
> your texture.
What I am doing now is replacing the original blue
with an alpha value of 0 and a color value that is
the average of all visible colors.
The solution is not perfect (works best when the visible
parts are all of approx. the same color anyway),
and it would probably be better to derive
individual replacement colors for each blue pixel,
but the average value is good enough for me.
For the moment at least.
:-)
Thanks to all!
zed
whats happening im pretty sure is
when youre saving the image in a paint program there is the 'blurring'
occuring
open up the image in the paint program + zoom in close + check the pixel
colours to see if theyre exactly purple + not a mixture or purple +
another colour.
better method is to ditch colorkeys and create the alpha channel in the
paint program
how to?
copy the colour channel to the alpha channel
goto contrast + turn that up to maximum
this hopefully should turn all the pixels in the alpha channel to either
black or white
load that in your app instead
btw this is a far faster method than creating your own alphachannel
during the app
zed