View Full Version : Quake3
09-05-2000, 10:42 AM
i read that Q3A sorts polys by texture. I was wondering because after this the depth sort provided by the bsp tree needn't to be valid or i'm wrong? Does Q3A use a Z Buffer or how is the depth sort accomplished ?
Thanks in advance
09-05-2000, 11:23 AM
Quake3 uses multiple levels of sorting. First off, all polys are sorted by shader. The shaders themselves are sorted to the first order by implicit or explicit sort type. I would assume the opaque shaders are sorted to the Nth order by way of textures used. The opaque polys are drawn into the z-buffer (unless disabled by a given poly's shader). For those polygons that end up in the sorted transparent set, they are sorted to the second order by depth. They are then drawn back to front into the color buffer only, but still using z-buffer testing. Note: The transparent polys of the world actually come out in the proper order and require no sorting. But since you have to allow for the possiblility of temporary or dynamic transparent polys, i.e. arbitrary transparent polys, the transparent set must be depth sorted (unless you happen to know they are already in order).
09-05-2000, 09:45 PM
From what I've heard, the BSP is used to render the scene with only z-buffer writing. That the z-buffer was only tested when drawing the models. I would imagine that the texture sorting would only be from the potentialy visible set defined by the BSP.
But this is a generic rule for BSP engines, I dunno about Quake3 specificly.
09-06-2000, 04:57 AM
Well of course it only sorts the shaders that are used, and then at that, most of the shaders will not need resorting ever again (unless the client loads a new shader). After all shaders that are used in the game are sorted, Quake3 appears to chain together the shaders used in each frame. The only sorting then is the depth sorting of the transparent polygons and then only if a temporary (explosions, blood, etc) or dynamic (mover or player) transparent polygon is in the view frustum.
The PVS only helps narrow down which polygons of the world will be clipped against the view frustum. It has nothing to do with the sorting of shaders or polygons.
And in general, Quake3 defaults to always testing Z (this is essentially free). Some shaders do turn off z testing, or change the test used however. But most shaders leave z testing turned on and using the standard less than or equal test. Of course the z-trick flips the test each frame but that fact remains hidden from the shader creator.
Also, it may be the case that Quake 3 overrides the shaders' z test setting when drawing the opaque polys of the static world (aka world model 0). I'm not sure of this since I haven't really checked in detail yet.
But it certainly makes sense to do that when using a software renderer (which Quake3 does not in general ever use, though you can force it to use a software renderer).
[This message has been edited by DFrey (edited 09-06-2000).]
09-06-2000, 09:04 PM
thank you for your replys.
you said that z buffering is essentially free. I have less knownledge about hardware acceleration. Could you explain it to me why z buffering is almost free ?
09-06-2000, 09:17 PM
Depth buffering is usually free or low cost because the hardware is designed to perform the operation in parallel with other operations. There is silicon designed to perform the test which might be redundant and therefore idle if you don't depth test. The same is sometimes true for other types of test like stencil and alpha but it's dependent on the implementation. It is not the case that it is always completely free however. There is additional memory bandwidth used when depth testing which is probably the biggest issue on the fastest modern hardware. You need to read the depth buffer value from the framebuffer, and you usually need to write the new value if the depth test passes, but in general it's nowhere near the performance penalty you used to see in a software engine.
I don't know if you're aware but Quake (1) was depth buffered, but not all tested. Carmack wrote depth values for all wall geometry with no tests because it was sorted anyway. He then depth tested the monsters against those values to resolve their visibility. It works a treat too.
09-07-2000, 06:00 AM
markl: dorbie explained it pretty much spot on. I would add, that the newer high end video cards that use DDR memory really can make z buffering free since the video logic can write to the frame buffer at the same time it is reading from the z buffer (and vice versa). Making the time spent on z testing vanishingly small since it can be done is parallel with frame buffer writes.
09-07-2000, 06:13 AM
Tilers and deferred renderers / scene capture cards don't have that big bandwidth problem.
As a software programmer you must know the hardware you're working for, it's good and bad points to avoid doing things wrong.
Do not think that because you're a software programmer you don't have to have a deep knowledge of Hardware, it's untrue and will cost you huge amounts of time to solve the problems/slowndowns.
Dunno about z-buffering on modern hardware but on my rage128 disabling z-buffering gave me a speed increase of 20FPS!!
09-07-2000, 10:27 PM
I agree with my PII 400 and TNT graphincs card I get between 18% and 25% speed improvment when I disable the Z-buffer.
>I agree with my PII 400 and TNT graphincs card I get between 18% and 25% speed improvment when I disable the Z-buffer.<
Yup but I forgot to mention that the speed decrease without texture sorting is another dimension....Without sorting by texture your engine wonīt get any FPS anymore if you have many big textures....And there is no way: Either you render with the bspīs back to front order OR you sort by texture.....Would be interesting how Carmack solved that problem in Quake1(Perhaps he disabled z-buffering for the static world only in the software-modus where texture changing doesnīt matter too much?)?
[This message has been edited by XBCT (edited 09-09-2000).]
Powered by vBulletin® Version 4.2.3 Copyright © 2016 vBulletin Solutions, Inc. All rights reserved.