Jump to content


How to code cameras and draw distances


4 replies to this topic

#1 Gnarlyman

    Valued Member

  • Members
  • PipPipPip
  • 109 posts
  • LocationMilwaukee

Posted 06 March 2012 - 06:10 AM

I'd like to know...

How is the actual camera, and what it views, and et cetera, programmed? Obviously, that's tied to draw distance, but much more so, I'm very curious/puzzled as to the math/programming involved in cameras, which obviously have to "draw more of" the environment with the receding distance. Is there a certain ratio or math to get the cam to look right? I'm trying to code a camera system from scratch, and I'd like to know how to go about it. I hope this Q is coming across in a more or less understandable manner...

Thanks!

#2 geon

    Senior Member

  • Members
  • PipPipPipPip
  • 939 posts

Posted 06 March 2012 - 07:12 AM

Google for frustum and projection matrix. That should get you started.

#3 Gnarlyman

    Valued Member

  • Members
  • PipPipPip
  • 109 posts
  • LocationMilwaukee

Posted 07 March 2012 - 05:14 AM

Thanks, I looked all of that up and have gotten a good handle on it. Thanks again. My next question would be...

What's the general logic and process that governs the detection of meshes and...everything in the environment, really, within the viewing frustum?

#4 Reedbeta

    DevMaster Staff

  • Administrators
  • 5307 posts
  • LocationBellevue, WA

Posted 07 March 2012 - 05:54 AM

Usually people put a bounding volume of some kind around each object or mesh, such as an axis-aligned bounding box (AABB) or a sphere. These simplified shapes can easily and quickly be checked against the frustum (you can search for AABB-versus-frustum or sphere-versus-frustum intersection tests). The object is drawn if its bounding volume intersects the frustum, which is a conservative estimate of what's visible.

For more efficient frustum culling of large numbers of objects, a hierarchy of bounding volumes is used, such as an AABB tree, sphere tree, octree or BSP tree.

Note that if you're just trying to get the camera working, you should avoid frustum culling and simply draw all objects each frame, then put the frustum culling in later once you've got other things working (since it is a bit of a fiddly process with the potential for lots of odd bugs).
reedbeta.com - developer blog, OpenGL demos, and other projects

#5 geon

    Senior Member

  • Members
  • PipPipPipPip
  • 939 posts

Posted 07 March 2012 - 06:18 AM

To know what's inside the frustum, you need frustum culling and clipping. The clipping is done by the hardware and drivers in projection space. Any triangle outside the frustum is simply clipped. That way, every triangle left is able to be rasterized to screen pixels.

Frustum culling is just an optimization to avoid sending stuff to the hardware if it will all be clipped away anyway. Some primitive shape like a sphere or a box is assigned to each object. If the shape is completely outside the frustum, the object is not drawn.





1 user(s) are reading this topic

0 members, 1 guests, 0 anonymous users