i created a program, that uses bsp-trees. I draw the polys from back to front without the z-buffer. I tested it also with front to back and the z-buffer, but that was about 50% slower!
However in many games you can select if you want to use 16 or 24 bit for the depth-buffer. So THEY use the depth-test.
Also i read in this forum, that Carmack uses something with stencil-buffer and the depth-test etc. so even he seems to use the depth-buffer.
However if i use it i have to use it all the time, not only when doing shadows or something, cause the buffer needs to collect the depthinformation about the rest of the world.
So should i use the depth-buffer or not?
I am a bit confused, because many people say, one should not use it, but everybody seems to use it.
if you don’t need the dept buffer at all turn it off. For the static bsp geometry you want z writes but you don’t actually need to compare with the x buffer. Basically draw your bsp with zbuffer but with the test being always pass (so you get the x values written). Then when you draw models for example and you need x testing turn the test function back to GL_LESS or whatever you want to do.
There are also other tricks that can help you save the clearing of the depth buffer every frame. Sortof like you described drawing back to front and the front to back swapping the comparison each time.
Hope this helps and happy coding.
PS and remember. Everything is a tradeoff between speed and quality. If your happy with the quality and its fast enough, then good enough get some sleep. ( :
Thanks for the tip, i really didn´t think, that you could only disable the testing, but letting gl write the values. That´s a really good idea, i will test it immediately.
I tested it yesterday.
It really works fine. Of course it is slower with the depth-buffer (using GL_ALWAYS), than without it, but the speed is ok. However compared to really using the depth-buffer (GL_LESS) it is much faster.
You are rendering back to front for not using depth buffer,
But, you performance will decrease because of state change overhead in larger levels which have surfaces that have many passes and use many small&big textures.
It’s better rendering in the order that minimise state changes.
I’m not sure why you render back-to-front, but my guess is that it is to avoid depth-testing (?). Actually, if you enable depth-testing and render front-to-back, most modern hardware will be able to throw away alot of rendering operations automatically, thus speeding things up considerably. Normally, rendering in any order (unsorted), will still give you better performance with depth-testing enabled.
It also sounds as if you’re not using hardware T&L (?), since you sort in view coordinates (?). Let the hardware do projection and modelview transformations for you.