I'll try and keep this post short. After a few discussions on IRC, the mesh simplification idea explained in the previous post might be better left for until after the midterm evaluation. Until then I should focus on the CHC++ implementation in order to determine exactly what the bottlenecks, in terms of speed reduction, are. I also should provide some hard numbers to back up any results I find. So, that's what I'm gonna' try and do. Having Mike Gist's implementation as a reference I hope I'll make some good headway. Having merged furstvis in the render manager I'll take a few different approaches in a few key points (such as mesh rendering for occlusion queries) than my mentor did in the hope it'll provide more speed boosts. That's all for now.
Ok...so I've been trying the past few days to get some headway on the occlusion culling. After resorting to drawing the meshes quicker with a variant of the DrawMesh method (available in the OpenGl plugin), I have tried several schemes involving bounding boxes in order to reduce the query overhead. Unfortunately all of the methods I have tried have all sorts of corner cases where the culling scheme either culls geometry incorrectly or it is extremely conservative, culling far to little. The methods that have cases where geometry is culled incorrectly aren't well suited for a general culler. The ones which are too conservative aren't very good because they don't really do very efficient work.
So...what to do? Well, as far as I can see, with the midterm deadline approaching, there's only one sure way to get some results which are to focus on implementing a mesh simplification algorithm. This has several advantages:
1) There already exists a basic implementation, written by my mentor with the CHC++ algorithm in mind. The main problem with it is the overhead created by rendering the same geometry twice. By rendering simplified, but accurate, meshes for occlusion queries the overhead will be eliminated enough to make using the CHC++ algorithm practical.
2) The mesh simplification scheme will enable the new culler to work for generalized models and scenes.
So which algorithm to use? Well, there has been numerous research related to the topic of mesh simplification. I've been doing some research today and the algorithm that seems most promising in terms of speed, accuracy and generality is Garland and Heckbert, which uses a quadric based polygonal surface simplification scheme. There's very little time left until the midterm evaluation and I hope to have this algorithm functioning by the 11th of July. Once that's done I can integrate it into the the CHC framework.
I'm cutting it close on time as far as midterm evaluations are concerned, but I hope I'll have some concrete results come the mid-deadline. I'll provide some updates as I progress into the implementation of the mesh simplification algorithm.
Hello there. I'm rather late writing this post, for which I apologize. What I've been doing until now is trying to integrate the chc algorithm into CS by using a modified version of the unshadowed render manager. This has meant integrating support for occlusion queries into the OpenGl renderer and modifying frustvis to interract with the modified unshadowed version I mentioned.
My mentor, Mike Gist has done some work related to hardware supported occlusion culling in CS. Unfortunately the work he did was centered on rendering the polygons in a scene twice in order to be able to see which ones would be occluded. This unfortunately has the issue of added overhead of rendering the same geometry basically twice. I've been trying to improve this through the use of bounding boxes. This is to say render a bounding box mesh in order to test for occlusion. This unfortunately has some quality draw backs:
The first pictures shows the houses in front and a third one in the back. We also see the bounding box outlines to get a better idea of what's going on.
From the second picture we get a pretty good idea of what's going on, wrong. The idea is that as the two bounding box meshes approach each other and begin to overlap, the third house dissapears. Why? you ask? Well even though, the house should be visible, the over conservative bounding box meshes obscure the third house's bounding box mesh completely, thus leading to wrong visual results.
So what to do?
Well, I can think of several schemes to solve this.
1) Decide before the rendering which objects are to be considered occluders and render them normally, all the other meshes (occludees) being rendered with as a boudning box mesh when testing visibility. This would avoid the problem seen in the pictures above.
2) Render the objects as simplified meshes when testing for visibility. This is technically the best solution, as it leads to a compromise between the bounding box mesh solution and the initial 2-pas rendering. We render lower detail meshes that strive to preserve the original's shape characteristics. This would save most of the overhead of drawing when testing for visibility and also alleviate the accuracy problem of bounding boxes.
As my mentor suggested, one method to cut down on the over ehad would be to introduce a "direct" way to render geometry. This would bypass most of CS' abstractions and simply draw basic geometry data (no textures, shaders or any other additional stuff). This will be my next target and after that I'll discuss which of the ways described above would be most feasible.
Stay tuned for further details in the coming days. Over and out.
...and Crystal Space. My name is Claudiu Mihail and I will be trying to improve Crystal Space's visual culler system during this year's Google Summer of Code.
As this project aims to take advantage of next generation chip-set capabilities the new culler will be build (at least in part) from the ground up. After some talking with my mentor and other Crystal Space developers the direction to go is to start a new plugin. This is going to be a rendermanager plugin that, in time, should replace the current one. Steps to follow for this are:
1) Base the new rendermanager plugin on the unshadowed code alraedy in place
2) Cannibalize code from the frustvis plugin (which implements frustum culling) and integrate it into the new render manager.
3) Once 1) and 2) are completed I can begin adding occlusion culling and begin implementing the CHC culling algorithm as described in my application plan.
The main challenge in this endeavor will be to understand and use the code already in place. Since CS is a pretty complex project I hope this won't pose to much of a problem.
As I progress further into my work I will be keeping everyone updated through this blog. But enough chatter, time to get to work.