Sign in to follow this  

Handling huge depth range spans

This topic is 3040 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

Hi folks, I'm working on an indie game where the players will be able to drive and fly vehicles from the ground and all the way into space. We have a global terrain model and the visual range will be all the way to the horizon. Now, when the player moves around by foot on ground, this is OK, the far clipping plane will generally not be that far out, but when the player enters a vehicle and flies high up, we need to have the near clipping plane close enough to not clip the cockpit geometry and far enough to reach the horizon, which can be very far if we're high enough. Needless to say, this is bad for z buffer precision.... Now, we've tried splitting the scene so that we render the far objects first, then clear the z buffer and render the near objects on top. This works most of the time, but we have some cases where objects from the "far" group will stretch into the near group, typically very large objects. Then we may have smaller objects from the "near" group that should have been behind parts of the large object, but still will be rendered in front of it. I just wondered if some of you had worked with similar problems before, and if you have some clever ideas to solve the problem of huge z distance spans. Cheers

Share this post


Link to post
Share on other sites
I've just recently experimented with logarithmic z-buffer for exactly the same reasons. It works quite nicely, although it has some problems of its own - it requires a finer tessellation to avoid artifacts when one vertex is behind the camera.

[Edited by - cameni on August 19, 2009 1:07:24 PM]

Share this post


Link to post
Share on other sites
@Waterwalker. You're right, I can render those objects twice :-) However, I would really like a different solution than splitting the scene. I get a lot of overhead since I use cascading shadow maps and need to calculate shadow maps for both zones.

@cameni: The logarithmic z buffer looks like just what I need! How do you implement this in practice? I use OpenGL so I guess I have to introduce this calculation in all my fragment shaders? Or is there another clever way to insert it right after the projection step?

Share this post


Link to post
Share on other sites
Hmm, if the near geometry is something like a cockpit or whatnot, why not render the planet with near/far planes adjusted for it's range (near plane just before the planet's surface starts, far plane set to the calculated horizon), then clear the depth buffer, adjust your near/far planes for your cockpit geometry (probably static values here) and draw the cockpit.

You're guaranteed never to have anything overlap with your cockpit and for it always to be in perfect precision in terms of depth.

Just my 2c.

Share this post


Link to post
Share on other sites
I had a similar situation with cascade shadow mapping. I simply split the view frustum to 6 smaller frustums and render the whole scene 6 times with adjusted projection matrices. I'm not using any optimizations yet (for example frustum culling), since my application is so fill rated, and I only loose lot of fps because the 6 shadow map rendering passes, without SM the slowing down is hardly noticeable.

Share this post


Link to post
Share on other sites
Quote:
Original post by tsevalHow do you implement this in practice? I use OpenGL so I guess I have to introduce this calculation in all my fragment shaders? Or is there another clever way to insert it right after the projection step?
I had to put the calculation in all vertex shaders, just after the transformation comes the equation that manipulates z.
z = log(C*z + 1) / log(C*Far + 1) * w
The 1/log(C*Far+1) is constant and can be baked into the projection matrix.

Share this post


Link to post
Share on other sites
Hi again,

I tried the logarithmic z function and that seemed to work nicely! However, it seems that it shifts the entire scene in the z direction? This means that my frustum culling fails on close objects, because the near clipping plane seems to be in another place than expected.

The frustum culling is done before the projection matrix is applied, the log z transform is done after projection. Am I doing something wrong here, or is this as expected?

Share this post


Link to post
Share on other sites
Quote:
Original post by tseval
I tried the logarithmic z function and that seemed to work nicely! However, it seems that it shifts the entire scene in the z direction? This means that my frustum culling fails on close objects, because the near clipping plane seems to be in another place than expected.

I'm not quite sure what you refer to. The equation for logarithmic Z itself only uses the far plane distance. Can you post the parameters of your frustum etc?

Share this post


Link to post
Share on other sites
I can adjust the near clipping plane in the frustum culling to avoid the problem, but I also ran into the interpolation problems mentioned on cameni's blog, so I went back to the split scene solution for the time being.

However, I was wondering if this could be done per fragment instead of per vertex? Wouldn't this eliminate the interpolation problem?

@cameni: The problem was that all objects close to the camera were culled by the near clipping plane in the software frustum, indicating that the z coordinate before projection was closer to the screen than the modified depth coordinate in GL.

Share this post


Link to post
Share on other sites
Quote:
Original post by tseval
However, I was wondering if this could be done per fragment instead of per vertex? Wouldn't this eliminate the interpolation problem?
That's what Ysaneya did - see in his journal. I was going to test it but he did it sooner [smile]

Share this post


Link to post
Share on other sites

This topic is 3040 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.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this