1st - If once the opengl is enabled, where does the first fragment compared to if the depth buffer is still empty?

Just re-iterating and re-wording:

The depth buffer usually works as a shortcut to see if something should be drawn or discarded. It has several options:

* NEVER (don't draw)

* ALWAYS (always draw)

* EQUAL (draw if the values are exactly equal)

* LESS (draw if the value is smaller than what exists, and store this new smaller value)

* LEQUAL (draw if the value is smaller or equal to what exists, and store the new value)

* GREATER (you get it...)

* GEQUAL (Greater or equal)

Generally games will not explicitly clear the depth buffer. Instead they set the flag to ALWAYS and draw their skybox or draw a distant plane, thus obliterating whatever was stored and setting a new maximum depth.

The depth buffer can be used for other tasks as well as depth. You can use depth images, or pre-computed depth fields, to mix and match 3D worlds with pre-rendered 2D images by drawing a pre-rendered image and telling the depth buffer what pre-computed depths they represent. You can use depth buffers to help compute fog or atmospheric scattering or depth-of-field distortions.

As for how the depth number is determined, there are many methods. You can change the values that get used inside your graphics shaders or compute shaders.

Because of the magic of floating point, smaller numbers are more precise than bigger numbers. The sliding scale of the decimal point (hence "floating" point) means the tiniest numbers have the greatest precision. Each time it floats bigger, the precision drops by half. Floating point precision operates at logarithmic scales.

That means that the nearest items usually have high precision, but distant items can suffer from "z-fighting", where planes that are touching each other will shimmer and shift between the objects as the camera and models moves.

To counter the sliding precision, people have come up with many different ways to compute the depth values.

You can use the simple calculation of (object depth / view frustum depth). That is normally the default that happens if you didn't provide a custom value. Some programs will store the inverse of that distance, termed a 'w-buffer". Some programs will use a logarithmic z value, basically reversing the logarithmic nature of floating point turning it back to a roughly linear scale. Some programs will use different algorithms that suit them better.

The value that you store and compare against is up to you.

Are you sure this is still the truth? With all modern GPU having Hi-Z, I know at least ATI(AMD) has fast Z clear IIRC using Hi-Z buffer. I would think drawing the skybox last will potentially save alot of fill depending on how much of the sky is visible.

Ah, the joys of constantly-changing graphics hardware.

Looks like yet another change, where an older best practice is replaced.

I'm glad I'm not a graphics-centric engineer because it seems every few years it flips itself on its head; the old best practices are discouraged, the old practices to avoid become recommendations.

From some of that reading you linked, if your graphics card has a compressed z-buffer, use a clear operation since it will drop the compressed blocks. if you are using an older card without compressed Z-buffer, overwrite rather than clear since a clear resets the value to a specific depth and then you'll immediately overwrite it with new depth data.

And if you're targeting cards in between, implement both.

If you implement only one or the other, you're doing it wrong on the opposite era's cards.

Isnt this on eye space? I must have confuse on how depth buffer works on depth precision. All in all my real confusion was on the depth precision it self. Which happens first? is the the test or the equation for depth precision?

Normally it is a value between 0 and 1, mostly this stems from the nature of floating point.

At the point in the pipeline it is happening the pixel fragment is generally relative to the view frustum, a value from 0 to 1.

The task for comparing against the z-buffer is simple enough. The pixel fragment's depth value is compared against the z-buffer using the selected operation (any one of <, <=, ==, !=, >=, >, true, false). If the result is false the pixel fragment is discarded and processing stops. if the result is true the z-value is written to the z-buffer, and processing continues.

As for what happens first, that gets a little tricky.

From a high level perspective, the test against the z-buffer happens toward the end of the graphics pipeline: Everything is sent to the card to be rendered. The vertex shader is run, which can do tasks like skinning and transformation, basically moving stuff around. The hull shader is run that can break down line segments into smoother curve segments. The tesselator runs to connect all the tiny line pieces. The domain shader is run, and it can calculate the final position of each vertex point. The geometry shader runs next and can further modify what vertices are actually drawn. The pixel shader runs and can modify color and depth information. Conceptually the z-test runs here, as described above. Assuming the z-buffer test passes, the pixel fragment is passed along to be merged with other values. Finally, output of all the rendered pixels are merged together and generate a full final image.

In practice, there are several tricks and optimizations that hardware can do to make the test happen much earlier. The hardware can peek ahead at the shaders being used.

If the hardware can see that the pixel shader does not modify the z-value, it can run the test before the vertex shader eliminating what is normally the most expensive shader.

If the hardware can also see that the geometry shader does not modify z-value, it can run the test that much earlier and avoid the work if the test fails. If the hardware can also see the domain shader doesn't affect the z value, it can be bumped again. Repeat for each shader.

That part happens automatically.

There are methods (I am not fully read up on them) to run an early depth-only processing pass. Basically it runs to transform all the geometry but does not do any of the more expensive lighting or coloring operations. That information is used to perform earlier or more reliable depth tests in the second pass.