Forum archive
Nasty little bug with transparent surfaces
- I have found that when you're looking through stuff like glass sometimes certain sprites disapear. I wonder if this has anything to do with the way it handles transparency.
are you (Jonof) aware of this bug and do you know how to fix it? - JonoF and I know about this problem. Let me explain why it happens: OpenGL modifies the Z-buffer for translucent sprites in exactly the same way as opaque sprites. So if a translucent sprite in front is drawn first, then anything behind it will be invisible because the Z-buffer clips them off. The obvious solution is to sort the sprites better, but this doesn't solve everything because sometimes sprites intersect each other. Because of this, the only way to draw sprites in back-to-front order properly is to split the sprite planes into pieces. This, unfortunately, requires a system that's much more complex than what I'm currently using. It's something that's been on the back of my mind for a while, and I do plan to implement it when I get around to it .. in other words, WID ; )
And this occurs also with voxels?
If I use voxels, and I look at them through a window, will the bug still possible? What's about Zculling and other functions who could let duke3d a bit slower? There must be other methods aside of splitting sprite planes? (well, normal sprites shipped with duke3d don't have more than one plane anyway..they're flat)
Thanks :)Nasty little bug with transparent surfaces
If I use voxels, and I look at them through a window, will the bug still possible?
Voxel objects do suffer from a similar sorting problem. However, in 8-bit classic mode (which is the only mode that supports voxels), the bug has a different effect. In classic mode, if a translucent plane in front is drawn first, then all the sprites drawn later (even if behind it) will be at full brightness instead of being "blended" with the translucent plane (when applicable).What's about Zculling...
I'm not exactly sure what you mean by "Zculling". You'll have to explain it.well, normal sprites shipped with duke3d don't have more than one plane anyway..they're flat
If all sprites were face sprites (our cardboard cut-out friends), then life would be wonderful because all planes would be parallel - and therefore not need splitting. Build, however, has wall sprites, floor sprites, and masked walls (which are really just wall sprites).I understood, thank you :)
I'm really loving this topic.
For about culling, sorry I didn't mention the quake2 optimizating commands people used to do with opengl: z_trick and cull. I've referenced both.
Anyway, it may not be the real thing we're searching on... the problem is in a upper hierarchy, the way the function was implemented.
Is it that hard to re-edit opengl libraries in order to not let it modify zbuffer for depth information?
But why quake didn't have those problems? Is that mainly because Quake and engines alike does not use sprites? (and that's why I retired myself from editing it). I'm now on the nostalgic duke3d levels like a quick rabbit, making replics of real places like my new university, however a true sector over sector absense is still a real gap. Not to mention the rapid development of others engines like Crystal Space.
(Nevertheless I love solving hard problems and amazed with voxel library - the new world)
Thank you :)