10 replies to this topic

[Jotaf]

Hi there! I'm having some trouble with something that I thought at first would be rather straight-forward. I need to test if a polygon is facing the screen or not -- it should be easy enough, since this is done in simple face culling, and most articles lead you to believe it's trivial. But it's not :P

My code does the following: get the poly's normal, get the camera view direction, dot product, voila. < 0 and it's facing away; > 0 and it's facing the screen.

What's the problem? Well, it works fine around the center of the screen. But the more to the edges, the bigger the deviation, until the error is some extreme 45 degrees. My guess is that this is due to the perspective, I'm using "nicest" perspective calculations. The fellas over at GameDev were unable to help. How can I take the perspective into account?

[m4x0r]

If p is a point on the triangle (like say one of the vertices), just test dot(p - cameraPosition, normal) > 0. You can see this is quite similar to what you're doing, except that you don't want to use the camera view direction, since as you point out that doesn't take into account that it's a perspective projection.

Max

[geon]

Let your hardware do the job for you. It will cull them anyway if you tell it to do so.

Do you really cull quicker on the cpu, than the culled triangles can be transferred by the memory bus? If not, you are just un-optimizing...

[Crash]

If only I had learned to read!

[zavie]

You are testing if your polygon is facing the screen, while you want to test if it is facing the camera. This is a bit different, enough to see some error when the polygon is far from the center of the screen. See this page for more details : http://www.flipcode....illboards.shtml

As m4x0r said, you should use the vector going from the camera to the polygon instead.

Note that this can result quite tricky for huge polygons, since you have to compute the nearest point of the polygon. But I don't think it does matter for face culling, while for distance computing it does. ^_^;

[Vandervecken]

You can also project the normals into the Camera or View's space and do your dot product there. It even simplifies the dot product (at the cost of a transform) since your Camera's direction vector is always fixed while in worldspace the direction vector varies even per poly (your current problem).

[Reedbeta]

Vandervecken, you will still have to do the same work in view space, it is related affinely to the world space and so the camera's direction vector still varies. It is just the vector from the origin to the polygon in that case.

[Vandervecken]

Reedbeta said:

Vandervecken, you will still have to do the same work in view space, it is related affinely to the world space and so the camera's direction vector still varies. It is just the vector from the origin to the polygon in that case.

I was thinking of projecting it into a parallel view space... kinda a project of it into a 3d screen space. Like if you wanted to project into a -1,1 view box with all prespective calculations done already to clip easy.

[Reedbeta]

I think doing a perspective transform would be a lot more work than just calculating the camera vector in world space =D

[.oisyn]

Plus the fact that the projected plane defined by the triangle isn't a plane anymore (it's curved on the z-axis), so there is no unique normal to do the dotproduct with

[Vandervecken]

Exactly, project the normal not the triangle. You couldn't care less about the triangle or surface.

In most cases dotting the two (correct) vectors in world space is fastest, but as always that is implementation and hardware dependant. The projection might very well be "free" if you're doing it for some other reason in the pipeline (if this is the way you clip the view fulstrum, or some odd lighting hack, or ...?) that backface culling wouldn't eliminate. Besides I was only suggesting a different than the usual way of doing this hehe (not the best by any means).