# Taking perspective into account, testing if a poly is facing the screen

10 replies to this topic

### #1Jotaf

New Member

• Members
• 14 posts

Posted 18 December 2005 - 09:46 PM

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?

### #2m4x0r

New Member

• Members
• 25 posts

Posted 18 December 2005 - 09:54 PM

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

### #3geon

Senior Member

• Members
• 939 posts

Posted 20 December 2005 - 07:46 AM

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...

### #4Crash

New Member

• Members
• 9 posts

Posted 20 December 2005 - 01:53 PM

### #5zavie

Member

• Members
• 91 posts

Posted 21 December 2005 - 08:12 AM

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. ^_^;

### #6Vandervecken

Member

• Members
• 32 posts

Posted 30 December 2005 - 08:24 AM

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).

### #7Reedbeta

DevMaster Staff

• 5307 posts
• LocationBellevue, WA

Posted 30 December 2005 - 11:16 AM

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.
reedbeta.com - developer blog, OpenGL demos, and other projects

### #8Vandervecken

Member

• Members
• 32 posts

Posted 30 December 2005 - 08:11 PM

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.

### #9Reedbeta

DevMaster Staff

• 5307 posts
• LocationBellevue, WA

Posted 30 December 2005 - 10:14 PM

I think doing a perspective transform would be a lot more work than just calculating the camera vector in world space =D
reedbeta.com - developer blog, OpenGL demos, and other projects

### #10.oisyn

DevMaster Staff

• Moderators
• 1842 posts

Posted 31 December 2005 - 12:16 AM

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
-
Currently working on: the 3D engine for Tomb Raider.

### #11Vandervecken

Member

• Members
• 32 posts

Posted 31 December 2005 - 05:32 AM

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).

#### 1 user(s) are reading this topic

0 members, 1 guests, 0 anonymous users