glOrtho setup for rendering "impostors" into a texture.
Are you blending that to the screen as pre-multiplied or as regular alpha blending? It does look like the alpha is over-saturated, but it also looks like you are also re-multiplying the source pixels by the alpha. Maybe not, I can't really tell just from the screenshot.
According to the red book at least, don't you need to do anything special to use glBlendFuncSeperate() over glBlendFunc(), they both are activated with the GL_BLEND token.
Code:
glBlendFunc(GL_ONE, GL_ONE_MINUS_SRC_ALPHA);According to the red book at least, don't you need to do anything special to use glBlendFuncSeperate() over glBlendFunc(), they both are activated with the GL_BLEND token.
Scott Lembcke - Howling Moon Software
Author of Chipmunk Physics - A fast and simple rigid body physics library in C.
I'm going to have to keep experimenting; Using glBlendFuncSeparate didn't make any difference, as far as I can tell. The alpha remains saturated wherever fragments hit the buffer.
TomorrowPlusX Wrote:I'd *never* even heard of this glBlendFuncSeparate...Promoted from EXT_blend_func_separate to OpenGL 1.4. It is only available on Radeon8500+ and GeForce5200+. And, er, software.
Quote:can GL Profiler allow me to see the renderbuffer contents when I'm doing RTT? I thought it only allowed me to see the contents of the display context.If you are really using FBO renderbuffers (why would you use a renderbuffer to render to texture?) then no, the GL Profiler available as of XCode 2.2.1 can't show you the contents. A future version should fix that. It can show the contents of any display context, just use the context popup. And of course any texture, including ones bound to an FBO.
In my previous projects like PCSX I found it very helpful to watch the alpha buffer drawn one primitive at a time. It is much easier to see how those DST_ALPHA values are built up.
arekkusu Wrote:Promoted from EXT_blend_func_separate to OpenGL 1.4. It is only available on Radeon8500+ and GeForce5200+. And, er, software.
Gotcha. I stumbled across that googling for info on glBlendFuncSeparate. I'm willing to make the card-compatibility sacrifice
arekkusu Wrote:If you are really using FBO renderbuffers (why would you use a renderbuffer to render to texture?) then no, the GL Profiler available as of XCode 2.2.1 can't show you the contents. A future version should fix that. It can show the contents of any display context, just use the context popup. And of course any texture, including ones bound to an FBO.
It's very possible that I'm mixing up my terminology. I'm using an FBO to target a color attachment texture; I'm not certain of any other approach to do the same, other than PBuffers. Too bad I can't view its alpha channel.
arekkusu Wrote:In my previous projects like PCSX I found it very helpful to watch the alpha buffer drawn one primitive at a time. It is much easier to see how those DST_ALPHA values are built up.
I'll keep my fingers crossed for an updated GL Profiler in the future
I have to post an update. First, I solved what I thought was the problem. The whole black-fringe thing was an artifact resultant of a bug in how my scenegraph sets up drawing for transparent objects ( which are depth sorted and all that hoo-hah ).
Anyway, on catching that, I discovered that I have, in fact, the exact opposite problem than I thought. Initially I thought that alpha was saturating.
Now, I realize that alpha is not saturating, but is in fact acting more along these lines:
Pseudo
You can see in this annotated screenshot:
![[Image: Screenshots-2006-05-17-02.png]](http://zakariya.net/shamyl/Trees/Screenshots-2006-05-17-02.png)
What's happening, as far as I can tell, is that each incoming fragment with alpha < 1 is reducing the alpha in the color buffer. I've tried different blending modes with no luck.
You can see in the above code I've tried to make the alpha blending function additive. No luck, though.
EDIT:
The plot thickens! If I turn off texturing, but leave the code otherwise identical, I get the correct additive blending behavior.
![[Image: Screenshots-2006-05-18-01.png]](http://zakariya.net/shamyl/Trees/Screenshots-2006-05-18-01.png)
I'm baffled.
Anyway, on catching that, I discovered that I have, in fact, the exact opposite problem than I thought. Initially I thought that alpha was saturating.
Now, I realize that alpha is not saturating, but is in fact acting more along these lines:
Pseudo
Code:
dst.alpha = src.alpha * dst.alphaYou can see in this annotated screenshot:
![[Image: Screenshots-2006-05-17-02.png]](http://zakariya.net/shamyl/Trees/Screenshots-2006-05-17-02.png)
What's happening, as far as I can tell, is that each incoming fragment with alpha < 1 is reducing the alpha in the color buffer. I've tried different blending modes with no luck.
Code:
void TreeFoliage::LeafRenderer::display( RenderPass pass )
{
if ( impostorRendering )
{
glEnable( GL_DEPTH_TEST );
glDisable( GL_FOG );
glDisable( GL_LIGHTING );
vec3 ambient = WORLD()->ambientLight();
const float alphaPinion = highQuality ? 0.85f : 0.4f;
glEnable( GL_BLEND );
glBlendFuncSeparate( GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA,
GL_SRC_ALPHA, GL_ONE );
// render relatively solid bits
glDepthMask( GL_TRUE );
glAlphaFunc( GL_GREATER, alphaPinion );
glBegin( GL_QUADS );
TreeLeafVec::iterator it( leaves.begin() ), end( leaves.end() );
for ( ; it != end; ++it )
{
vec4 color( it->color );
color.x *= ambient.x;
color.y *= ambient.y;
color.z *= ambient.z;
glColor4fv( color.v );
it->display();
}
glEnd();
// render fringe bits
glDepthMask( GL_FALSE );
glAlphaFunc( GL_LEQUAL, alphaPinion );
glBegin( GL_QUADS );
it = leaves.begin();
for ( ; it != end; ++it )
{
vec4 color( it->color );
color.x *= ambient.x;
color.y *= ambient.y;
color.z *= ambient.z;
glColor4fv( color.v );
it->display();
}
glEnd();
glDepthMask( GL_TRUE );
glBlendFunc( GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA );
glEnable( GL_FOG );
glEnable( GL_LIGHTING );
}
else
{
//normal rendering...
}
}You can see in the above code I've tried to make the alpha blending function additive. No luck, though.
EDIT:
The plot thickens! If I turn off texturing, but leave the code otherwise identical, I get the correct additive blending behavior.
![[Image: Screenshots-2006-05-18-01.png]](http://zakariya.net/shamyl/Trees/Screenshots-2006-05-18-01.png)
I'm baffled.
Well, I don't know exactly what solved it. I poked around a little, and experimented. I think -- think -- that eliminating depth writes and disabling alpha testing fixed it.
I can't say why, though.
Now, back to the problem of how to get a correct projection.
I can't say why, though.
Now, back to the problem of how to get a correct projection.
You might need to use EXT_blend_equation_separate or another similar extension to get the destination alpha working the way you want.
Well, after a fair amount of experimentation, I now have both the alpha compositing and the ortho projections working correctly!
In fact, in tests, the tree ( rendered distantly as an impostor ) looks almost exactly the same as the real geometric tree, complete with parallax when you look from different angles. The only difference is that the impostor -- being a texture -- is antialiased where the normally rendered tree is not. When I enable FSAA, it basically is indistinguishable!
So, now I've got some plumbing issues to make trees automatically switch between impostor and solid rendering based on distance ( and probably lrp the alpha of the solid and impostor for a range between the switch, so I don't get "popping" ).
Ultimately, that's what I used, but making it *work* required -- apparently -- turning off alpha and depth testing. I don't understand why, though.
In fact, in tests, the tree ( rendered distantly as an impostor ) looks almost exactly the same as the real geometric tree, complete with parallax when you look from different angles. The only difference is that the impostor -- being a texture -- is antialiased where the normally rendered tree is not. When I enable FSAA, it basically is indistinguishable!
So, now I've got some plumbing issues to make trees automatically switch between impostor and solid rendering based on distance ( and probably lrp the alpha of the solid and impostor for a range between the switch, so I don't get "popping" ).
OneSadCookie Wrote:You might need to use EXT_blend_equation_separate or another similar extension to get the destination alpha working the way you want.
Ultimately, that's what I used, but making it *work* required -- apparently -- turning off alpha and depth testing. I don't understand why, though.
Possibly Related Threads...
| Thread: | Author | Replies: | Views: | Last Post | |
| FBO rendering to GL_ALPHA texture | Fenris | 11 | 4,883 |
Jun 4, 2009 03:18 PM Last Post: Fenris |
|
| HELP!!! Simple glOrtho problem! | Marvin | 3 | 3,490 |
Jun 27, 2007 10:23 AM Last Post: Marvin |
|
| xCode/SDL Setup | hammonjj | 2 | 4,291 |
Mar 2, 2007 06:37 AM Last Post: hammonjj |
|
| OpenGL Texture in relation to GL orientation, and... glOrtho help. | Jones | 6 | 4,433 |
Jun 30, 2006 07:18 PM Last Post: arekkusu |
|
| SDL 2D OpenGL setup | unknown | 13 | 6,376 |
Jul 16, 2005 09:07 PM Last Post: unknown |
|

