Order of operations in  frustum culling.

OpenGL Development JOGL Development
#1

Project:
Simple brute-force terrain divided up into sections. Each section has a bounding cube used for culling. The camera implements gluLookAt().

Current order of operations:

  1. calculate frustum
  2. call gluLookAt()
  3. cull landscape sections
  4. draw landscape sections

Performance and appearance of scene:
Performance nearly doubled, and the scene looks fine.

Weirdness:

  1. No matter where the camera moves in the scene, the
    number of culled sections remains exactly the same.
  2. Even though the reported number of culled sections
    remains static, the frame rate goes up dramatically
    when the camera is pointed directly at the ground, or
    moves to the edge of the scene and looks “out into
    space”.

Observations/Questions:

  1. How can those 2 facts be explained? I would say that
    the code I am using to report the number of culled
    sections is faulty, but it is so simple that I don’t THINK
    I could have it screwed up :slight_smile:
  2. As far as the order of operations goes, it seems like
    the intuitive thing would be:
    A) Call gluLookAt() to move camera.
    B) Move objects in scene.
    C) Calculate frustum.
    D) Cull
    E) Draw
  3. I tried the ‘intuitive’ approach, and it culls items
    that should easily be visible, whereas the first
    order of operations listed in this post seems to work
    fine execpt for the issues listed in the ‘weirdness’
    section.

Thanks for your input :slight_smile:

#2

What actually gets drawn still effects performance.
Depending on your graphics card and your scene, you may be geometry bound of fill bound. When the camera looks down or up, the final frame renders much less geoemtry, possible as low as 1-2 triangles but fills the entire screen with pixels. If the card can hande the pixel fill then performance will increase for that view.
Also terrains are a notorious rendering problem. When looking out over a terrain, the amount of triangles AND pixels is often highest because of the fact that the view can see far into the distance requiring a lot of geometry and horizon pixels are overdrawn many times requiring more pixel fill as well.

#3

Thanks for the speedy and informative answer. Since you didn’t say that my current order of operations is incorrect, may I assume I can leave it the way it is?

Also, if the operations are in the correct order, I clearly don’t understand how the process works since I don’t understand why the number of non-culled terrain sections always remains the same. Could someone explain this to me?

#4

You can’t calculate the frustum before you call gluLookAt…

Cas :slight_smile:

#5

So this is correct?

A) Call gluLookAt() to move camera. 
B) Move objects in scene. 
C) Calculate frustum. 
D) Cull 
E) Draw
#6

yip … although I normally change positions before calling my camera position method, which is gluLookAt() for you.

always stay with the intuitive one. I just presume that there is a culling error in your frustum class, or when you calculate the planes. minuses are easily placed on the wrong side :slight_smile:

Kenzo

#7

I’ll get to work looking for an error then. Thanks for the input. One thing for sure; if it wasn’t for the community, questions like this would go unanswered :slight_smile:

#8

Well…after looking at my code for calculating the frustum, I’m reminded of a promise I made to myself a couple of months ago: “I will never copy and paste in a computer program again. Ever.”.

So, I’m going to make a new promise: “I will never copy and paste in a computer program again. Ever.”. :slight_smile:

#9

hehe … know the thing! But sometimes you can learn great things of other peoples code. I always rewrite the code in my own style, so I can make sure I understand everything I take over … ! So it works now ?

#10

I haven’t tried it yet, but I will here in a bit. The copy and paste part is worse than you think: I was too lazy to type the frustum calculations for each of the 6 planes, so I did it once, copied, pasted, and ‘made the necessay adjustments’ to each plane afterward. Well, I didn’t make all the adjustments :slight_smile: There were 12 places where there was a ‘-’ and there should have been a ‘+’. I would imagine that is going to make a difference!

The code is 100% borrowed from a book I found, so I can’t take any credit whatsoever for creating it, but I take all the credit for mutilating it.

#11

Well, Guoshima, it still culls partially visible chunks of my terrain, but I believe this is due to the fact that the algorithm tests the corners or the bounding box for inclusion in the frustum, and, since the bounding box for each terrain chunk is quite large, the camera can get itself into a position where the chunk is partially visible, but none of the corners are. I assume that using a bounding sphere would solve this problem, and will try it soon.

#12

you can take a look at http://www.gametutorials.com, they have a nice frustum tutorial class which you can use. It implements all these things, but can use a little bit of optimization. Can send you my version if you want to … just mail me.
Mine partially based on this and on Game Programming Mathematics from Lengyel (great book).