   2D culling - lousy trig bites me back....
  After a little bit of thinking I realised my terrain engine doesn''t need a 3D culling mechanism - instead a "simple" 2D occlusion test for each of the patches (the terrain is tessellated symmetrically into square patches) would be much more suitable. That''s when I realised I can''t do it and remembered that''s precisely why I used to be so weak in math. Here''s the full deal:I know the look-at vector and the positional vector. I also know the FOV in degrees. What I don''t know is what the test should look like for occluding square patches based on that information. I also know the patches'' corner coordinates. Discarding the y (up) component, what would be the math behind the culling test?I can do the research myself (and I have - I just haven''t found much useful on the Net) - I just need a few pointers although something close to pseudocode would be most appreciated (that way I might actually understand the thing).Cheers 
  You want to take the current look at vector and project it on the xz plane (im assuming the terrain is parrallel to the xz plane) so do so just set the y value to zero and normalize it.From here you want to use this 2d vector in the xz plane and use it and your fov to form two edge vectors. These will be the ones that represent the V extending from the camera representing the visible arc. Now you want to test each quad against these two vectors. A simple suggestion would be making a vector from the camera location to the different verts of the quad and also projecting that to the xz plane and taking the dot product of this vector with the two "edge''s normals" in 2d the normals of a vector are extremely easy to find, in the 2d case merely swap the x and z values and negate one of them depending on the direction you want the normals to go. This will be the same as a half space test in 2d and will let you know which side of each vector the vertex is on. If its between the two vectors its in view.Now theres tons of optimization that can be done there, I am fairly certain you can optimize out the normalizations because I dont think that the vector lengths matter in this instance with no far clipping plane. Theres also some optimization based on which direction the edge vectors are going to which two (not all four) quad corners you have to check ;  Thanks dclyde, I''ll try it out as soon as I get the program to run again (currently doing some heave remodeling in the texture management and window code) 