[Public WebGL] determining depth of z-buffer

Steve Baker [email protected]
Wed Feb 2 16:20:15 PST 2011

Argh!   I forgot about that!

The alternative is just to turn off Z-testing and Z-writing and draw the
sky before anything else on the screen.

   -- Steve

On 02/02/2011 05:53 PM, Ben Vanik wrote:
> Awesome tricks, Steve.
> Unfortunately I think gl_FragDepth isn't supported in GLES/WebGL,
> though, so the last trick isn't easily doable ;(
> --
> Ben Vanik
> http://www.noxa.org
> On Wed, Feb 2, 2011 at 4:02 PM, Steve Baker <[email protected]> wrote:
>> On 02/02/2011 04:03 PM, Giles Thomas wrote:
>>> You may already be familiar with this trick, but just in case: if
>>> you're finding that the depth buffer's not deep enough to handle your
>>> scene's level of detail (say, skybox/sphere 10,000,000,000 units away,
>>> Sun 100,000,000 units away, planet 90,000 units away and spaceship 0.1
>>> units away), you can avoid having to worry at least about the distance
>>> of the sky by drawing it at -- say -- half the far clipping distance
>>> and then clearing the depth buffer so that whatever you draw next will
>>> wind up on top of it, using gl.clear(gl.DEPTH_BUFFER_BIT);  I did
>>> something like this in my (long-unupdated)
>>> <http://learningwebgl.com/spacelike/>
>>> In general, I think (experts please correct me if I'm wrong here!)
>>> that if you have various objects at very distinct bands of distances,
>>> where no object intersects two bands, you can draw each band, most
>>> distant band first, closest last, using a different projection matrix
>>> each time -- same fov and aspect, but appropriately-adjusted near and
>>> far clipping distances -- thus being able to get maximum use of the
>>> depth buffer's precision each time.  You just need to clear the depth
>>> buffer after each band, so that each closer level is always drawn on
>>> top of the previous one.
>>> This is something I've inferred from lots of reading rather than read
>>> specifically, however, so it could absolutely standard practice, with
>>> a well-known name that I just don't know, or it could be utter
>>> nonsense.  Or possibly some combination of the two.
>>> Cheers,
>>> Giles
>> That technique is often called "depth stripeing" or "depth stripping".
>> It works OK for simple renderings but having to clear the Z buffer
>> between passes is problematic if you want to use the Z buffer for
>> something else afterwards.
>> Another trick I've used is to draw small, nearby objects N times too big
>> and N times further away than they really are.   That lets me push the
>> near clip plane much further away - which improves Z precision immensely.
>> The simulator we built to train US "Predator" drone aircraft pilots does
>> this.  The Predator's camera has a phenomenal zoom factor so it can see
>> things tens of miles away like they were right next to you...but it can
>> also see parts of the aircraft itself that are mere inches from the
>> camera!   This is horrible for Z-buffer precision - so we cheat and draw
>> the aircraft somewhere between 'actual size' and 100 times too big
>> depending on altitude.   You can build this into the vertex shader so
>> the rest of your software doesn't have to do anything special.
>> For things like the "sky ball", you can change the fragment shader to
>> write a specific, known value to the Z buffer rather than using the
>> hardware interpolated value that comes from the vertex shader.  That
>> allows you much more control over how close you can push it out and
>> prevents it from "flimmering" as you induce different roundoff errors
>> when you move the camera around.
>> There are a LOT of tricks out there.
>>  -- Steve
>> -----------------------------------------------------------
>> You are currently subscribed to [email protected]
>> To unsubscribe, send an email to [email protected] with
>> the following command in the body of your email:
>> unsubscribe public_webgl
>> -----------------------------------------------------------

You are currently subscribed to [email protected]
To unsubscribe, send an email to [email protected] with
the following command in the body of your email:
unsubscribe public_webgl

More information about the public_webgl mailing list