I''m not really sure that his will help because of the connectivity thing but this is what I did in one of my programs.

get the data from the vertex buffer

use pythagorous to work out the distance between the camera and the first vertex of the face.

use pythagorous to work out the distance between the camera and (the first vertex on the face + it''s normal)

Compare the two calculations - if the first is smaller than the second the face is facing away from the camera.

To speed this up you can miss the square root in the pythagerous cus it doesn''t do anything in this example.

hope that gives you some ideas even if it''s not helpfull

de_matt : in computer graphics, there is a famous algorithm that simply tell you if a vertex+direction is facing the camera : compute the dot product between the eye-vertex vector (vector from the camera to the vertex) and the normal. If the dot-product is negative, then the vertex+direction is facing the camera.
Actually, that is what is done by OpenGL''s face culling. (OpenGL does compute a cross product over the face instead of using normals, though)

That''s true. That''s what I have to do, if OpenGL can''t figure it out by itself.

Marching Cube isn''t an alternative because Marching Cube requires a cube-like structure. And as I already mentioned, I don''t have a structure on these points. Just a bunch of points.

And the whole thing has to be fast. I don''t have the time to compute something like a surface.

The rendering as it is now is ok, but what I want is simply to speed it up, because I render more points than necessary.

quote:Original post by OrangyTang
Normals are not touched (or needed) for front/back face culling.

Indeed, that''s what I''m saying

The problem with vertex program is that the overhead due to program execution may be slower than rendering the points themselves, unless points are really big.

quote:Original post by AxelF
Marching Cube isn't an alternative because Marching Cube requires a cube-like structure. And as I already mentioned, I don't have a structure on these points. Just a bunch of points.

That's actually not a requirement, but if you don't want to compute a surface the point is moot.

Anyhoo, I suspect that backface culling is going not to help you, unless you have large point sprites that eat fillrate. Backface culling requires that every vertex be touched/processed. It's primary purpose is to save on scan conversion/fillrate. When you're dealing with points, fillrate is pretty negligable vs. vertex transformation, so backface culling points doesn't make much sense.

You'll need to come up with a smarter method of point culling. If you have no structure at all to your points, you'll probably have to impose some, either by generating a surface or sorting them somehow.

[edited by - cheesegrater on April 29, 2003 1:36:15 PM]