Doom 3 engine release and game code

[Irritant]

[nbohr1more]

[mh]

The info I had was more the other way around - ATI were the ones with early-Z and NV without. That was based on a .plan from reasonably early in the development of the engine, so it may have been subsequently invalidated, of course. Doom 3 can't use early-Z anyway as it needs to keep the stencil test active for all stages of it's interaction render.

My current intentions for the engine are nothing; I have other priorities and I'm just playing around with the code in spare time. A possible goal is to write an ARB asm to HLSL converter and do a D3D port, but right now it's way off in the future, if at all.

[nbohr1more]

[mh]

That's quite a curious thread, with - unfortunately - quite a bit of conspiracy theory in it that is sadly reminiscent of some of the recent hoo-hah over Rage.

The only really relevant post is - I believe - the one you've quoted, but even that only tells a small part of the story. The nature of stencil test is that when it's enabled any form of early-Z won't work because stencil test comes after the per-fragment part of the pipeline, so whether it's z-pass or z-fail is irrelevant, there will always still be work to do (the same applies to alpha test and traditional depth testing). It's possible that an intelligent driver may be able to figure out from the stencil op that it can skip the stencil test under certain circumstances (e.g. with glStencilOp (GL_KEEP, GL_KEEP, GL_KEEP)), but that's driver-dependent and shouldn't be relied on.

Now, Doom 3 keeps the stencil test enabled for all of it's drawing: shadows, light interactions, old-style drawing (used for trans surfaces, skyboxes, some overlay effects, etc) meaning that the only thing you can rely on is the worst-case scenario, which is that early-Z won't work.

[Spike]

aye, if its actually testing the stencil buffer then you've already lost your early-z optimisation - its already rasterizing per pixel.

however, generating stencil shadow volumes doesn't test the stencil buffer, it only updates it, so for these passes, you should be able to keep any early-z optimisations on the condition that the first and middle argument of glStencilOp is GL_KEEP (zfail requires inc and dec for the front or back, while zpass has the inc/dec for the 3rd argument instead).
Its only the actual rendering which tests the stencil buffer, but in this case, the depthtest is also required to pass, so there's no reason for the stencil to be tested if its the depth will fail anyway, so early-z should apply for these passes without a problem.
for skys and unlit things, even if doom3 leaves stencil testing enabled, I would expect that it reset StencilOp to full GL_KEEPs and StencilFunc to GL_ALWAYS, both combined basically leave the stencil buffer untouched regardless of glEnables, so early-z testing should still apply.

Of course, hardware and drivers may have limitations that could give worse characteristics, but if they don't, I disagree with mh.
Zpass volume generation, where the stencil is only updated when the depth pass also succeeds should fully benefit from any early-z tests without needing to resort to specific pixels, while generation of z-fail volumes where the stencil is updated even if the depth fails will need to iterate over the pixels themselves.
Of course, this is pretty much a moot point as z-pass is faster anyway due to no front/back cap rendering. You'd only want to use z-fail where z-pass is inadequete anyway - any decent engine would want to use z-pass where it can. Any arguing would be over the amount of speed you can get by doing so (and whether its enough for it to be worth detecting if you can get away with z-pass).

Is the way I see it, anyway.

[mh]

Well a lot of it depends on the hardware; early-Z is part of neither the OpenGL nor D3D specs so drivers aren't even under any obligation to implement it at all (and an engine can definitely be set up to take advantage of it where possible/reasonable, but should never assume that it's there). Those that do may do so in any way that the engineers see fit, and that meets the actual requirements of the specs (most specifically that an early-Z optimization doesn't change the final output from the fragment/pixel shader).

A few of the earlier ATI papers on it that I've read seem to imply that it won't run if stencil test was enabled at all. That would indicate that they operated it on a coarser level than per-fragment (say, per-triangle or block of fragments - guess) and consequently it would have been possible for individual fragments to pass early-Z but still fail a real Z test. Other hardware may differ, but the key point remains that it is very hardware-dependent and so shouldn't be relied on.

One thing I found both amusing and annoying from that Beyond3D thread was the accusations of id deliberately nerfing ATI. Of course it's the case that if they hadn't implemented z-fail they would have had to do two passes, so what would have been gained from early-Z would have been lost from the second pass. All the more so as the first preload pass for when the view was inside the shadow volume still needed a zfail condition. And ironic because id had included ATI-specific code (the old two-sided stencil extension, as well as ATI_fragment_shader) so they shouldn't have even been accused of trying to nobble ATI.

[revelator]

[revelator]

[revelator]

[revelator]

[revelator]

guess peeps are busy with newyear

[leileilol]

I don't even own Doom 3 anymore. I would have tried this

[revelator]

aw

well i refined the code some more ill post changes later

[New Horizon]