# 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.

## 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 on other sites
Render the overlapping objects twice, the near and far plane will take care of clipping the corresponding parts and write the correct parts into the corresponding depth buffer.

##### 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 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 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 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 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 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 on other sites
Quote:
 Original post by tsevalI 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 on other sites
Quote:
 The frustum culling is done before the projection matrix is applied

but it's implemented in software, so you can just set your frustum near plane at the camera origin (zero distance) and it will fix the problem

##### 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 on other sites
Quote:
 Original post by tsevalHowever, 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 on other sites
Great, thanks! I'll check it out

##### 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.