I’m Peter Szücs and I’m studying Master of Computer Engineering at Budapest University of Technology and Economics.
Sorry for the late proposal. I hope it's not too late.
It's waste of performance to have high quality models in faraway distance. Games can gain lot of performance by reducing faraway models and Ogre provides two methods for this: Manually created mesh LOD (for example in Blender) and generated mesh LOD. Blender supports nice reduction algorithms, why don't we just use that? First manually created mesh LOD creates a separated mesh for each LOD level, which means vertex data is duplicated for each LOD, which makes a big memory overhead. The memory overhead is needed, because Blender moves the vertices from original position to a calculated new position, so we need a separated vertex buffer too. Why don't we use Hoppe's algorithm or other more advanced techniques for reduction? These techniques have got the same problem as Blender. Also it would add limitations: For example if the mesh has bone weights or custom vertex data passed to a vertex shader than you can’t just insert a vertex. So the goal of my GSoC proposal is to improve current progressive mesh algorithm.
How to use it currently?
The progressive mesh algorithm was rewritten multiple times and the interface differs between v1.7, v1.8 and v1.9. I have created the MeshLod sample for v1.9 to show the LOD features. However if you just need more performance, you can run the following code on every mesh:
Code: Select all
Ogre::QueuedProgressiveMeshGenerator pm; pm.generateAutoconfiguredLodLevels(mesh);
I would like to do 6 independent tasks related to progressive mesh:
- Compress LOD levels: I had an idea to compress LOD by up to 50% without performance degradation! My idea is to merge 2 index buffers into a single merged index buffer. The merged index buffer would consist of 3 parts. Let’s say we merge LOD1 + LOD2, then the beginning of the buffer would LOD1 faces only, second part would be LOD1+LOD2 shared faces and the third part would be LOD2 only. Imagine it as a frame shifting mechanism, where I just change the offset and size of the buffer instead of swapping buffer. (1 weeks of work)
- Take into account vertex normals: This one is the most visible artifact in the output currently. Try out the MeshLod sample and check the color above the mouth while you reduce Sinbad.mesh. At 50% its dark, 52% its bright, 57% its dark. This is caused by self-shadowing. Fixing this would improve the quality of the output. <TODO: Create document explaining the possible algorithms and add references> (3 weeks of work)
- Allow to profile LOD weights: Sometimes the generated LOD with high reduction looks nice…except just a single vertex which messes up the whole mesh. This may be a bug in the algorithm. In that case you need to reduce fewer vertices? Well what if you could just fix that single vertex. The idea is to create a small sample in the SampleBrowser where the artist can select (or step by step reduce each) vertex and change the weight of it manually. This also helps debugging progressive mesh algorithm. (2 weeks of work)
- Weighted outer wall: This would be an optional feature and it may not be related to all kind of meshes. When I have made a visual benchmarking system for LOD in worldforge, we have noticed, that buildings are reduced less than other models. This is caused by the fact, that the wall has two sides and there are static objects inside the building. The algorithm currently doesn’t care on what is visible from outside and what not. The idea is to detect the outer wall of the reduced mesh in a pass before processing the progressive mesh algorithm. Also You can set the strength in the range 0-1 on how much should this influence the output (0=off;1=keep outer wall only) This would drastically increase efficiency of meshes which has internal faces like buildings. I couldn't find an algorithm for this problem, but I have planned my own algorithm and I would like to implement it. <TODO: Create document explaining the algorithm> (4 weeks of work)
- Allow to mix automatic and manual LOD: The idea is that you can reduce LOD1 by 50%, for LOD2 you use a manual mesh and for LOD3 you reduce the manual mesh by 50%. So it would make a hierarchy of LOD levels, which allows mixing automatic and manual mesh LOD levels. (1 weeks of work)
- Create effective manual mesh: The idea is that you can use your favorite editor (like Blender) and restructure faces and remove vertices there, but you should not create new vertex positions! Then with a tool (maybe OgreMeshUpgrader or MeshMagick) you can bake it into the mesh as index buffer only LOD. (2 weeks of work)
In the past 2 GSoC years I had less time in the first month caused by exams, but this year it is shifted a month and I will have time from the beginning to the end! Also I normally go to holiday for a week during the summer, but the date is not yet specified. I would suggest the following schedule:
- Now - June 17: Community Bonding period
In the bonding period I have most of the time exams, so I will not have much time. (Currently I’m having less time too). I’m focusing on how to implement new features into Ogre. I will create a prototype for the outer wall detection algorithm. Create algorithm documentations on how everything works mathematically, what kind of advantages/disadvantages it has and discussing this with the mentor.
- June 17: Coding starts ***
- June 17 – June 24: Compress LOD levels (1 week)
This just needs changes in the baking, but baking is separated between threaded and non-threaded implementation and both needs changes.
I need to change ProgressiveMeshGenerator::bakeLods, ProgressiveMeshGenerator::PMTriangle, PMWorker::bakeLods()and PMGenRequest structure
- June 24-July 15: Take into account vertex normals (3 weeks)
This needs 3 weeks, because it also needs some experimenting, because there are multiple solutions. I could just compare the dot product from source to destination, but it may look better if I count the overall angle of the vertex before and after the reduction.
I need to change ProgressiveMeshGenerator::PMVertex, ProgressiveMeshGenerator::PMTriangle, ProgressiveMeshGenerator::computeEdgeCollapseCost.
- July 15 - July 29: Allow to profile LOD weights (2 weeks)
Create ProgressiveMeshGenerator::setProfileData, where you can pass the custom weights based on vertex position. Creating a sample with an interface for profiling LOD and allow to export the mesh with the MeshSerializer. ?How to select the mesh?Cross platform file selector?
- July 29-August 5: Catch up delays or holiday (1 week)
NOTE: I may go later on holiday and I may already start next task before Mid.
- August 2: Mid Term Evaluation ***
At this point I should be ready with first 3 tasks.
- August 5-August 26: Weighted outer wall (2 weeks)
This will be an optional pass before progressive mesh. It will be in a separated class. The goal is to calculate convex hull and do the appropriate calculations on the data. However before coding starts, I want to create a prototype of this, so that I can prepare for issues and make the schedule more stable.
- August 26-September 9: Weighted outer wall improvements (2 weeks)
I will implement an optional feature to use few ray traces to improve approximation quality, but I will decide this based on the results and current progress/delays. I may find other ideas at that date to improve it.
- September 9-September 16: Allow to mix automatic and manual LOD. (1 week)
This needs some Core changes in the LOD handling.
- September 16: Soft pencils down ***
- September 16-September 23: Clean code, improve documentation. (1 week)
- September 23: Firm pencils down ***
- September 23-October 7: Create effective manual mesh (2 weeks)
This will be an after GSoC task for completeness. This is not related to the core, but to the tools.
I was participating in GSoC 2011 and GSoC 2012 at Worldforge on Ogre related tasks. Both were success. I know Ogre3D quiet well. I switched the GSoC organization, because I always worked on Ogre3D there (but I still like to contribute to worldforge too ). I know the workflow of GSoC quiet well too. I'm proficient in C++ and experienced in the internals (compiler/linker/OS). I have experience in free and open-source development on Windows, Linux and OSX. I have experience in 3D geometry algorithms, 3D graphics and shaders too. I have developed the current progressive mesh algorithm in Ogre3D v1.9, so maybe I know it the best on what/why is written as it is.