do you sort transparent objects?
Author
do you sort transparent objects (poly by poly)?
or you do tricks such as disable depth writing while rendering alpha?
Sort objects by depth.
Disable ZWrite.
Enable ZTest.
Render culling front faces.
Render culling back faces.
Done.
Disable ZWrite.
Enable ZTest.
Render culling front faces.
Render culling back faces.
Done.
There needs to be a blending method that works regardless of the order you render in because this problem is IMO the biggest hassle there is.
I had an Idea for a routine and that is to have a layered frame buffer that stores ALL the fragments written to any particular pixel, sorts them by depth and then draws them to the screen back to front when the buffer is swapped. to speed up things it could discard any fragment that’s deeper than an opaque Pixel.
I suppose this could be done with a pixel shader(although I don’t know enough about them yet) but I guess it would be fastest if it was done by the hardware directly.
The graphics card would have to allocate an area of its memory for the buffer in such a way that the pixels are spaced n*b bits apart; n being the number of layers and b being bits per pixel. Although I suppose it would be better to store the adjacent pixels contiguously and have the layers separate, because you would almost never use 100% of any layer except for the first and maybe the second.
I had an Idea for a routine and that is to have a layered frame buffer that stores ALL the fragments written to any particular pixel, sorts them by depth and then draws them to the screen back to front when the buffer is swapped. to speed up things it could discard any fragment that’s deeper than an opaque Pixel.
I suppose this could be done with a pixel shader(although I don’t know enough about them yet) but I guess it would be fastest if it was done by the hardware directly.
The graphics card would have to allocate an area of its memory for the buffer in such a way that the pixels are spaced n*b bits apart; n being the number of layers and b being bits per pixel. Although I suppose it would be better to store the adjacent pixels contiguously and have the layers separate, because you would almost never use 100% of any layer except for the first and maybe the second.
In some blending modes you don't have to sort transparent objects.
In my current project I draw clouds with blend mode (GL_ONE, GL_ONE_MINUS_SRC_ALPHA), i.e. the pixels in the frame buffer are not attenuated. I found that it looked better than (GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA). When you use GL_ONE, it doesn't matter in which order you draw the transparent stuff since everything is just added to the pixel, so order is inimportant.
In my current project I draw clouds with blend mode (GL_ONE, GL_ONE_MINUS_SRC_ALPHA), i.e. the pixels in the frame buffer are not attenuated. I found that it looked better than (GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA). When you use GL_ONE, it doesn't matter in which order you draw the transparent stuff since everything is just added to the pixel, so order is inimportant.
The graphics cards manufactured by powerVR use whats known as tile based rendering, by considering tiny portions of the screen at a time it can perform defered blending, where all the blending calcs are performed once all the polygon info is availiable, it removes the need for sorting transparancy's the technique was just not adopted by the nvidia, ati etc. would have saved a lot of messing around...
Quote:Original post by Lutz
In some blending modes you don't have to sort transparent objects.
In my current project I draw clouds with blend mode (GL_ONE, GL_ONE_MINUS_SRC_ALPHA), i.e. the pixels in the frame buffer are not attenuated. I found that it looked better than (GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA). When you use GL_ONE, it doesn't matter in which order you draw the transparent stuff since everything is just added to the pixel, so order is inimportant.
That's not true,(GL_ONE,GL_ONE_MINUS_SRC_ALPHA) is order dependent. Just work out an imaginery example with two pixels writing in the frame buffer, and you see that the order is important. I think that the order is not important only if you multiply the destination with a constant value, like GL_ONE or GL_ZERO. For example, (GL_SRC_ALPHA,GL_ONE) is order-indepedent.
Quote:Original post by aleks_1661Well why the hell not! They are dumb not to adopt such an obviously advantageous feature.
The graphics cards manufactured by powerVR use whats known as tile based rendering, by considering tiny portions of the screen at a time it can perform defered blending, where all the blending calcs are performed once all the polygon info is availiable, it removes the need for sorting transparancy's the technique was just not adopted by the nvidia, ati etc.
The only way to render order indipendent polys is to use an additive blend mode, this is the mode typically used for corona's, lens flare's and other effects that appear to glow. The blend just adds the colour information from the source to what has been rendered previously. (GL_ONE, GL_ONE_MINUS_SRC_COLOR)
The only down side of additive is rendering things like smoke becomes impossible since the darker a texture is the more transparent it appears, black portions of a texture will become completely transparent, where as 128 gray will appear as half translucent white. which is a bummer..
unfortunately you pretty much have to use some form of sorting. I use one of the stdlib sort routines these are highly optimised and perform quite well, i use qsort in particular, though i havent looked at the whole range, i think there are a few -
you have to write a function similar to the following to perform the comparison -
int comparePolys( const void *arg1, const void *arg2 )
{
/* Compare all of both strings: */
MyQuad* p1 = (MyQuad*)arg1;
MyQuad* p2 = (MyQuad*)arg2;
return (p1->depth == p2->depth)?(0):((p1->depth < p2->depth)?(1):(-1));
}
then use the a call similar to the following to sort them -
qsort( g_vertexArray, g_numPolys, sizeof( MyQuad ), comparePolys );
Happy particulating.... :-)
The only down side of additive is rendering things like smoke becomes impossible since the darker a texture is the more transparent it appears, black portions of a texture will become completely transparent, where as 128 gray will appear as half translucent white. which is a bummer..
unfortunately you pretty much have to use some form of sorting. I use one of the stdlib sort routines these are highly optimised and perform quite well, i use qsort in particular, though i havent looked at the whole range, i think there are a few -
you have to write a function similar to the following to perform the comparison -
int comparePolys( const void *arg1, const void *arg2 )
{
/* Compare all of both strings: */
MyQuad* p1 = (MyQuad*)arg1;
MyQuad* p2 = (MyQuad*)arg2;
return (p1->depth == p2->depth)?(0):((p1->depth < p2->depth)?(1):(-1));
}
then use the a call similar to the following to sort them -
qsort( g_vertexArray, g_numPolys, sizeof( MyQuad ), comparePolys );
Happy particulating.... :-)
Quote:Original post by mikemanQuote:Original post by Lutz
In some blending modes you don't have to sort transparent objects.
In my current project I draw clouds with blend mode (GL_ONE, GL_ONE_MINUS_SRC_ALPHA), i.e. the pixels in the frame buffer are not attenuated. I found that it looked better than (GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA). When you use GL_ONE, it doesn't matter in which order you draw the transparent stuff since everything is just added to the pixel, so order is inimportant.
That's not true,(GL_ONE,GL_ONE_MINUS_SRC_ALPHA) is order dependent. Just work out an imaginery example with two pixels writing in the frame buffer, and you see that the order is important. I think that the order is not important only if you multiply the destination with a constant value, like GL_ONE or GL_ZERO. For example, (GL_SRC_ALPHA,GL_ONE) is order-indepedent.
You are absolutely right! I always mix up source and destination blend factor.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
