3D clipping & gluPerspective()

This is a discussion on 3D clipping & gluPerspective() within the Game Programming forums, part of the General Programming Boards category; i am a little confused about 3D clipping using gluPerspective(). from what ive read, i thought that anything out side ...

  1. #1
    Crazy Fool Perspective's Avatar
    Join Date
    Jan 2003
    Location
    Canada
    Posts
    2,640

    3D clipping & gluPerspective()

    i am a little confused about 3D clipping using gluPerspective(). from what ive read, i thought that anything out side of the viewable 'perspective' should not be rendered (ie. no projection calculations done). but i did a little test and i dont think this is the case...

    i added 50 high poly models to an area of the scene. when looking at them (they are inside viewable frustum) the program was slow and choppy as excpected. When i turned the camera away from them (no longer in the viewable perspective/frustum) the program was still slow and choppy which implies rendering calculations are still being done for these non-viewable objects.

    my question is: do i have to manually calculate what is viewable and only draw/render that? or can openGL (gluPerspective) do this for me. if it can do the 3D clipping for me, what am i doing wrong??

    this is how i set up my perspective...
    Code:
    gluPerspective(55.0f,(GLfloat)width/(GLfloat)height,0.1f,50.0f);

  2. #2
    Registered User
    Join Date
    Apr 2002
    Posts
    1,571
    Isn't the first parameter FOV in Radians?

  3. #3
    Crazy Fool Perspective's Avatar
    Join Date
    Jan 2003
    Location
    Canada
    Posts
    2,640

  4. #4
    Registered User SAMSAM's Avatar
    Join Date
    Nov 2001
    Posts
    218
    FOV is in degrees.

    but why most of the math functions in C math lib are in radiant,

    like sin() cos() tan()

    does it serve a purpose?

  5. #5
    Shadow12345
    Guest
    Calculations are done on everything that you tell OpenGL to render, but only the things that are inside the frustum get put to the screen. In order to skip calculations of things that are outisde the frustum you have to manually do a lot of crazy math to determine if it lies in front or behind the planes that make up the view frustum. Depending on what you are working with you will typically have the world partitioned into segments (poly knows all about this he did a binary space partitioner) and you first determine what segment (read: sector) you are in, then you check all of the polygon data in that sector (and all the sectors that are visible from that sector) to determine if they are within the frustum or not.

    EDIT:
    SAMSAM I have no clue why degrees are used anywhere, radians make more sense. My math teacher (he's a really old guy btw) threatens to beat us up whenever we mention degrees instead of radians. I would also like to know why glRotatef uses degrees instead of radians, I mean come on radians are rotations. I would bet money that OpenGL only does that because people are more comfortable with degrees, that you pass in a degree measure but opengl converts it to radians and then performs the necessary operations.
    Last edited by Shadow12345; 02-20-2003 at 09:14 PM.

  6. #6
    Crazy Fool Perspective's Avatar
    Join Date
    Jan 2003
    Location
    Canada
    Posts
    2,640
    hmmmm... space partitioning sounds like alot of work. i think im just gonna keep 5 plane equations (ie. the frustum) and check world coordinates to see if objects are inside the viewable region or not. thanx for the help!

  7. #7
    Shadow12345
    Guest
    Actually there are usually 6 planes when creating volumes, technically it can and sometimes is 5 planes, but you've got the back plane and sometimes the plane closest to the camera which constitutes six altogether.

  8. #8
    Crazy Fool Perspective's Avatar
    Join Date
    Jan 2003
    Location
    Canada
    Posts
    2,640
    yeah, thats right. but if i calculate the 5 plane equations based on the camera position then the 'front' plane (closest to camera) is just orthogonal to the camera direction, so world coordinates of objects behind the camera's point are behind the front plane. this would save storing the front clipping plane and the camera's position as 2 different things. i only need the camera position/direction and the left, right, top, bottom, and back planes.

    this all sounds fine and dandy in theory, i assume doing the plane calculations and coordinate comparisons for every frame will take considerably less time then projection calculations for thousands of polys that dont even get rendered.

    does this seem logical to you shadow12345? any other suggestions are welcome.

  9. #9
    Shadow12345
    Guest
    Yes calculating which objects are within the frustum and only rendering those is much less expensive than just rendering every polygon. That's why it's done.

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. 3d graphics without API
    By h3ro in forum Game Programming
    Replies: 6
    Last Post: 05-31-2008, 11:51 AM
  2. Odd 3D Invis Objects?
    By Zeusbwr in forum Game Programming
    Replies: 4
    Last Post: 12-07-2004, 06:01 PM
  3. 3D starfield
    By VirtualAce in forum Game Programming
    Replies: 6
    Last Post: 06-26-2003, 12:40 PM
  4. 3D SDK for C++ programmers
    By chand in forum Game Programming
    Replies: 2
    Last Post: 05-20-2003, 07:38 AM
  5. 3d engines
    By Unregistered in forum Game Programming
    Replies: 7
    Last Post: 12-17-2001, 10:19 AM

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21