Sign in to follow this  
godmodder

Screendoor transparency

Recommended Posts

godmodder    828
Hi, I want to render transparent objects in my scene, but sorting is out of the question. Does anyone know of any methods to draw transparent objects without sorting the entire scene back-to-the-front? I was looking into the Screendoor Transparancy technique, but couldn't find much information on it. Does anyone know how it works? I think I have to do something with GL_POLYGON_STIPPLE but don't know what exactly. Thanks for your help, Jeroen

Share this post


Link to post
Share on other sites
swiftcoder    18432
You could do it like that, first draw all solid geometry normally, then draw the transparencies in two passes, I don't see any reason why it wouldn't work.

I just rendered all my geometry in two passes when I used the technique for a small test app, so I don't know for sure.

Share this post


Link to post
Share on other sites
Farraj    152
Just checking (because no one said anything)

This '2-pass' trick of yours works with the Blend() function, right?

I've been having the same problem. But I couldn't find a way. I sort of had the same idea, but I didn't know how I was souppose to go about it.

Share this post


Link to post
Share on other sites
Farraj    152
nope, doesn't work -_-'

the texture is drawn to the right depth, but although it's transparent you still can't see what's behind it due to the quad drawing in the 1st pass.

Last check, is there really no way to draw a transparet or masked texture without 'Disable()ing' the 'DEPTH_TEST'???

Share this post


Link to post
Share on other sites
Specchum    242
Quote:
Original post by Farraj
Last check, is there really no way to draw a transparet or masked texture without 'Disable()ing' the 'DEPTH_TEST'???


Instead of disabling the entire depth test, just try disabling writing to the depth buffer : glDepthMask(GL_FALSE)

Share this post


Link to post
Share on other sites
Farraj    152
I just finish googling 'glDepthMask()'

I never knew that there was such a thing :D

It draws the transparnt object naturally like any other 3D object but without saving it's current depth in the depth buffer (z-puffer??)

Now that's what I call using your head. :P

Although, I still don't understand why use only GL_FALSE to change the depthmask from one state to another and back?

Oh well :P

thanks Specchum.

Share this post


Link to post
Share on other sites
__ODIN__    479
Just disabling DepthMask isn't going to get you the results you're looking for; if you rotate around a bit, you'll quickly find solutions where the draw-order breaks up.

Your best bet is to draw opaque and alpha objects in seperate passes, sorting alpha objects by depth, and disabling Z-write on them when rendering.

Allan

Share this post


Link to post
Share on other sites
Kalidor    1087
Quote:
Original post by godmodder
...
Does anyone know of any methods to draw transparent objects without sorting the entire scene back-to-the-front?
...
There's no need to sort the entire scene. __ODIN__ has it right, I'll explain in a (very) little more detail.
 - Enable depth testing and depth writing
- Render all opaque objects (order doesn't matter here)
- Disable depth writing
- Render all transparent objects from back to front

Share this post


Link to post
Share on other sites
RDragon1    1205
How come you guys disable writing to the depth buffer. Is that simply an optimization to eliminate the writing?

What happens when, for instance, you have two quads that are translucent, and they intersect each other - meaning part of each quad is behind and in front of each other?

Share this post


Link to post
Share on other sites
lynedavid    122


Using multisample transparency can be things a whole lot more easy!

Only problem with this method though is that you will need anti-aliasing enabled for it to work. Also, I dont think its supported by ATI cards (though i could be wrong about this).

Share this post


Link to post
Share on other sites
Kalidor    1087
Quote:
Original post by RDragon1
How come you guys disable writing to the depth buffer. Is that simply an optimization to eliminate the writing?

What happens when, for instance, you have two quads that are translucent, and they intersect each other - meaning part of each quad is behind and in front of each other?
For the most part, turning off depth writing is just an optimization. But it's also for the cases that you are asking about, overlapping or intersecting objects. If you leave depth writing on, then the part of one object that's behind or inside another object will not be rendered at all, which is not what we want. Let's take a little example...

Say you have two objects, ObjA and ObjB. You determine through your sorting routine that ObjA is "in front" of ObjB (how that's determined doesn't matter for this example). The problem is that part of ObjA extends further back into the scene such that it is behind ObjB. If we leave depth writing on, that part of ObjA will fail the depth test when it is tested against the depth from ObjB and it won't be rendered. What "should" happen is that the part of ObjA that is behind ObjB should be rendered first so that it doesn't blend with ObjB, then ObjB should be rendered so that it blends with that part of ObjA, then the rest of ObjA should be rendered.

There are two ways to fix this, splitting the object or depth peeling, neither of which are very viable for an application where performance is key. What's usually done is that this problem is just ignored since it is pretty rare, especially once you have collision detection and response implemented.

Share this post


Link to post
Share on other sites
Ademan555    361
My understanding is that alpha TESTING creates two results, RENDER or DONT. Ie it acts like an alpha map with alpha blending with either 255 or 0. I suppose that could work for you, but from what i gather, its probably not what you want. May i ask, though, why you're unable to sort your geometry? For small scenes you can generally sort pretty fast, and also, you can skip the squareroot in the distance function, because we KNOW if A > B then sqrt(A) > sqrt(B) which means you can compare the squares of the distances between objects and the viewpoint, and get the same order, and it should be far faster. And if this is a particle system or somethign with millions of particles or similar... you probably dont hafta worry much about sorting because there will be so many it probably wont matter if its exact in its order.

cheers
-Dan

cheers
-Dan

Share this post


Link to post
Share on other sites
RDragon1    1205
Quote:
Original post by swiftcoder
Quote:
Original post by Ademan555
we KNOW if A > B then sqrt(A) > sqrt(B)


Only if A and B are not less than 1 [grin]


Since A and B are the square of some number in this case, I think that's safe to assume [grin]

Share this post


Link to post
Share on other sites
Specchum    242
Quote:
Original post by RDragon1
Quote:
Original post by swiftcoder
Quote:
Original post by Ademan555
we KNOW if A > B then sqrt(A) > sqrt(B)


Only if A and B are not less than 1 [grin]


Since A and B are the square of some number in this case, I think that's safe to assume [grin]


Only if the original numbers that A & B are squares of are >= 1. :D

Share this post


Link to post
Share on other sites
l0calh05t    1796
Quote:
Original post by lynedavid


Using multisample transparency can be things a whole lot more easy!

Only problem with this method though is that you will need anti-aliasing enabled for it to work. Also, I dont think its supported by ATI cards (though i could be wrong about this).


Go here and scroll down to alpha to coverage http://www.humus.ca/index.php?page=3D

it's actually pretty much the same as screen-door transparency, just on a sub-pixel level.

and it works on ati cards.

Share this post


Link to post
Share on other sites
Aragon    144
at directx with the colorkey thing
i was able to tell that
parts of texture that fits to colorkey value
not drawn..and the Z Buffer also not
that was true colorkeying

at moment with alpha stuff in opengl
the colorkey parts are invisible (thats ok) but the Zbuffer
of whole rect is painted,even the invisible parts/pixels

how to prevent this?

(i do not use glut,glaux ,shader stuff)






Share this post


Link to post
Share on other sites
Kalidor    1087
Quote:
Original post by Aragon
at directx with the colorkey thing
i was able to tell that
parts of texture that fits to colorkey value
not drawn..and the Z Buffer also not
that was true colorkeying

at moment with alpha stuff in opengl
the colorkey parts are invisible (thats ok) but the Zbuffer
of whole rect is painted,even the invisible parts/pixels

how to prevent this?

(i do not use glut,glaux ,shader stuff)
This probably should have been a new thread, but it's a simple answer.

Use alpha testing. Enable it (glEnable) and set the alpha function (glAlphaFunc). Set it so that whatever you want to end up in the depth buffer passes the alpha test (ie: any fragment with alpha greater than 0.0).

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this