Jump to content
  • Advertisement
Sign in to follow this  
Hawkblood

Logarithmic depth buffer/Infinite far clip plane?

This topic is 824 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I'm working with VERY large scenes (solar system size). I have recently read some info about "infinite far clip" (didn't understand it), and would like to know more about it. Also, I have been looking into logarithmic depth buffers but also didn't understand how to implement......

 

I've been getting around the vast render distance by a combination of clearing the z-buffer and doing a scaled-down render for far objects:

-first render the skybox (stars)

-sort all the visible objects into "depth fields"

-render all the farthest objects first

-clear the depth buffer

-render the next farthest

-repeat.............

 

It would be nice to not have to sort or scale the far objects.......

Share this post


Link to post
Share on other sites
Advertisement

But the old logarithmic or linear depth buffers hacks aren't a useful idea any more. They come with performance overheads and introduce rendering artefacts. You can get the same quality improvement by simply using a floating point depth buffer format instead of a traditional integer/fixed point format (floats have logarithmic precision by design).

Sure about that? If I recall correctly from what I understood in Kemen's paper, the issue with float depth buffers is exactly that they have far too many bits for very close range, and the curve then goes upwards far too steep, hitting the "useless" area or what he called it after some few hundred meters. His solution works for hundreds/thousands of kilometers (while still being able to discriminate close-up stuff with somewhat reasonable accuracy).

-first render the skybox (stars)

Why? ROP is a bottleneck (it's the slowest growing GPU resource). Admittedly, in a space simulation most of the screen is "empty" unless a big planet is in front of you, but still... why throw twice the amount of work at ROP for the areas where there are planets? Normally the skybox is always what you draw last.

(Well no... transparent stuff is what you draw last)

Share this post


Link to post
Share on other sites

You said "perspective matrix". Did you mean "projection matrix"?

 

I that "trick" you are talking about the "infinite far clip"?

 

@samoth

I draw the skybox first because I have to clear the depth buffer with each "depth field" using my current technique.

I have to clear the depth buffer, render without a depth test, and in order of far-to-near for the planets because if I don't there will be some cases where a moon will disappear within the geometry of its host planet. Currently, I am setting the far clip to 11,000, putting the planets/moons at 10,000, and scaling them using a distance formula....... This seems tedious and unnecessary. That's why I posted this topic.

Share this post


Link to post
Share on other sites

But the old logarithmic or linear depth buffers hacks aren't a useful idea any more. They come with performance overheads and introduce rendering artefacts. You can get the same quality improvement by simply using a floating point depth buffer format instead of a traditional integer/fixed point format (floats have logarithmic precision by design).

Sure about that? If I recall correctly from what I understood in Kemen's paper, the issue with float depth buffers is exactly that they have far too many bits for very close range, and the curve then goes upwards far too steep, hitting the "useless" area or what he called it after some few hundred meters. His solution works for hundreds/thousands of kilometers (while still being able to discriminate close-up stuff with somewhat reasonable accuracy).
Yes that's what happens with a normal perspective matrix (which is why you reverse it). With reversed near/far planes, Kemen shows that float32 is better than log24 but not quite as good as log32.

You said "perspective matrix". Did you mean "projection matrix"?
 
I that "trick" you are talking about the "infinite far clip"?

A perspective matrix is a projection matrix - one with a field of view.
There's also other kinds of projection matrices that don't have perspective - e.g. For 2d rendering.

No, infinite far clip is a different trick that allows your far plane to be at infinite distance away.

Share this post


Link to post
Share on other sites

Considering what I'm trying to achieve, what do you suggest? I would think an infinite far clip would be best for stuff that's really far away and do the swapping parameters trick for things that are relatively near..... right?

Share this post


Link to post
Share on other sites

Infinite far clip is not actually intended for this use case.  What it's actually for is geometry that needs to be projected on the far clipping plane, or extruded to infinity, with a classic example being stencil shadow volumes.  Despite sounding attractive, it actually suffers from the same precision issues as a standard perspective projection.  So while the far plane may be at infinity, that doesn't mean that you have a usable infinite range between the near and far planes; you still have the majority of your precision concentrated at the near plane and you still have the same number of bits asif you'd used a classic perspective projection.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!