Originally posted by A027298:
[b] [quote]Originally posted by knackered:
…This is an insane thread.
I think my question wasn’t insane…so pretty straightforward.
[/b][/QUOTE]
Are you kidding me?
Transforming the bloody vertices on the CPU will be far faster than reading back the zbuffer and finding the smallest z value out of it! OpenGL selection?! Are you kidding me?
That’s what’s insane.
I think something that nobody has mentioned yet is that finding the closest vertex to the viewing position to determine the distance to the near clip plane will give incorrect results at times.
For example:
. - Eye Position0--------------------------------------0
-vertex -vertex
Here you can see that the closest vertices are the ones at the end of the ground plane, so the clipping plane would be set to be way out, meaning that almost all of the ground plane would be culled, and the viewer would see almost nothing. Probably not what is desired.
What you really want to do is calculate the closest distance to any of the triangles that possibly could be in view - a much more complex problem.
j
Originally posted by j:
[b]I think something that nobody has mentioned yet is that finding the closest vertex to the viewing position to determine the distance to the near clip plane will give incorrect results at times.
For example:
. - Eye Position
0[/b]
Hi
thats what I also mentioned in my threads.
He should calculate the vertex distance to the eye plane using my suggestion without the map (that came into my mind becaus I thought he would need further processing)
Bye
ScottManDeath
Well, actually, that still doesn’t work. Imagine this situation:
.---------->(View Vector)0---------------------------0
In this case, the eye plane will be vertical, so the near clip plane will be calculated way out by the far right vertex, which is the closest vertex to the camera. This is definitely not correct.
j
Transform your view point V into object space. Now for each point P(i), find (V-P(i))^2. The point with the smallest value will be your closest point to your view point. Note that this will also include points which are not in view (ie, behind you).
Without some sort of bounding hierarchy, you’re not gonna find anything faster than that.
[This message has been edited by fresh (edited 01-21-2003).]
Hello there,
I believe that the problem of finding the closest vertex is not the problem you really need to solve.
In order to place your near plane as far forwards as possible you need to ensure that it is closer than the closest pixel you render, not the closest vertex. It is quite possible to have a polygon with one vertex far from you and another behind you, outside of your view frustrum, yet the closest pixel will be closer than the vertex in front of you.
Your low-resolution depth read finds these close pixels, but only to an approximation. In your final high-res render you may find a few pixels even closer.
I hope that helps,
Leon
Sort? That doesn’t work unless you transform the vertices to eye space on the CPU!
…or transform the camera position into object space… But I retract my case. Thanks, Tom. 
Originally posted by Leon:
Your low-resolution depth read finds these close pixels, but only to an approximation. In your final high-res render you may find a few pixels even closer.
Yes, currently I am doing it like that. Maybe the safest and easiest method to do.
How about…
(At load time - ie. Only done once) Divide your verts into a number of set units and calc the bounding spheres for these units. (ie. List of bounding spheres, list of indices that map your verts to the spheres)
Transform your camera into objects space.
Find the closest bounding sphere to the eye plane. If sphere overlaps the eye plane and/or there are spheres behind the eye plane then set the near plane to some preselected distance (because it doesn’t really matter where you put it, it’s going to clip your geometry).
If the sphere does not overlap the eye plane, go through the list of verts and find the nearest one to the eye plane.
I think that’s not too difficult, “unsafe”, cpu intensive or inaccurate…
Presumably, you’re finding the closest vertex by doing a dot product between the view vector and (vertex - camera) in world space, so that’s still safe.
However, pushing the near clipping plane around is generally just not a great idea. Users will still see Z fighting when they’re in situations where there’s something close to the camera. It’s also QUITE likely that you want to draw geometry that extends behind the camera (such as a wall you’re running alongside, or the floor you’re standing on) so you’ll get a negative “closest” value – then what you you do?
The best solution I know of is to decide on a near clipping plane distance (say, 0.8) and then make sure you put a collision sphere of at least that size around the camera, so that the camera can’t clip through geometry (unless that geometry is lacking collision). This, of course, requires that you have a decent collision system, and don’t mind running this on your camera everytime it (or the environment) moves.
Originally posted by jwatte:
Presumably, you’re finding the closest vertex by doing a dot product between the view vector and (vertex - camera) in world space, so that’s still safe.
That’ll give you the closest vertex to the the view vector wont it? Rather than to the camera position?
That could be the furtherest point from the camera (if you were looking into the base of a cone).
(Or am I missing something…)
Originally posted by rgpc:
(Or am I missing something…)
Yes, you’re all missing something here. It seem like Leon is the only one who’s got a hang on what this is about. Read his last mail, it should describe the problem quite clearly.
Oh and knackered, you are right. This thread IS insane… Everybody just keeps telling the same stuff all over again, solving the wrong problem.
-Ilkka