Main idea of the project is to replace the current brute force approach of distance dependent LOD for rendering heightmaps to a Continuous distance dependent LOD in Ogre3D.
Project Proposal
The current LOD system in terrain simply pops the mesh when its transition has to take place.
This implementation has several issues like it consumes memory as each pre-calculated tile mesh has to stay in memory even if they are not queued to render. Also notice the sudden drop in FPS.
The proposed system will eliminate this issue by dynamically altering the vertices and indexing of the tile mesh that would look somewhat like this.
Project is aimed at implementing the system good enough to be merged to the main trunk, and the final result would be reflected in Ogre’s Terrain Demo.
Implementation
There have been many implementations that have been made that I’d refer to
- 1)Nvidia
2)Vertexasylum
1). Quadtree traversal and node selection:-
Heightmaps are arranged into a quadtree, then use the best quadtree nodes from different LOD levels at run time. Ogre already has a Class TerrainQuadTreeNode to take care of it.
2). Morph implementation:-
Each vertex is morphed individually based on its own LOD metric, where the morph is performed per-node. Each node supports transition between two LOD layers: its own and the next larger and less complex one. Morph operation is performed in the vertex shader in such way that every block of eight triangles from the more detailed mesh is smoothly morphed into the corresponding block of two triangles on the less detailed mesh by gradual enlargement of the two triangles and reduction of the remaining six triangles into degenerate triangles that are not rasterized.
3). Rendering:-
To render the terrain, we iterate through the selected nodes and their data is used to render
the patch of the terrain that they cover. Continuous transition between LOD levels is done by
morphing the area of each layer into a less complex neighbouring layer to achieve seamless
transition between them.
Schedule
<<ACCEPTED PROPOSALS ANNOUNCED>>
- May 27~June 16(3 weeks) Setup developing environment. Read research papers and other implementations. Understand Ogre’s infrastructure. Discuss best ways to approach the problem with community and mentor.
- June 17~June 14(4 weeks) Begin implementation
June 15~July 21(1 week) Benchmark and Optimize
July 22~July 28 (1 week) Documentation
July 29~August 4 (1 week) Test and Deal with Mid-Term Evaluation
- August 5 ~ August 25 (4 weeks) Complete the project
August 26~ September1(1 week) Benchmark and Optimize
September 2 ~ September 15 (1 week) Documentation
- September 16 ~ September 23 (1 week) Test
- September 24 ~ September 27 (1 week) Deal with Final Evaluation
Why You're The Person For This Project
I’m a Third year undergrad computer science student of Meerut Institute of Engineering and Technology. I love video games and always keep asking myself while playing them the same question, “How do they do it!”.
To be really honest, I’ve been reading a lot lately about the project lately but sparingly understood the exact implementation. However my commitment towards becoming a good graphics programmer has always helped in tackling such scenarios. Also, part of my work on Crystal Space engine under GSoC 2011 was based on the project I’m proposal. It’s a definitely a plus. Having said that, I’m pretty sure with the right guidance from an incredibly supportive Ogre community I’d bring some eye-candy to the table.
Why OGRE?
Not only Ogre is a great rendering engine but it also have a very strongly community and followers. Also, Recent use of Ogre in medical simulation has deeply impacted me to work with on it.
Anything Else
Apart from practical exams for 3 days on random unknown dates I have no other commitments for this summer.