Vega Strike Forums

I'm lost...
You mean we cannot render with GL_EQUAL while using a shader?
Or that somehow the z-buffer would be overwritten on second pass?
Or you mean that the shader needs to read z-info? If the latter, we could write the z value to RGB on the first pass (plus height field to A if we're planning to use texture offset), or even do this onto another render target that we use read-only on second pass, maybe. (I mean *in addition to* the z-buffer). Generally speaking, though, distance to the eye is too easy to calculate to be worried about accessing the z-buffer, unless I'm missing something...

It's "the latter". But doing that would add yet another render target.
Well... there could be a way with multiple passes per "deferred pass", but still, it's cumbersome and the more cumbersome the higher the overhead, and the higher the overhead the less effective the technique.

So... that's why I don't think it's useful, yet.

Yeah, sorry; I was editing my post still... So to repeat my new edit, why do we need to access z-info? We can easily recalculate z, or better yet, compute distance to the eye, and with more precision, to boot.

The "shading" pass is simply a screen-aligned quad that covers the entire screen, geometry-wise... textured with the output of the previous pass (the four render targets), that produces the final result.
The whole idea is not having to compute/process vertices again, which might be costly (for instance, lots of occluded geometry, or lots of vertex-shader stuff).
So... you don't have the positions of the vertices... only the pixels rendered on those 4 targets.

The first pass, even if rendering to 4 targets, is supposed to be überfast, because it only writes out shading parameters and performs no (or very few and inexpensive) computations, so culling is performed much faster than normal.

Gottcha. (Back to the drawing board...)

Hey, I wasn't even the first one to put landing gear in a Hellcat...