 |
Author |
Topic: Transparent Z-Sorting (Read 677 times) |
|
skloopy
|
Transparent Z-Sorting
« on: Jun 5th, 2003, 5:07am » |
|
I'm not sure if this is a bug or not, but it seems like things drawn with above 50% transparency will not z-sort. Below 50% is sorted okay, so what is the reason for it shifting like that?
|
|
|
|
|
arielm
|
Re: Transparent Z-Sorting
« Reply #1 on: Jun 7th, 2003, 8:29pm » |
|
ryan,
(i'm helping the processing team in categorizing potential bugs in the graphics-engine...)
i could'nt reproduce the issue you mentioned... is it possible for you to post a simplified example that shows the problem?
thanks!
ariel
|
Ariel Malka | www.chronotext.org
|
|
|
benelek
 
|
Re: Transparent Z-Sorting
« Reply #2 on: Jun 8th, 2003, 2:39am » |
|
i don't know if this's what RYAN+SD meant, but the Contours sketch i just posted brought up the same issue for me.
i had an array of coloured lines drawn offset into the distance. i found that when i drew the closest ones first and then the further ones, the further ones were drawn over the closer ones.
i'm not sure if this problem arises out of the ambiguity of 2d/3d drawing modes and layering...
~jacob
|
|
|
|
|
arielm
|
Re: Transparent Z-Sorting
« Reply #3 on: Jun 8th, 2003, 9:19am » |
|
benelek,
(for the record,) the "contours" applet you mentioned is at:
http://proce55ing.net/discourse/yabb/board_Contribution_Automat_ed_action_display_num_1054967904.html
but i think it's a different issue, because ryan+sd mentioned problems with transparency (and apparently polygons) and you are mentioning problems with lines... and i suppose the 2 things relate to separate parts of the graphics engine...
the question is what the difference in term of z between the problematic lines in your applet (then, it could just be a problem of zbuffer resolution, solvable with a call to perspective())
if you think that you can reproduce the problem you mentioned (in a de-obfuscated, simplified test-case), please open a new topic in this board and we'll continue there.
thanks...
ADDED-LATER: well, it seems that it's a known bug that "single pixel lines have no alpha and no z"!
|
| « Last Edit: Jun 8th, 2003, 3:14pm by arielm » |
|
Ariel Malka | www.chronotext.org
|
|
|
fry
|
Re: Transparent Z-Sorting
« Reply #4 on: Jun 8th, 2003, 5:21pm » |
|
indeed, things with < 50% transparency won't have a z coordinate assigned for them.. this is less a bug than something that we'll need to figure out a solution for.
if we make everything drawn have a z value, you're going to have strangeness.. for instance, anti-aliased polygon edges are drawn using alpha. if you set the z value anywhere that an alpha-masked pixel is drawn, you'll get a crusty halo around the polygon, because especially below 50% transparency, one can barely see the pixels. so if two things are drawn overlapping each other this way, then there will be a large gap between the two shapes. that make sense?
i'll have to see what opengl does in this situation, and we'll just follow along with that. (ariel, could you make a note in the bugs db to have us check how opengl behaves on this issue?)
and benelek's issue does indeed sound like the single pixel line problem. carlos has some code coming up that should be fixing that soon.
another problem (as an aside), is that in general, alpha is imperfect in most 3D engines (this includes OpenGL, and probably DirectX), because it is based on the order in which objects are drawn. but we're not even dealing with that just yet.
|
|
|
|
|
arielm
|
Re: Transparent Z-Sorting
« Reply #6 on: Jun 8th, 2003, 9:45pm » |
|
thank you ryan!
|
Ariel Malka | www.chronotext.org
|
|
|
|
