#120518 - qw3rty - Sun Mar 04, 2007 9:31 am
I'm trying to draw two transparent objects in front of each other.
Their transparency doesn't combine as expected though - some parts are more transparent than others(the change in transparency happens at the triangles borders)
Both transparent objects have an unique POLY_ID (otherwise only one of them is drawn, if they overlap).
One of the objects isn't textured, the other is (but I tried it with both objects textured and there was no difference.)
Sometimes it happens that they cross each other, but that doesn't seem to be connected to the issues I am experiencing.
P.S. : I'm trying to do ploygon-transparency, not transparent textures.
#120561 - gabebear - Sun Mar 04, 2007 6:43 pm
This just seems to be an oddity of the DS hardware. I'm not sure how exactly the DS sorts translucent polygons; GBATEK says you can enable "Translucent polygon Y-sorting" or just sort them yourself. libnds uses y-sorting.
Y-sorting messes up at odd time at polygon boundaries. The fix here is to switch to manual sort mode by replacing your glFlush(); calls with GFX_FLUSH = 1;. Whatever you send to the gfx engine first will be "behind" whatever you send later. GFX_FLUSH = 1; doesn't effect how solid polygons are drawn.
If you don't know which object is closer to the camera you can use a position test to get the distance of a point from the camera. The postest stuff is only in CVS right now and the only example that uses the position test is the 3D Picking demo which is in the CVS examples.
I'll extend glFlush to turn y-sorting on/off in CVS. I guess there should also be an example explaining translucent polygon sorting.
#120599 - qw3rty - Sun Mar 04, 2007 11:20 pm
So, if I want multiple transparent surfaces in front of each other, I have to completely disable depth-test ?
In my project I draw MD2-models (quake2), that are swimming on one of my transparent surfaces (water) - some parts of them are under the waves.
Would that mean I'd have to draw the MD2's in parts (parts behind the water, then water, then parts in front of water)?
That would be a pain in the ass ! :O
(Or even impossible - some triangles would be both - in front and behind the waves !)
P.S. : would using a semi-transparent texture work with depth-testing ? (e.g. GL_RGB32_A3)
#120604 - Payk - Sun Mar 04, 2007 11:46 pm
Hmhmh thats odd
#120627 - qw3rty - Mon Mar 05, 2007 1:42 am
What's odd ? that my models are partly underwater ? seems realistic to me ;)
#120650 - sajiimori - Mon Mar 05, 2007 4:24 am
As far as I know, there are only 3 hardware features to mix&match to try for the best (or least bad) results in each case.
- Z-write threshold: How opaque a pixel must be before it causes the Z buffer to be updated.
- Polygon IDs.
- Auto versus manual sort. Use manual for more stable behavior. Unstable is even worse than incorrect.
In all cases, pixels are not displayed if they have a Z value that's beyond the current value in the Z buffer. As far as I know, there's no option to change this behavior, except a bit that determines what happens when the Z values are exactly equal (which is not the issue here).
If you have an opaque object standing half-way in water, draw the water last and it'll look fine. If you draw all translucent objects after all opaque objects, it'll always look right... until translucent objects overlap.
If you have a translucent object standing half-way in water, then yes, the only way I know of to make it look correct is to cut the polys. Personally, I'd set the Z-update threshold so the water causes Z updates, give the water and object separate poly IDs, then draw the object after the water. You won't be able to see the submerged part of the object, but splitting polys at runtime is not generally practical.
#120667 - qw3rty - Mon Mar 05, 2007 11:01 am
Hmmm.... I guess I'll be alright without multiple transparent surfaces.
(I want the submerged parts of the ships to be visible)
What about texture-alpha ? (GL_RGB32_A3)
Do they work with without any additional logic ?
(I'm currently at well over 90% CPU-time, so I can't include much additional code in the renderer, at least not at 60 FPS)