 Lightmapping I recently wrote a nice 24 bit ray-cast lightmapper. An interesting project as I had never written one before. It was really nothing special but at first I had all these small textures for lightmaps and they were really slowing things down when switching between them. And so I decided to put a whole bunch of lightmaps on one big 256x256 texture in some optimal fashion so in any given scene I changed lightmap textures only a few times. This seems like a really obvious approach now but it didn't when I started. I'm sure others have done it before me, but it's always nice to come up with something you haven't heard of before. After I did this I heard that q3a does it. (or so I was told.) Anyway you can check out the results of that and of some of my other projects at http://www.rpi.edu/~hodorl/ Visibility Thoughts: C-Buffer and Hardware Acceleration Here's a thought. I've heard it described before, but with software implementations. I haven't implemented it but it seems like a good idea to me. Usurping OpenGL's glFeedback() function, you can get the position of the 2D polygons that end up on the screen. So if world geometry was set in an oct-tree, you could draw front to back, and use glFeedback to get the vertices of the 2D faces on screen. You then add the faces to a C-Buffer. When drawing each of the leaf nodes of the oct-tree, you test to see if the bounding box of the leaf is visible using the c-buffer. If it is, add the faces in the leaf to the frame buffer and c-buffer. Repeat until screen is nicely filled or you run out of nodes to draw. This could also work with moving objects, as long as they are placed in the proper nodes at run time. LOD Thoughts Another idea I've been throwing around are some thoughts on level of detail models. Mostly landscapes, but this idea I think could work for any type model or even landscapes with overhangs. Pretend there is this great primitive called LODPatch. Each LODPatch is really a square binary triangle tree. Each patch throughout the model has the same number of triangles at each level and has the same number of levels. Each patch also has 4 pointers to the adjoining patches at the edges. When rendering is about to happen, you first determine if the patch is visible and what level you want to recurse to in the tree based on distance, roughness, or whatever. Then you make sure that no adjacent visible patches differ in level by more than one. It is then a simple matter to draw these patches to a set level. By checking the adjoining patches you can easily check which edges need to be split farther to get rid of cracks and T-junctions, since adjoining patches differ only by one level. To get rid of popping, I would think it's pretty easy just to linear interpolate between detail levels based upon some linear distance function. Luke 
|
