[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Public WebGL] Weird alpha issue.
- To: Benoit Jacob <firstname.lastname@example.org>
- Subject: Re: [Public WebGL] Weird alpha issue.
- From: Steve Baker <email@example.com>
- Date: Mon, 01 Nov 2010 20:16:15 -0500
- Cc: public webgl <firstname.lastname@example.org>, Zhenyao Mo <email@example.com>
- Dkim-signature: v=1; a=rsa-sha1; c=relaxed; d=sjbaker.org; h=message-id :date:from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; s=sjbaker.org; bh=eOt5t /F4tgY5tnQbQU2BuVtfrk8=; b=Q2edPNFRYRikdu+njv1geRjM/UeCJzNHN+AQi hlMN5Di7tMqXIHAaZ7WKxWtBET49hz+F5UFyB47TFf+dhmFjk/78iEkJC27mJ2RL 2KZ0bmUcX2Kh9KkgDP9t6PWPodJ3Wkq5exngW3ywI66Fc6YF2UGtvd17D5waa0Gk MyG0T0=
- Domainkey-signature: a=rsa-sha1; c=nofws; d=sjbaker.org; h=message-id:date :from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=sjbaker.org; b=jPwXpRuqMVKvCjo1vQO4CAzAvJsbwiHvmGsRhxRnFjYo3ey0SHWj7LtuvvFWf BOHLm2j/rbEfyCHR9AM89uHLDYtiCaVtJ+mPg0OuwSe1jxJQRH5rSV9nrKSqvr4W 5vc76o7NDPUekaTlFc0oWGZ+UJ/48Z55Spo9i6qE9g9ksg=
- In-reply-to: <780789151.246002.1288644295362.JavaMail.firstname.lastname@example.org>
- References: <780789151.246002.1288644295362.JavaMail.email@example.com>
- Sender: firstname.lastname@example.org
- User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:126.96.36.199) Gecko/20100520 SUSE/3.0.5 Thunderbird/3.0.5
According to the spec, (forgive me if I misread it) - WebGL doesn't
support the glAlphaFunc feature from OpenGL. (I think that's because
it's not implemented in OpenGL ES 2.0) So if you want something like
the OpenGL alpha test feature, you have to implement it yourself in your
if ( alpha < alphaRef ) discard ;
Well, my example program doesn't do that - hence, pixels with alpha==0.0
*SHOULD* be rendered just like pixels with (say) alpha==0.1 are.
So - look at my little test program: The smoke puff is a pair of
triangles with a texture that has alpha==1.0 in the middle and
alpha==0.0 at the edges. So when destination alpha is enabled (either
deliberately or buggily) we should see a rectangular hole in the canvas
- not a smoke-cloud-shaped hole. Even if destination-alpha were
disabled, this behavior would cause unexpected issues with Z-buffering
of completely transparent surfaces.
The behavior I'm seeing is as if alpha testing were enabled with
alphaRef set to some very small value.
It should be an easy fix - just call glDisable(GL_ALPHA_TEST)
someplace. What's weird is that should be the OpenGL default - so
something somewhere is actively calling glEnable(GL_ALPHA_TEST)...and it
AFAICT, neither Minefield nor Chrome is getting that right - not in
OpenGL or ANGLE - Linux or Windows.
The way things are right now, if someone actually WANTED to cut a
perfectly transparent shape out of their destination-alpha canvas,
they'd be unable to do so by writing alpha==0 pixels.
On 11/01/2010 03:44 PM, Benoit Jacob wrote:
>> * Both browsers incorrectly AlphaTest out pixels where alpha==0.0
> Sorry, I missed this part and can't find back where you explained it. What are we doing wrong specifically on pixels where alpha==0 ?
You are currently subscribed to email@example.com.
To unsubscribe, send an email to firstname.lastname@example.org with
the following command in the body of your email: