View Frustum Alternative

I am working on a simulation project that requires me to have entities walking around in a 3D world. I have all that working, matrix transformations, etc. I'm at the point where I need what is essentially a view frustum, so I can give each entity a visible area. However, when looking over the calculations required to do it, it seems like a perspective frustum is only required to be able to project it onto a 2D screen. Is there another, easier to code solution, that would function better, such as an orthogonal perspective? Could I just define a shape mathematically and test wether the coordinates of the objects are inside or out? I am not really a 3D coder (and I am doing this all from scratch, not using an engine or anything), so I would like the simplest solution possible for my needs.

Thank you!

-
It sounds like you're saying each entity has a view-frustum-like volume within which it can "see". Is that right? Can you be more specific about what operations you need to do with these view volumes? For instance, do you need to test whether a point is inside one, or test for intersection with another volume (and if so, what shape is that volume), etc.? How realistic of a vision model do you need? – Nathan Reed Nov 27 '11 at 22:33
Yes, that is exactly what I want, a volume for each entity within which it can see. I need to test wether points are inside this volume primarily. As of now, I do not need to do any intersections. So, just a volume and the ability to see if an arbitrary xyz point is inside. – Kuros Nov 27 '11 at 22:35
I will also want to account for points being behind solid surfaces, for example if a point is behind something I've labeled as opaque (a wall or something). They shouldn't be visible in that case, but that may be a different problem. – Kuros Nov 27 '11 at 22:50

You could use a cone instead of a frustum; it would be a simpler point-in-volume check. You'd construct the vector from the entity's eye point (the apex of the cone) to the point to be tested, then normalize it and dot-product with the entity's view direction (another normalized vector). Then test if the dot product is > cos(0.5 * the entity's FOV). That cos factor can be precomputed and stored if the cone widths don't change.

This doesn't give you the ability to have separate vertical and horizontal FOVs, though, in case you care about that.

As for seeing through walls, that is a harder problem. In general, you'll need to do a raycast from the entity's eye point to the point being tested and see if it hits any scene geometry along the way; storing the geometry in a BSP tree can be helpful for speeding this up. Tracing rays against a scene is a large topic that you can find a lot of information about on the Web.

-
Ah, that helps a lot, thank you. I suspected raytracing would be involved..I'll tackle that separately. Thank you again! – Kuros Nov 27 '11 at 23:28
Although separate horizontal and vertical FOVs would be nice...maybe later. – Kuros Nov 27 '11 at 23:30

If you combine a view matrix & a projection matrix (which you can do for each entity, like if it were a FPS), the component values in the resulting matrix can be used to create 6 planes (a vector4 representing each plane) representing the boundaries of the frustum. Then these planes can be used to test if other objects are on one side of the plane or not. When an object is behind all six planes, it is inside that frustum.

If you use Xna, this comes built in. If not, reflect Xna to see the principle/code behind and port it to whatever language/platform you're using.

-
Thank you, but I was hoping for something simpler and not involving a projection matrix, as I have no need for it. – Kuros Nov 27 '11 at 23:29
Simple is good, I agree. In Xna, the projection matrix is a built in class and it makes it so simple to implement it. Again, you could easily reflect & port the projection creator as well if you don't find something simpler. – Steve H Nov 28 '11 at 2:15