First, some introduction. I'm working on a game engine for my virtual reality class in the short term and for general game developing in the long term. I want to build the whole thing as a tree of objects that can have scripting, geometry, communication with each other and various other optional properties. In order to maintain portability and make this useful both for right now and for later, I also want to set up the major components (windowing, input, rendering, sound, etc) as plugins with interface classes.
My first question is about the actual rendering of triangles from meshes in the scene graph. The best idea I have right now is to define a material class that has lighting, textures, etc in it and keep a list of materials in a manager class. Then, whenever an object requests to have a mesh associated with it from the model manager I have the model manager go into the model file, find all the materials and send them to the material manager (getting indices back), and then go on and load the mesh. This way I have only load each model once, and I only load each material once (now that I'm thinking about it, I should have a texture manager that the material manager sends requests to too). So now I have all these materials loaded into memory, and a bunch of meshes defined as triangles with indices into the material list.
Now I define a renderer class with several lists of triangles, organized by material. I define a max size for the number of lists and the number of triangles in each list. When a list of triangles is full or when I need room for a new list or when I flush at the end of rendering, I switch rendering states and send the list of tris to the gpu as a display list or whatever. This should run fast because it minimizes state changes, but the drawback is that I have to transform all my vertices to world-space before I start rendering. Is this a good method?
My second question is about culling for rendering and collision detection. My idea here is to have every mesh in the model manager have an associated bounding box. Each frame, I would do a preorder traversal of the graph. If the node isn't declared as static, I get the bounding boxes for all its children and determine a bounding box that contains all of the children and the current node's geometry (if it has any) and return that. If the node is static, then I assume it was preprocessed and I just get the bounding box at the top. At the end of this traversal, I have a bounding box for each node that contains all of its children. I can use this to cull my rendering and to limit my collision testing. The clever part of this, I think, is that you can define parts of the world that don't move (and things that are currently not moving) as static, and then they don't need their bounding boxes updated. You could use this to implicitly build a terrain quadtree or an octree into the scene graph. So my question is, is this going to be good compared to traditional (quadtree, bsp, octree) methods?