Original Post
Okay, I am a bit stuck coming up with a really efficient drawing method. Here is what I have to work with: A SceneGraph and an Octree. Consider the scene graph to be a direct representation of how the scene should be drawn, from a top down order, if all transformations were applied in order. The octree is a physical representation of where the objects are located. Currently, here is what I am doing. I am going through my scene graph, applying all transformations, and saving the current model view matrix. After saving the current model view, check against the last model view, and see if the object has moved. If it has, remove it from the old location in the Octree and replace it back in to a new node. I am making as many short cuts as possible, like storing where the object was in the tree for immediate removal (O(logn) vs O(1)...meh), and even storing the actual list iterator location so I don't have to use std::list::remove. When it comes time to draw, I go through the octree. I see if the current node is in the view frustum. To do this, I use the node's x,y,z location and a 'radius' that encompasses the entire node -- I already had a sphere frustum collision method. If the node is inside the frustum (or collides), I draw any geometry attached to that node (technically, there is a bug in here that I can't find ... but that is for another post). When I draw the geometry, I call a simple glPushMatrix(), glLoadMatrixf( modelView ) [modelView is what we stored during the update], and then glPopMatrix(). I then check the children. If it is not in the view frustum, I return. With a couple hundred triangles, my FPS are already seriously dropping. They were about 100-150 before I implemented this octree method, where I just parsed straight down my scene graph -- but now I am at about 30 or 40. Maybe 50 on a good day. So I suspected that it was the glGetFloatv and the glLoadMatrixf that were causing the major slow downs. I ran Shark (a MacOSX sampler), and it said most of my time was being used on: gldGetString() -- ATIRadeon9700GLDriver -- 7.4% isSphereInFrustum() -- My Code -- 5.9% szone_free -- libSystem.B.dylib -- 5.9% szone_malloc -- libSystem.B.dylib -- 5.0% gleSetAttrib() -- GLEngine -- 4.9% gleGetAttrib() -- GLEngine -- 2.7% Suprisingly, glGetFloatv and glLoadMatrixf both use "0.0%" of the time. Negligible. Anyway, it makes me wonder as to what caused this major slow down. I mean, I am drawing 200 triangles, and my system feels like its drawing 2000. Any thoughts as to what this could be? I got rid of the isSphereInFrustum() call and I got about a 10fps boost -- at the cost of no culling. Any thoughts as to a better way to implement my drawing scheme? Thanks!