PDA

View Full Version : Near and Far clipping ratios



Punchey
12-04-2000, 08:35 AM
I know it is advisable to keep the near and far clipping planes' ratio low. But what is the recommended ratio? I've heard the near plane should be 1.0 but this leads to an inability to get very close to objects, but then you could overcome this apparant inability to get close to objects by drawing them much larger, however, then you have the problem that you're more limited to the distance of objects. For example, I'm drawing a planet, and I want to be able to fly VERY close to the surface of the planet. But to achieve this appearance with the near plane set to 1.0, I have to make the planet *HUGE* (in terms of its radius)! Otherwise, I hardly get close to the planet at all and BAM I'm inside the planet. I realize the ratio can be larger with a larger Z-buffer (32bit). But is current hardware well equiped to use a 32bit Z-buffer? Or is it best to stick with 16bit? And, taking all of this into consideration, what is the best way to simulate things like space and drawing HUGE objects like planets and EXREMELY distant objects like stars? Are there any tricks anyone has they'd like to share?

I remember a long time ago (in a galaxy far, far away) there was a title called Microsoft Space Simulator. It was monster cool because you could pump the time compression way up and fly at near-light speeds through the galaxy. You could start somewhere within the solar system and you'd see the actual stars in their real places. And then you could accelerate and you'd see the planets of the solar system whiz past and become little dots in the distance and eventually, you'd begin to see the stars that make up familiar constelations start to move and then you could eventually fly around them and see how they didn't lay on a flat plane as they appear from our solar system. This kind of _LARGE_SCALE_ universe is what I'm seeking to create and I'm just wondering if anyone has any tricks to rendering _DISTANT_ objects and still maintain accurate depthbuffering.

zed
12-04-2000, 10:41 AM
2 options
measure the zvalues of everything in your scene everyframe and set the near/far values to those every frame.
or use 2 depth ranges ie draw all the near stuff change the near/far planes and draw all the far stuff.
ive done it this way with a space thing and IIRC there was no zfighting from 1m to a billion kilometers

Punchey
12-04-2000, 11:14 AM
So you did it using the second method you mentioned? Cool! Thanks, man! Could you elaborate a bit on how you actually implemented that system? How do you actually use two different depth systems and how do you handle the rendering of something like that? I've heard if you use a near clipping of less than 1.0 you'll run into problems. But are you saying this is not the case? Thanks again!

Michael Steinberg
12-04-2000, 12:21 PM
I can't understand how you're generalizing the zbuffer problem.
It's always cool to have the distance between the planes as small as possible, but the scale of the displayed object should specify the ideal ration (would be limes to zero... http://www.opengl.org/discussion_boards/ubb/smile.gif ). So, get the maximum z value of any object (you can use bounding spheres) and the minimum z value, and use them. It should always give the best results.

Michael Steinberg
12-04-2000, 12:24 PM
Whoops, I think I oversaw some details in your question. Sorry.
Maybe, you don't really let the far-away object get far away, but do a lod with scaling the object down appropriately.

Punchey
12-04-2000, 01:32 PM
Originally posted by Michael Steinberg:
Whoops, I think I oversaw some details in your question. Sorry.
Maybe, you don't really let the far-away object get far away, but do a lod with scaling the object down appropriately.

That sort of technique might work for some things, but for other things, you'd lose the whole feature of depth buffering: occlusion. Do you have any ideas as to how to implement this other guy's suggestion? It sounds pretty good especially seing as how he says he's already implemented it with success. Although, depth-sorting everything before rendering is something I havn't had to deal with yet.

BK
12-04-2000, 04:46 PM
Punchey,

You don't have to depth sort everything, its more of a case of picking a distance and having objects as being either in front of or behind that imaginary 'line'.

In its simplest form, you just test each object as you go to draw it and put objects on the near side of the imaginary line aside for the next pass with the 'closer' far and near clipping planes.

When you do the second pass, just clear the Z-Buffer (but not the frame buffer obviously) before you draw.

I guess that if your distance is very large, you could use several of these 'clipping bands'

I haven't actually done it yet, but plan to soon. I'm sure there are a few things I haven't covered like what to do with objects that straddle the boundry and such,and I'm sure there are more efficient implementations than my simple explaination.

Punchey
12-04-2000, 05:17 PM
well, you'd have to do more than just clear the Z-buffer. You'd have to reset the near and far clipping planes because you'd still get depth fighting. The problem I'm running into is if I draw using a near clip of 1.0, it looks as though I can never get close to anything like a planet or such. If I make the planet large enough to look good so that I can get what looks to be reasonably close to it without it dissapearing, then when I fly away from the planet, it dissapears beyond the far clipping plane FAR too early. So I'm at a loss of what to do. Is it much of a performance penalty to reset your near and far clipping planes each frame? And if not, which calls are best to use to accomplish this? Also, I'm noticing that whether I use a 16bit or 32bit Z-buffer, it still has the same ammount of depth fighting.

Michael Steinberg
12-04-2000, 10:06 PM
I think it's almost necessary to reset the clipping planes every frame, just to improve visuals. For my own purposes it seems to be far easier though than to yours...
Maybe replace the galaxies with a simple billboard when you are far enough away. They won't get depth fighting then. You could even project them on a sphere or something else. It's just that you can't see a whole galaxy detailed from one point. AND maybe it is more easily to apply your own depth sorting, only drawing them over each other. I mean, planet's don't intersect, so you can sort them and do a far to near rendering without depth test. That would be the way, I think.
And planets are almost always convex.

[This message has been edited by Michael Steinberg (edited 12-05-2000).]

Punchey
12-05-2000, 06:01 AM
About the 32-bit Z-buffer thing, do you know if there's a big performance premium on today's hardware for using one as opposed to a 16-bit Z-buffer? I'm beginning to think I'm going to need a whole message board dedicated to the topic of Space combat sims. The reason being that after getting into it and trying to implement things like laser beams and stuff I just have a TON of questions to ask. If anyone else out there is doing something like this themselves, it wouldn't hurt for us to collaborate together and brainstorm to come up with some solutions to these very basic problems.

Michael Steinberg
12-05-2000, 06:02 AM
Might be that it didn't get clear, but I'm also (trying) to write a space combat sim. Maybe we should work together or at least change ideas...

Punchey
12-05-2000, 06:05 AM
I almost forgot, since a planet or something could lay on the border between the two sets of near/far clipping planes, I suppose you'd need to make them overlap a bit? And I further suppose that the size of this overlap would essentially define the maximum size of an object in your universe that could possibly cross that border? Is my reasoning correct here or is there a way to get around this?

Michael Steinberg
12-05-2000, 06:37 AM
I don't think that it is quite a good idea to use multiple sets of planes.
You'd still have to render back to front in a way, and you'd have to clear the depth buffer many times a frame.
Here is what I would do:

-1. ( http://www.opengl.org/discussion_boards/ubb/smile.gif) Define a maximum distance where normals objects would be visible
0. Define a real greate ratio, the near planes lies, where the maximum distance is
1. Turn off Depth testing
2. Sort Planets after depths
3. Draw planets back to front
4. Set the actual ratio for near objects
4.5. Switch on depth testing
5. Draw planets that lied on the max-distance-plane a second time or in front of it.
6. Draw all your great space ships

Punchey
12-05-2000, 08:25 AM
So you are basically saying to draw distant objects scaled down but actually near with depth testing turned off, and then turn depth testing back on and draw near object actual size?

Michael Steinberg
12-05-2000, 09:14 AM
Nope, for far away planets, only switch off depth tests, to not let the ratio get great. I hope you can follow me.

Michael Steinberg
12-05-2000, 09:17 AM
You'll have a great ratio for undetailed far-away (convex) meshes, but you won't do the depth test on it, to have the full precision of the zbuffer completely for the close objects that are more complex in rendering in the correct depth order.

Punchey
12-05-2000, 10:06 AM
So you're talking about the accuracy ratio of the depth buffer once used. I thought the ratio of the depth buffer was determined by the near and far clipping planes. If you set a near of .5 and a far of 10000 you've defined the ratio of the depth buffer. AFAIK using the depth buffer is not what determines the resulting ratio of accuracy. In other words, it's not as if I could set up a near of .5 and a far of 10000 and then just do all my depth-tested drawing between .5 and 100 and expect that to keep the ratio down because the depth buffer's accuracy was determined when I set the near and far clipping planes. Or am I wrong about this? If I'm right, then to fix the depth accuracy problem you'd have to define a smaller depth range such as 1.0 and 5000 but, unfortunately, then whether I disable depth testing or not, objects farther away than 5000 will get clipped.

BK
12-05-2000, 04:28 PM
"well, you'd have to do more than just clear the Z-buffer. You'd have to reset the near and far clipping planes"

I sorta took that as a given http://www.opengl.org/discussion_boards/ubb/smile.gif Does anyone know what the penalty for changing the clipping planes are? In my situation I only need probably 2 or at most 3 of the clipping bands I described anyway.

I have seen this technique in a commercial engine using 4 clipping bands (thats were I got the term from http://www.opengl.org/discussion_boards/ubb/smile.gif ), and it works well without noticable FPS drops. That was performing all transformations in the engine itself, so maybe the penalty is greater for OpenGL and/or HW T&L, I'm not sure. I guess I'll find out soon...

I've heard of tricks that eliminate the need to actually clear the Z-Buffer,so maybe that helps the Z-Buffer clear penalty.

About the 32bit Z-Buffer, alot of cards force the Z-Buffer to 16 bit when you use 16 bit colour depth, you probably thought of that, but just in case.

So if I gather what you are saying Michael, then you are setting up the rear clipping plane to a far distance, turning off Z test and write, and using the painters algo to draw the distant planets.

Then, change the front and rear clipping planes to a desired value, turn Z test and write back on and draw the remaining planets and objects.

Actually thats not a bad idea considering all the planets are spheres, and the other objects should be too small to be drawn.

Kilam Malik
12-05-2000, 10:09 PM
Originally posted by BK:
I've heard of tricks that eliminate the need to actually clear the Z-Buffer,so maybe that helps the Z-Buffer clear penalty.


But using that trick, you have to leave the near and far clipping planes on the same value for each frame. I'm not sure, if this trick is used in current graphic-card drivers.

Michael Steinberg
12-06-2000, 04:33 AM
I think I've not been clear while the last explanations.
AFAIK, anything before the front or behind the back planes won't be rendered anyway.
If you have a great ratio, you'll get depth fighting in detailed object, which are NOT CONVEX. Planets ARE CONVEX. For CONVEX bodies, planets, you don't need any depth testing in this case, since they won't intersect. SO:

1: Sort the planets after their distance from the viewer.
2: Specify a maximum distance where detailed objects like space ships, which are in fact very small can be seen. You could fade them out with black fog if you want to.
3: Set up the far an the near planes: The near plane gets the maximum distance of point 1.
4: Clear Depth buffer
5: Disable depth buffer
6: Draw any planets that are far away with back->front ordering, so you won't need depth testing.
7: Setup the planes: Near plane: as near as any object can get, Far Plane: The maximum distance from point 1
8: ENABLE depth test
9: Draw your highly detailed objects like starships.

Hope I'm clear now.
BTW: My lost teeth don't hurt...Funny.

Michael Steinberg
12-06-2000, 04:39 AM
Oh, BK. You actually got it right. For speheres it's easy, since you can use their position to determine which one to draw first. And for the ring of the saturn, it will get a bit more complicated, but not with visual errors.

Michael Steinberg
12-06-2000, 04:44 AM
And to game fun:
I can't imagine a game to be fun where you'll have to fly around between real planets in a galaxy. If you wanted to move between two planets, you'd need to be VERY fast, but then, if you'd have enemy space ships, it won't come to a fight, since you'd have to be WAY TO FAST FOR A FIGHT... I mean, if you'll have a speed of a few thousands of meters per second, and your spaceship is 20 or 40 meters long and the enemies aren't bigger, you won't even see them.

Punchey
12-06-2000, 06:05 AM
You're right... But I'm not talking about doing a *completely* realistic game this time around. But I would like to be able to make a game where particular battles take place over a really HUGE planet so that it "feels" like you're really in orbit over a REALLY BIG planet. But still be able to move towards and away from the planet to some degree. I suppose you're on to a good idea here as to just disabling the depth buffer when drawing objects like these. I just wonder now what the best method would be to allow the user to fly around but not actually allow them to collide with the planet. I guess I could just simply stop their movement when they get too close but that makes a game feel really fake. I suppose a SUPER cool thing to do (although it'd be SUPER hard too) would be to actually allow the user to fly down into the atmosphere of the planet and actually cruise the terrain. :-) I'm probably getting a bit ahead of myself now. But you're right about the rings of Saturn... That'd be a pretty difficult situation to deal with. But for the game I have in mind, I'm thinking about drawing Saturn without the depth buffer, and then drawing "asteroid" looking things (actual polygon objects) in a belt-type arrangement and the combat would actually take place *in* the rings. That way I can get away from the whole problem of disabling the depth buffer when drawing the rings.

So, I still have yet another question: what is the best data structure to use to organize my objects that will allow for the easiest and quickest depth sorting and is OpenGL friendly?

Michael Steinberg
12-06-2000, 01:24 PM
Maybe a great array of triangles, and indices to it for every object. Hmmm.
At least destroyed starships could burn away in the atmosphere... I've been thinking about thousand cool effects, but I think that is a mistake. If one has every little complicated effect in mind, you won't get started...
Anyway, I'm currently simply working on my windows routines and my own intern gl windows implementation. It's limited, but I'll need to write some mesh-editing progs ingame and it will help a lot, I think.
Is anybode used to 3dsmax or a modeler that can export it?

[This message has been edited by Michael Steinberg (edited 12-06-2000).]