[GSoC 2011]{EDIT}Proposal draft is up: Vecor field terrain.

Threads related to Google Summer of Code
Post Reply
debdatta_basu
Kobold
Posts: 31
Joined: Thu Jun 10, 2010 4:32 am

[GSoC 2011]{EDIT}Proposal draft is up: Vecor field terrain.

Post by debdatta_basu »

Proposal for adding Vector Field terrain in OGRE:

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
Height Field (Image Courtesy: Halo Wars Presentation)
Height Field (Image Courtesy: Halo Wars Presentation)
Vector Field (Image Courtesy: Halo Wars Presentation)
Vector Field (Image Courtesy: Halo Wars Presentation)
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.
How will this project benefit OGRE users?
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:
Image Courtesy: Halo Wars Presentation
Image Courtesy: Halo Wars Presentation
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.
Will be sufficient for most practical purposes. These tools can be added to the current editing system with relative ease.
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.
May 21 – June 3 (First steps, 2 weeks):
  • 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.
June 4 - June 10 (Differential Encoding, 1 week):
  • 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.
June 11 - July 1 (Doing away with Geomipmapping, 3 weeks):
  • 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.
July 2 – July 8 (Tools, 1 week):
  • Improve basic exporter.
  • Add Displace along normal, and displace along view direction tools.
  • Add Sweep vertices tool.
July 9 - July 12 (Grace Period, 4 days):
  • Get any overflowed work done.
  • Prepare for Evaluation.
JULY 13th: MID TERM 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.
July 28 – August 10 (Extras and Documentation, 2 weeks):
  • Implement triangle mesh based collision detection system.
  • Experiment with DCT based compression.
  • Write documentation.
August 11 – August 17 (Grace Period, 1 week):
  • Handle any unfinished work.
Future Extensions:

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.
I currently have no related projects to share. This is due to a variety or reasons, the major one being the lack of uninterrupted time to work on one. However, I can vouch for the depth of my knowledge and the extent of my abilities, and one chat with me will be sufficient to convince you of the same.

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.
Last edited by debdatta_basu on Fri Apr 08, 2011 5:23 am, edited 15 times in total.
User avatar
tuan kuranes
OGRE Retired Moderator
OGRE Retired Moderator
Posts: 2653
Joined: Wed Sep 24, 2003 8:07 am
Location: Haute Garonne, France
x 4
Contact:

Re: [GSoC 2011]Irregular z Buffer shadows and other ideas.

Post by tuan kuranes »

1 & 2) check dx11 ogre rendersystem status, and what you would need to add ot achieve youre goal.

1) a single shadowmapping techniques seems a bit narrow scopes. check ogrer demo shadow and intel shadow explorer (intel code paper on Adaptive volumetric shadow maps (AVSM) or Sample Distribution Shadow Maps (SDSM)) in order to make a list of deliverables.

2) did you check ogre RTSS and how you could build something on it.

3) Vector field displacement terrain, like Halo did and explained in the Halo Wars GDC presentation, "The Terrain of Next-Gen." , is a very welcome application and a huge work already that would be sufficent on its own for a gsoc. (not only direc implementation, but also Ogre terrain and paging system integration and enhancment in order to use it.)
FYI, A fully working voxel engine on top of Ogre already exists (http://www.ogre3d.org/forums/viewtopic.php?f=11&t=27394).
debdatta_basu
Kobold
Posts: 31
Joined: Thu Jun 10, 2010 4:32 am

Re: [GSoC 2011]Irregular z Buffer shadows and other ideas.

Post by debdatta_basu »

@Tuan,

1 & 2) These would not require much changes to the render system at all, although (1)Would require compute-graphics interop, which is a breeze for dx11, and can be set up in opencl without much hassle.

1) I checked out the sdsm paper, and irregular shadow maps are a little different from that. In case of irregular shadow maps, the shadow map rasterization is not done using the gpu's hardware at all. The irregular Z-buffer allows arbitrary placement of shadow map samples in the image plane, and rasterizing these arbitrary samples requires a custom rasterizer to be built in opencl. This makes it less trivial to implement.

2) I know about RTSS, and it is a little different in scope from what i am trying to implement, although the spirit is the same. Let me elaborate:

The system I am proposing will completely free shader writers from the underlying intricacies of the rendering algorithm. Shaders would be of the following types:

a)Surface shaders: WIll take point, Normal, a set of texture co-ords, and a set of textures as input. Give colour as output.

b)Light shaders: Will describe the illumination available from lights. Input will be light position, and the position/normal of the destination point. Output would be light intensity. No shadow mapping code, etc would need to be explicitly written. The underlying system will take care of it. choosing between different shadow algorithms would be a matter of setting a flag.

c)Displacement shaders: Will take care of displacements.

d) Post Processing shaders: will post-process images.

These shaders would be translated in runtime depending on the algorithm the user chooses. The shader writer would be insulated from underlying data types for color/texture, etc. Choosing between integer/floating point pipelines, deferred shading, etc would be a matter of setting a flag in the shader generator. The RTSS does this to a certain extent. However, this system would add a level of flexibility and programmability to it.

People familiar with non real time shading languages like MetaSL, or renderman shading Language would be familiar with this kind of shader programming, and the advantages it presents.

3) I have seen that presentation, and I am glad to hear that you like it. Thank you for sending the link to the voxel engine. it seems to be well integrated with the current terrain system, though I do not know the extent of its integration with the paging system and the like. In any case it will be an excellent starting point for a voxel integrated vector field system.

>>...."huge work already that would be sufficent on its own for a gsoc..."

Absolutely.... I sent 3 proposals because I had a lots of ideas. Finally, I would be working on any one of these.

Thank you.
Debdatta Basu.
User avatar
tuan kuranes
OGRE Retired Moderator
OGRE Retired Moderator
Posts: 2653
Joined: Wed Sep 24, 2003 8:07 am
Location: Haute Garonne, France
x 4
Contact:

Re: [GSoC 2011]Irregular z Buffer shadows and other ideas.

Post by tuan kuranes »

1 & 2) What I meant is ogrer dx11 rendersystem is still a WIP. Having DX11 fit to welcome project based on DX11 gsoc may be a gsoc subject on its own. Better check.

1) what I meant is irregulat z buffer is nice and hot topic in research, but still research, without clear perfomance advantages on current well known techniques, whereas techniques & demo listed above are more to the point for ogre users. (explorer shadow app, and all techniques where shadow technique is proven to be < 4ms)

2) Idea is more to use RTSS as a starting point, with a step by step planning, which would garantee usables devliverables even if gsoc work not finished. (unfinished system whatever elegant is of no use if not finished). Otherwise proposal is too huge and very likely to be unfinished at the end of gsoc...

1 & 2 & 3) Keep in mind that a narrow but well planned and "step by step" defined is really better than a huge "block" project likely to be unfinished...
debdatta_basu
Kobold
Posts: 31
Joined: Thu Jun 10, 2010 4:32 am

Re: [GSoC 2011]Irregular z Buffer shadows and other ideas.

Post by debdatta_basu »

Sorry for the delay in responding.... I was out on a biking trip, and there was no internet connection. :)

1) The paper I gave a link to earlier gives good performance characteristics for their test scenes, but yes, the technique has seen very little or no real world use. Will be great for a demo, but not for an actual contribution. so Let us leave it out...

In my opinion, (2) and (3) will be a really good projects. for (2), I do not plan to do an all out "block" project as you said, but lay the framework for more intuitive shader programming in OGRE.

a) A unified shading language spec based on Renderman shading language.
b) Intermediate data structures for describing various types of shaders, and parsers for converting into the same.
c) A new translator class would need to be made to translate the intermediate description to OGRE materials. This class will need to be extensible, in order to accommodate newer rendering algorithms as time progresses. My work will be limited to implementing a deferred shading version of the class. The majority of the work lies here.

Even if (c) goes unfinished, (a) and (b) will provide an excellent starting point for future endeavors...

I would like your thoughts on this idea, and would love to discuss further. If there is any specific reason you think the project will go unfinished, please let me know. Also, Please help me finalize the topic from among (2) and (3), so that I can start planning on implementation.

Debdatta Basu.
User avatar
tuan kuranes
OGRE Retired Moderator
OGRE Retired Moderator
Posts: 2653
Joined: Wed Sep 24, 2003 8:07 am
Location: Haute Garonne, France
x 4
Contact:

Re: [GSoC 2011]Irregular z Buffer shadows and other ideas.

Post by tuan kuranes »

2) still seems big for a summer of code (only writing the documentation of a) could take half the summer, not speaking of serialization, parsing bugs and tuning.) Previous script new parser code overhaul took a year, and had less impact that this one.

3) seems more fitted to the scope (time and subject)

Better a small, very polished project that will be finished for sure than a great but unlikely to succeed ...
In any case a small project can always be extended if needed (speed, io, doc, etc.)
debdatta_basu
Kobold
Posts: 31
Joined: Thu Jun 10, 2010 4:32 am

Re: [GSoC 2011]Topic Finalized: Vecor field terrain.

Post by debdatta_basu »

I spent the past week familiarizing myself with the new terrain system. I have found it very easy to work with as it is pretty modular. Hats off to Sinbad for his excellent work. Right now I have a pretty clear mental picture of this project. There are some things I still need to figure out. I have exams till Tuesday, after which I will sit down and make a concrete proposal. This gives me a mere 3 days, but I think(Hope)I can manage it. :D Wish me luck.

Also, Is there anything I should watch out for, or keep in mind? Any suggestions will be appreciated.

Thank You,
Debdatta Basu.
User avatar
Noman
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 714
Joined: Mon Jan 31, 2005 7:21 pm
Location: Israel
x 2
Contact:

Re: [GSoC 2011]{EDIT}Topic Finalized: Vecor field terrain.

Post by Noman »

There is a good chance that if you only have enough time to write the proposal (and not revise it based on our comments) there will be some problems with it and it will lower your chances. Try to post it here as soon as you can so we can give you comments before you upload a final version.
debdatta_basu
Kobold
Posts: 31
Joined: Thu Jun 10, 2010 4:32 am

Re: [GSoC 2011]{EDIT}Topic Finalized: Vecor field terrain.

Post by debdatta_basu »

Thanks Noman! I have a light exam on Tuesday, so I will start working on it from Monday itself!. Lets hope for the best!

-Debdatta Basu.
debdatta_basu
Kobold
Posts: 31
Joined: Thu Jun 10, 2010 4:32 am

Re: [GSoC 2011]Proposal draft is up: Vecor field terrain.

Post by debdatta_basu »

I have edited My initial post to include my proposal draft. I would love your comments and suggestions to help me perfect it.

Thank You,
Debdatta Basu.
User avatar
Noman
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 714
Joined: Mon Jan 31, 2005 7:21 pm
Location: Israel
x 2
Contact:

Re: [GSoC 2011]{EDIT}Proposal draft is up: Vecor field terra

Post by Noman »

Hey,

First of all, you should upload your proposal to google-melange.com , as time is running short. You will be able to update it if you find the time before the deadline, which is tomorrow.

Besides that :

1 - The presentation is a 1 hour video. Are the slides available somewhere?
2 - What are the main advantages of vector field terrain rather than heightmap based terrains?
3 - Assuming you get the engine working, how will the terrains be created? Are there external tools that generate this format? Do you need to create loaders from them?
debdatta_basu
Kobold
Posts: 31
Joined: Thu Jun 10, 2010 4:32 am

Re: [GSoC 2011]{EDIT}Proposal draft is up: Vecor field terra

Post by debdatta_basu »

@Noman.
Thanks for your suggestions and inputs. They were very helpful. I had somehow skimmed over the content creation part in the proposal, even though I had the idea in mind. I have now edited my proposal keeping your suggestions in mind.

The slides were available before on the Bonfire studios website. However, they were bought and closed down, and I can no longer find the slides online.....

I will definitely submit the proposal as soon as possible. I realize that my work has been last-minute, but I was busy with exams, and could find time only today..

Again, I am eagerly waiting for any criticism and feedback.

EDIT: Proposal updated on Google Melange.

Thank You,
Debdatta Basu.
debdatta_basu
Kobold
Posts: 31
Joined: Thu Jun 10, 2010 4:32 am

Re: [GSoC 2011]{EDIT}Proposal draft is up: Vecor field terra

Post by debdatta_basu »

Since my proposal has not been accepted for gsoc this year, It would be helpful for me to understand the negatives that kept it from happening.
Awaiting your responses.

Debdatta Basu.
User avatar
jacmoe
OGRE Retired Moderator
OGRE Retired Moderator
Posts: 20570
Joined: Thu Jan 22, 2004 10:13 am
Location: Denmark
x 179
Contact:

Re: [GSoC 2011]{EDIT}Proposal draft is up: Vecor field terra

Post by jacmoe »

I don't think you could have done any better. Excellent proposal. :)
Sadly, however, we didn't have the mentoring man-power to back it up. :(
GSoC is sometimes (maybe always) a devils choice.
/* Less noise. More signal. */
Ogitor Scenebuilder - powered by Ogre, presented by Qt, fueled by Passion.
OgreAddons - the Ogre code suppository.
Post Reply