Clipping planes

[Ian]

In the viewport header there are 2 values for a near/far clipping plane, but they are never passed to the hardware (always zero). Presumably they are calculated from the data set itself.
There are 4 viewport priorities, and the depth buffer is wiped between each priority layer. This means that because the layers are not depth tested against each other, each layer can have it's own near/far value pair.
I found in ECA and harley, really each layer needs a different value pair, as the sky is drawn at a distance in the millions, and the 2D stuff at a distance between 0-1. You can't represent such an extreme range without some sort of z fighting with a single near/far value pair.

To calculate them .. originally I did a min/max on the entire data set every frame. It worked giving accurate Z values, but was too expensive. But given the discovery of the node distances, we can now do this extremely fast.

Calculating the far plane is super easy from the node distances, you just find the max distance of a node, either fully inside of traversing the view frustum. Calculating a near plane is much more complex and I struggled with it. I tried just getting the min value of nodes fully inside the view frustum, this worked most of the time, but geometry which was also traversing the front clipping plane, that should have been visible wasn't.

Anyway I had a different idea, how the hardware might be doing it. Basically just getting the 'scale' of the scene from the top level nodes. If we know scale, ie the max distance is 1000 we could probably guess a near plane. My thinking currently is something like

Code: Select all

Near     Far
0.01     100
0.1      1000
1        10000
10       100000
100      1000000


[Ian]

This is the max values for each viewport priority layer for harley (at the start)

layer max 340282346638528860000000000000000000000.000000 -728656.312500 -13681.853516 -33.273438

First one is isn't used
-728656.312500 <- sky distance
-13681.853516 <- rest of the geometry
-33.273438 <- some gui stuff

If I set the near/far planes to match the main geometry

near = 13681/10,000
and
far = 13681

The sky is clipped as expected



But notice the Z fighting is totally gone



Just need to modify the clipping code to make this work. Currently I am clipping against the projection matrix I set. Need only to clip against 4 planes, the near should be set to 0, and the far infinity.

[Bart]

Very interesting -- so you are computing the far distance and then dividing by 1e4? And you get the far distance from the top-level bounding box?

[Ian]

It was just something I was trying
Basically it works better than what I am currently doing but I am not sure 100% that is what the hardware is doing
It still doesn't work well enough for scud which needs a near plane something like 0.05 to avoid clipping of the steering wheel

Harley is also quite problematic as a lot of the buildings are actually drawn as solids, and the doors and windows are separate polys painted over the top of the buildings, and there is often a lot of Z fighting between the two. You can see it in the images above.

I might try applying a linear depth buffer to the above logic and see if that works. I think it might be the missing piece of the puzzle. I tried it before with Harley, but covering the entire z range from say 0.2 - 1 million didn't work. I instantly saw depth issues on the biker himself. But I think using the node distances and constraining the ranges might actually be it.

[Bart]

I didn't think it was possible to apply a linear depth buffer in OpenGL 2.x?

Also, another problematic case is dayto2pe. When the mechanic closes the car's hood, a nut slides into view at an extremely close distance. A near clipping plane of .01 or maybe even less is required for that scene.

It'll be interesting to see what you come up with. Sounds like you are quite close to cracking this

[Ian]

I didn't think it was possible to apply a linear depth buffer in OpenGL 2.x?

Why not ?
Think I just used something like this in the shader
outPos.z = (outPos.z * outPos.w - nearPlane) / (farPlane - nearPlane)

I do wonder if it is doing a linear buffer though, because the matrices the hardware uses are just 4x3. So there is no W component, which in a normal graphics pipeline is required for the perspective divide.

[Ian]

I had another thought with regards to this problem. Strange how ideas come into your head after not thinking about them for some time

The near clipping plane might simply be the minimum node distance.

[Bart]

What about the bounding box around the node, which, if I'm not mistaken, could be partly behind the origin when the node gets very close? It does sound like an elegant and simple idea. By the way, something I've noticed is that there may be additional clipping in LA Machineguns that your engine isn't performing. When I watch videos of it running on Wii or on the actual arcade, I'm struck by the fact that explosions and other particle effects never get too close to the camera and somehow seamlessly get clipped out. In Supermodel, the view often gets obscured by smoke, etc.

[Ian]

I had a quick tinker with the idea
and basically it seems to work. Vf3 the near plane comes out at like 50 !

The node distance comes directly from the bounding box itself. Not sure whether to take into account translating the bounding box by the current modelview matrix. Translation and rotation make no difference, but scaling the whole scene could do in theory.

[Ian]

I found this
http://www.google.ch/patents/US20070216710

It seems suspiciously similar to what real3d were doing ..