# closet vertex to camera.

Originally posted by Tom Nuydens:
Sort? That doesn’t work unless you transform the vertices to eye space on the CPU!

Yes, sorting would be ok but this transformation on the CPU is very expensive.

…could I use a vertex program like using the distance of the last vector and compare it with the current?

This would need something like a static variable/register and pass it back then to the application…?

[This message has been edited by A027298 (edited 01-17-2003).]

Originally posted by A027298:

Yes, sorting would be ok but this transformation on the CPU is very expensive.

I think that was Toms point!

[b]
…could I use a vertex program like using the distance of the last vector and compare it with the current?

This would need something like a static variable/register and pass it back then to the application…?
[/b]

You can’t use a vertex program for precisely that reason. “Static” registers don’t exist, and aren’t likely to, as they cause all sorts of nasty race-conditions in the pipeline.

You seem rather afraid to do things on the CPU, and prefer to do them on the GPU, regardless of how complex that makes the operation. Is there a reason for this?

Hi

Perhaps you can calculate the distance to the eye plane by doing the opengl projectio just for the z coordinates. After that the z position is divided by the w component. Finally the distances get sorted.

mvp2…row 2 of modelviewprojection matrix
mvp3…row 3 of modelviewprojection matrix
vertex… vertex in object space with 4 components

for all vertices do
dist= dot4(mvp2,vertex) / dot4(mvp3,vertex)
store distance and vertex index

sort(distances)

For storing I would us a STL map<float,int> because its automaticly sorted.

Perhaps this is not what you want, but its a possible way

Bye
ScottManDeath

Originally posted by nutball:
You can’t use a vertex program for precisely that reason. “Static” registers don’t exist, and aren’t likely to, as they cause all sorts of nasty race-conditions in the pipeline.

Ok I see…

Originally posted by nutball:

I think that was Toms point!

indeed…

Originally posted by nutball:
You seem rather afraid to do things on the CPU, and prefer to do them on the GPU, regardless of how complex that makes the operation. Is there a reason for this?

No I am not afraid doing things on the CPU, but you know all vertices go to the GPU anyhow and why not perform then some stuff there?! …instead going through all vertices twice on CPU and GPU. But as you already said, it doesn’t work in the GPU.

@ScottManDeath
Thanks interesting idea, but maybe it’s too much what I want. I only wanna know the distance to the closest vertex to the camera position.

Thanks guys!!!

[This message has been edited by A027298 (edited 01-17-2003).]

[This message has been edited by A027298 (edited 01-17-2003).]

If you could tell us what effect you’re trying to produce realtime, maybe we could tell you if it’s possible to do it at acceptable speeds. From the little bit of info that you’ve shared with us I’d say that daves suggestion along with the Pythogora’s Theorem without the sqrt would pretty much do what you want.

Originally posted by WhatEver:
If you could tell us what effect you’re trying to produce realtime, maybe we could tell you if it’s possible to do it at acceptable speeds.

I would like to move the near plane as far as possible to the rendered scene. So I need to calculate the disctance to the vertex, which lies closest to the camera position.

Currently I am reading back the Z-Buffer. I render my scene only with a viewport like (0, 0, 128, 128) but I need then about 32 ms (gf4, P4). Thats slow. Nutball’s idea is much much faster, but it makes only sense for static geometry. My scene is small I have no tree structure, about 20k-100k verts and I cannot be restricted to be static. So,…it’s not more to say what I wanna do. Maybe there is an other clever idea, otherwise I have to go for the read back.

Thanks.

Hi

when you just want to place the near clipping plane as deep as possible, I would think about my suggestions because they will give you the vertices distance to then near plane.
If you use the euclidian distance from vertex to your camera, you’ll get different distances if your vertex is in center or on the border of your screen.

Another option would be to use the feedbackbuffer. IIRC it gives you the vertex window z depth. Then you just sort after it. The drawback is that you have to render your scene twice.

Bye
ScottManDeath

Why do you need to know which vertex is closest? Are you trying to select vertices that are closest to the near plane?

Originally posted by ScottManDeath:
when you just want to place the near clipping plane as deep as possible, I would think about my suggestions because they will give you the vertices distance to then near plane.

Hmmm…yes I should examine your suggestion. But why to store the vertices in a map? If the camera moves, all the vertices in the scene get a different transformation. So, why to use the old ones? But to that point you maybe didn’t know what I exactly wanted.

I mentioned that I am currently reading back the depth buffer. Actually the major penalty is the rendering of the scene, not the read back of the depth buffer (!). The read back plus finding the smallest value costs me 0ms with GetTickCount(). To render the scene costs me 32 ms (of course, everything is disabled, except the depth buffer).

Originally posted by ScottManDeath:

Why do you need to know which vertex is closest? Are you trying to select vertices that are closest to the near plane?

I need it only to adjust the near plane. So I am not trying to select vertices closest to the near plane or something like that.

[This message has been edited by A027298 (edited 01-18-2003).]

Why not just leave the near plane set to 1.0 or whatever your preference?

I appologize if I’m totally misunderstanding your intent, but from what I gather now, you want to adjust the near plane according to the closest vertex every frame for some reason. You don’t need to do that. When you set the near clipping plane with glFrustum or glOrtho, it’s always relative to the camera position.

Let me know if I’m on the right track.

Originally posted by WhatEver:
I appologize if I’m totally misunderstanding your intent, but from what I gather now, you want to adjust the near plane according to the closest vertex every frame for some reason.

Exactly, I wanna do that every frame in a if possible very fast way.

Originally posted by WhatEver:
When you set the near clipping plane with glFrustum or glOrtho, it’s always relative to the camera position.

Yes thats right, but you get different ‘images’ when moving the near plane. And for my thing I need it as close as possible to my scene.

[This message has been edited by A027298 (edited 01-18-2003).]

You may also consider to use OpenGL’s
selection buffer, using only
one ‘name’ for the entire scene.

The hit record then gives you the min/max
depth value which can be un-projected
to give you the values for the near/far plane.

This requieres an inital guess for the
near/far settings in order to include
all relevant vertices.

See man page for glSelectBuffer.

This wouldn’t be for shadow maps by any change, would it? Even perspective shadow maps, I think they require this in practice.

Selection buffer sounds good, especially if you don’t have zillions of polygons. Or how about rendering a low-res version and reading the depths from it. Would the error be too big? You could adjust the result a little to compensate the possible error.

-Ilkka

Originally posted by JustHanging:
Selection buffer sounds good

???

I hope you guys know that selection is ALWAYS performed in software! Selection seems to add some complicated stuff to be done, therefore some guys thought about dropping the selection-mode in OpenGL 2.0.

I have written a Leveleditor, which uses selection. A level with around 10000 vertices takes several seconds (Athlon 1.3, GF 2 Ti) to render and select an object ONCE, so you won´t be able to use it in realtime applications, 30 times a second.

I think this discussion is quite strange. Why not calculating the relative distance for all objects (without the square-root) and checking which of the closest vertices is inside the view-frustum? I don´t think this should be a problem.

Jan.

You don’t do anything with euclidian distance when adjusting near clip plane. You have to know the point nearest to the image plane that fits the screen. It might even not be any of the original vertice, you would have to do the clipping yourself to get it work.

Two ways to get this distance with opengl are selection (or feedback) buffer, and reading back depth buffer. Selection is remarkably faster of these two if there polycount is low. In this application you don’t need to push names or stuff like that, so it should be a little faster than your editor.

-Ilkka

Originally posted by JustHanging:
This wouldn’t be for shadow maps by any change, would it?

Yep, something like that.

Currently I am reading back the depth buffer, which is rather slow. Though I render only to a 128x128 window. So I gonna check this Selection buffer thing and compare it with reading back.

Originally posted by JustHanging:
[b]You don’t do anything with euclidian distance when adjusting near clip plane. You have to know the point nearest to the image plane that fits the screen. It might even not be any of the original vertice, you would have to do the clipping yourself to get it work.

Two ways to get this distance with opengl are selection (or feedback) buffer, and reading back depth buffer. Selection is remarkably faster of these two if there polycount is low. In this application you don’t need to push names or stuff like that, so it should be a little faster than your editor.

-Ilkka[/b]

why clip when clamping the z would do in this case - he only wants the distance.

Originally posted by knackered:

I think my question wasn’t insane…so pretty straightforward.

Originally posted by A027298:
Nutball’s idea is much much faster, but it makes only sense for static geometry.
[/b]

No, my suggestion works just fine for non-static geometry. My comment about static geometry was in the context of comparing a tree-based search to the brute force approach.

I’d hazard a guess that building a tree for your vertices would take longer than finding the minimum squared distance for all vertices using the simple arithmetic I proposed. Therefore although searching the tree to find the closest vertex might be quicker, if you add in the overhead of building the tree, that technique overall would (probably!) be slower.

If you had static geometry you could build the tree once and re-use it, and in that case the tree might well be a better method. For a dynamic geometry, the simple brute force approach is quite likely quicker than the tree.

That was what my comment about static geometry was aimed at.

How can clamping z achieve this? Say you’re standing on a flat floor looking forward. Now the shortest distance to the image plane in a corresponding image (I assume this is what is really needed) is the distance where the floor intersects the bottom clipping plane. That’s where you need the clipping. But then, you only need four clipping planes and only need to calculate the z-coordinates, so it might the fastest approach anyway.

For A027298, finding the optimal near plane seems to be quite expensive. Are you sure you can’t solve the precision problems some other way? And don’t be afraid to put your scene in some sort of scenegraph, sure you can come up with something unless it’s some realtime RIB viewer or something where the geometry can totally change from previous frame.

-Ilkka