Right now, Ogre's terrain system is confined to height maps. I would like to extend OGRE's terrain support to include Vector field terrain. The basic Idea is to allow terrain data points to contain vector valued displacement instead of scalar Height only. A complete implementation of this concept was made for Halo Wars, and a presentation about it can be found here:
http://www.gdcvault.com/play/1277/HALO- ... Terrain-of
Advantages over Height Fields:
- Displacements in arbitrary directions helps create organic looking terrain as opposed to the "sheet draped over" look of height fields.
- Overhangs and cliffs come naturally.
- Eliminates texture stretching, as vertices can be swept horizontally from places with lower detail to places that need more detail.
- Conceptually simple extension to existing height field systems.
Vector field terrain is superior to height fields in terms of appearance and control offered to the artist. It is a simple extension to height fields, and can be implemented with relative ease in the specified amount of time.
Is this project within the core scope of OGRE?
Yes, as this is an extension of the terrain system, code that already belongs to the OGRE core.
Some Screen Shots: Major issues and ideas:
1. Too much data: Vector fields triple the amount of data that needs to be stored. This means some sort of compression needs to be put in place. The Halo wars presentation went ahead with an uncompressed 1280x1280 data grid for the terrain, which came out to be around 14 mb. This is because their original wavelets implementation turned out to be too slow for the 360. However, hardware has moved on. Therefore, I will experiment with some sort of block based differential encoding, as this, hopefully will give an optimum mix of compression and speed. I would also experiment with coding using Gpu-based DCT, if time and performance permits. This is because as opposed to wavelets, proven GPU implementations of DCT are already available in the public domain.
2. Use of skirts to stitch terrain tiles in the current implementation: The current terrain system uses skirts to stitch together adjacent terrain tiles. This only works under the assumption that all displacement is height only. With vector fields, the skirts would have to be done away with, and some sort of stitching algorithm would have to be put in place. I propose using the snap function method used in the "Semi-Uniform Adaptive Patch Tessellation" paper. It can be found here:
http://folk.uio.no/erikd/pdf/topofix_draft.pdf
3: Collision Detection: The current terrain collision detection system relies on height fields, and Vector fields pose additional challenges. One way to handle them would be to treat terrain as regular geometry. This would mean creating a lower res version of the visual geometry and passing that to the collision detection system. The other approach would be to create a depth-only render of the top view of the terrain, and use this to create a height field for collision detection. This is the approach used in Halo Wars. I would like to implement the halo wars version first, as this fits nicely into the current terrain system, and, if time permits, do the other.
4. Doing away with Geomipmapping: The Halo wars implementation uses the hardware tessellator of the 360 for LOD. We could do the same on DX11 with hardware tessellation. However, the DX11 rendersystem is still WIP, and we would very much like to support dx10 and OGL 3. Hence, I propose using instanced tessellation, using Instance Cloud Reduction for View Frustum culling.
Instanced Tessellation: http://developer.download.nvidia.com/pr ... atible.pdf
Instance Cloud Reduction: http://rastergrid.com/blog/2010/02/inst ... y-shaders/
http://rastergrid.com/blog/2010/06/inst ... -reloaded/
5. Lightmap Generation: The current lightmap generation algorithm relies on heightmap ray casting. This would need to be modified for vector field terrain. I would be converting the vector field geometry to triangle meshes, and use standard ray tracing algorithms and acceleration structures.
6. Editor Support: As Vector fields are a relatively recent technology, standard tools are not available that deal natively in this format. Fortunately, converting triangle grids to this format is straightforward, and can be considered for importing terrain data from various sculpting tools. Vector fields require more sculpting tools than height fields, and many of these tools are standard in high end sculpting programs like Mudbox and Zbrush.
http://usa.autodesk.com/adsk/servlet/pc ... eID=123112
http://www.pixologic.com/home.php
A selection of such tools:
- Displace in View direction.
- Displace along Camera.
- Sweep vertices keeping topology unchanged.
I will be creating bare-bones importers and tools for testing purposes. However, Creating a polished terrain editor and exporter is beyond the scope of this project.
Proposal Timeline:
May 14- May 20 (Initial Evaluation, 1 week):
- Get to know my mentor.
- Get familiar with the New terrain system, and lay initial groundwork.
- Implement basic vector field displacement within the New Terrain framework.
- Remove skirts and replace with snap function based stitching.
- Implement Top view depth rendering, and use that for height field based collision detection.
- Implement bare-bones exporter for testing.
- Implement Block based Differential Encoding. Experiment with various block sizes.
- Evaluate performance.
- Create tool for converting from uncompressed image to our compressed format. Create new codec for loading compressed terrain data.
- Make modifications to the existing Hierarchical geometry batching code to incorporate instanced tessellation.
- Implement instanced tessellation on 16x16 terrain tiles. Experiment with various tile sizes.
- Implement instanced cloud reduction for view frustum culling.
- Evaluate features that might have been broken due to modification, and get these features working as before.
- Improve basic exporter.
- Add Displace along normal, and displace along view direction tools.
- Add Sweep vertices tool.
- Get any overflowed work done.
- Prepare for Evaluation.
July 14– July 27 (Light Maps, 2 weeks):
- Write code for converting vector field height maps to triangle mesh.
- Create Ray-tracing acceleration structures(Kd -tree) from the mesh.
- Implement ray-terrain intersection using the kd-tree.
- Hook up with current light map generation code.
- Implement triangle mesh based collision detection system.
- Experiment with DCT based compression.
- Write documentation.
- Handle any unfinished work.
The terrain system would benefit from a refined and polished editor. Various editing tools could be added to Ogitor, improving on the bare bones tools available by the end of the project. Also, exporters for various content creation tools would have to be made.
Why I am the person for this project:
I am a third year Electronics student at Indian Institute of Technology, Roorkee. As there is no real computer graphics program in our university, I have been doing countless hours of self study. I finally have the opportunity to put all that work to good use.
I have a real passion for computer graphics, and have had that passion since 8th grade. At this time, i taught myself some Maya and mental ray. Here are some links to works from this time:
http://www.3dm3.com/forum/f195/peace-de ... asu-15373/
http://www.3dm3.com/forum/f201/incomple ... asu-15673/
http://www.3dm3.com/forum/f195/viper-de ... asu-15376/
After getting into college however, my interests changed to programming, and my journey has been on ever since. Here is a summary of my skills and experience:
- Have excellent background in Mathematics and physics.
- Have followed recent research in various fields of realtime graphics, including GPU raytracing, Micropolygon pipelines, shadowing algorithms etc.
- Have started a computer graphics group at the software development section, IIT Roorkee, in order to create a graphics and game development following there. I mentor students, conduct lectures, etc.
- Have been following OGRE's development since 1.6. At this time, I was somewhat new, and OGRE helped me learn about graphics engine organization. Even though it has been some time since I was involved with OGRE, I am still familiar with the basic structure and function.
Why OGRE?
I have been following Ogre's development since 1.6, and the OGRE sources were a great source of information and inspiration for me. It is what got me into computer graphics. It has always been a great influence on my coding style, and has been a ready reference for various algorithms and techniques. I would love to utilize the knowledge and experience I gained over the years to give back to the open source rendering platform that taught me the most about real time graphics.
(Proposal Ends here).
I would like to thank everybody for helping me finalize the topic. I would also love your comments and suggestions regarding this proposal.
Thank You,
Debdatta Basu.