Ogre Forums

Short description
This is almost the continuation of kuxv's work in the GSoC 11, which is quite awesome but left incomplete. I'll work on it, try to make it merged into trunk and perhaps be ready for 1.9 release. I'm also going to implement a minimal Random Terrain Generator plugin, then demo the TS with an endless world to show that it can be used in reality now, more or less.

Project Proposal
After reading through the thread and wiki of the last year's terrain paging project, I think it is in a status of:

• -Unstable, especially when cross-platform, e.g. http://www.ogre3d.org/forums/viewtopic. ... 75#p437557
  -Tough bugs, e.g. http://www.ogre3d.org/forums/viewtopic. ... 75#p446856
  -Lack of documents, very lack, if I havn't missed something

Then I also summarized the needs of you guys who have shown great interest in the project, for example:

• -Stable, of course
  -Then it can be merged into trunk, and released since 1.9 ( What a pity to have 1.8 missed! )
  -Documents, the more the better

Here comes my planned work during the GSoC12:

• -Code review, bugfix, and even refactoring, to make it really usable
  -Documenting a lot, including implementation design, user manual and further development guide
  -Testing, then merging into trunk if it has been ready
  -A demo with a vast world, to show the TS can be in use in reality

To demo the TS, an interesting plugin will be introduced: the Random Terrain Generator, whose whole idea is proposed at the "Anything Else" section. Here we are just going to finish the simplest 2D Perlin Noise algorithm to let the generator work. The remain will be done outside the scope of GSoC.

In the demo, terrain blocks are continually generated when the player comes near the edge. So the world is actually endless that you can wander around forever within the TS's ability.
Features are:

• -Using paging, LOD, background loading
  -World is large-scale
  -Terrain changes from time to time
  -...

When demo the Terrain System, we'll meet some bottlenecks no matter on rendering effect or efficiency. For example, realtime terrain-generation needs realtime processing on the lighting and composite maps, while not pre-processing as before. As a result there may be performance bottlenecks. It's tough, but also valuable in making improvements. I haven't more concrete ideas, yet. So you can also take the demo as a test case and we are going to make the TS failed intentionally.

Schedule
==ACCEPTED PROPOSALS ANNOUNCED==

• 4.23~5.21 Read through the previous project's code. Setup developing environment. Disscuss with community and mentor to make the project totally clear

==BEGIN CODING==

• 5.21~6.11 (3 weeks) Code review and bugfix, close most of the cases reported in the forum. If refactoring is needed, the whole schedule below may be adjusted and I'll re-publish it as soon as possible
  6.11~6.25 (2 weeks) Write some documents ( The final exams locate here, slowing down the procedure )
  6.25~7.9 (2 weeks) Test, and start the process of merging into chunk

==MIDTERM EVALUATION==

• 7.9-7.13 (1 week) Deal with the midterm evaluation
  7.13-7.20 (1 week) Finish the minimal Terrain Generator
  7.20-8.13 (3 weeks) Make the demo

==SUGGESTED PENCILAS DOWN==

• 8.13-8.20 (1 week) Bugfix and improve documents

==FIRM PENCILAS DOWN==

• 8.20-8.24 Deal with the final evaluation

==PROJECT ENDED==

I have no commitments during the summer, except the final exams in June.
After finishing the project, I will continue contributing to the Terrain System. Actually, I'm very interested in terrain generation and procedure.

Why You're The Person For This Project
As mentioned above, I've worked on terrain generation, rendering and management. I've made my mind to be a game developer.
Though I'm new for Ogre development, I have followed it for some time. To prepare for this application, I've read some articles, tried the Terrain System, and read through the GSoC2011's related project.
I've ever contributed to open source projects, too. I developed several protocol dissectors for Wireshark, among which BT-uTP, BT-DHT and Vuze-DHT have been released since 1.6.0 and 1.7.0. And in the GSoC 2011 I also finished an i18n module for Blender, which has been released since 2.60. The documents are here.
In conclusion, I'm newbie, but with interest, necessary skills and of course passion. I'm eager to be involved in this.

Why OGRE?
Now when I want to make a personal 3D app, I'll always consider Ogre first. But I still havn't learned it well. As a coder, I think the best way to learn something is to become its contributor.

Anything Else [Terrain Generator and Procedure for Ogre and Ogitor]
As first proposed, my whole idea about the terrain generation will now be explained here, separated from the main GSoC proposal above. This can be also a standalone GSoC project I think, if the organization would accept:)

Let's see what is a Terrain Generator first. The following pictures show the snapshot of my previous work on terrain generation, in which the terrain is generated automatically by some algorithms. A lot of work was done to adjust the result to look natural.



Some well known terrain generation algorithms are:

• -Perlin Noise <GPU Gems 1, chap 5>
  -Fault Formation <Game Programming Gems 1, chap 4.17>
  -Diamond Square (Midpoint Displacement) <Game Programming Gems 1, chap 4.18>
  -Particle Deposition <Game Programming Gems 1, chap 4.19>
  -Terrain with Hollows <GPU Gems 3, chap 1>

Different algorithms have different arguments, and result in different styles of terrain. By defining the sea level, the terrain can also have lakes and sea.

For Ogre, the generator exists as a plugin, just like the water plugin and clouds plugin. In games we can create endless world automatically, or change the surroundings from time to time.
Based on the generator we can also create an Auto-Skybox plugin, which generates beautiful distant mountains and combines it with Xavyiy's SkyX to make a pre-rendered Skybox ( randomly, of course ). It may cheat the most discerning eyes successfully. Did you ever feel unsatisfied when you distinguished the real 3D scene and the flat skybox just by one glance?
Another idea is that, given a picture of the desired landscape, we can analyze it (using shapes to choose algorithm and parameters, using colors for texture). Finally, a similar world is produced.
By doing these work, some enhancement should be done on the Terrain System. For example, the terrain with hollows may need volume rendering, which is another proposal of this year's GSoC.
Further more, terrain rendering and decoration is another big topic, such as:

• -Naturally located vegetation
  -Grass rendering using instance
  -Soil type based terrain texturing(snow on the top, rock in the middle, and grassland in the gorge)
  -Bump mapping
  -24 hour lighting
  -Weather effects
  -...

With all these techniques the generated world becomes more and more lifelike.

For Ogitor, the generator exists as a brush. Actually it has been in it, located at TerrainTools->Deform. But the result is quite unnatural in contrast with Far Cry 2's Map Editor:


They are both finished by a single paint.

The generation technique has also been explained in decarpentier's article, which is frequently recommended to me.
Decarpentier's another great article describes terrain procedural. Common algorithms in this field include:

• -Ridged turbulence
  -Erosion, such as weathering and fluid corrosion
  -Distortion by noise
  -Smoothening

All of these are some kind of brushes, and Ogitor has implemented the last one. We can try to finish the others.

===============================================Thanks for Assaf's feedback!
1. Can you add to your thread - a UML, write the names of classes in OGRE you want to modify and why. names of major new classes you may add, their responsibilities and main methods


As shown in the class diagram, the [mod] and [add] tags are from kuxv's work. You can get the intention at [1] and [2]. The [new] tags are new parts from me, containing a TerrainGenerator plugin and a sample with endless terrain.
The TerrainGenerator uses different strategies to generate terrain, while during the gsoc only PerlinNoise will be implemented.
The Sample_TerrainEndless uses TerrainGenerator to generate and then render terrains. It's inherited from SdkSample, of course.

What risks does this project hold?
I have taken a quick look through the code, and think that the design may be the origin of instability. If this is exactly the conclusion when I finishs the code review, refactoring will be needed, which will surely disturb the schedule that have been made. Fortunately, the code size isn't very big. I'll try to catch up during the second half.

Can you list the "most of the cases reported in the forum" you wrote about in your proposal?

• - Win7+VS2010 building error [3]. It's said to have been repaired. I'll confirm it.
  - Wrong LOD calculation, and the sample crashes accidently [4]
  - Flexibility, such as dealing with many small terrain blocks [5]

I'll invite users to try it to collecte more reports. It is a necessary step before merging into mainline

2. Can you get OGRE from the trunk, compile it, run it and comment here that you did - just to make sure you are have a computer that can run OGRE for the summer project.
Yes, I've done that ever before, and tried again today, all with happy ending.

[1] http://www.ogre3d.org/tikiwiki/SoC2011+ ... _delivered
[2] http://www.ogre3d.org/forums/viewtopic. ... 25#p432577
[3] http://www.ogre3d.org/forums/viewtopic. ... 75#p437557
[4] http://www.ogre3d.org/forums/viewtopic. ... 75#p446856
[5] http://www.ogre3d.org/forums/viewtopic. ... 75#p450679

Just for the sake of completeness: I proposed to the application to also have a look at those links for inspiration:
http://www.ogre3d.org/forums/viewtopic.php?f=11&t=68026
http://www.decarpentier.nl/scape-render
http://www.decarpentier.nl/scape-procedural-basics
http://www.decarpentier.nl/scape-procedural-extensions

The info that can be found there, might however be already covered by the referenced GPU Gems articles...

This proposal is looks very promising.
That is definitely something which Ogre needs - terrain system needs further improvements.

Interesting proposal.
Your previous experience with this sort of stuff is also a big plus.

Some thoughts and suggestions of mine:
- It would be interesting if the procedural libraries also support brush capabilities, so they can be integrated in an editor like ogitor where you can manually tweak the terrain instead of only generating a full terain automatically.
- Perlin noise techniques might be a bit outdated and I think you can do better at generating more convincing terrain. Definitely have a look at the decarpentier.nl work. It would be awesome if those techniques could be integrated with Ogre::Terrain in an easy usable component. Most of the techniques you're referencing are from the first GPU Gems book, which dates from 2004 and Game Programming Gems 1 is from 2000. So, maybe have a look around for more recent techniques (for example the GPU Gems 2 or 3 books and the decarpentier articles).
- Vegetation and terrain texturing is another interesting thing to consider: allow automatic placement of plants based on height and steepness properties of the terrain. Also allow the texture to change on different heights (typical examples are: snow above a certain height, different ground texture below sea level).

Vegetation could be optional because I'd let it interact with the Paged Geometry addon, which is optional.

duststorm wrote:Interesting proposal.
Your previous experience with this sort of stuff is also a big plus.

Some thoughts and suggestions of mine:
- It would be interesting if the procedural libraries also support brush capabilities, so they can be integrated in an editor like ogitor where you can manually tweak the terrain instead of only generating a full terain automatically.
- Perlin noise techniques might be a bit outdated and I think you can do better at generating more convincing terrain. Definitely have a look at the decarpentier.nl work. It would be awesome if those techniques could be integrated with Ogre::Terrain in an easy usable component. Most of the techniques you're referencing are from the first GPU Gems book, which dates from 2004 and Game Programming Gems 1 is from 2000. So, maybe have a look around for more recent techniques (for example the GPU Gems 2 or 3 books and the decarpentier articles).
- Vegetation and terrain texturing is another interesting thing to consider: allow automatic placement of plants based on height and steepness properties of the terrain. Also allow the texture to change on different heights (typical examples are: snow above a certain height, different ground texture below sea level).

Vegetation could be optional because I'd let it interact with the Paged Geometry addon, which is optional.

Thank you for your suggestions!
- I do want the generator to be portable, just like a library. Then it's easy to be integrated into ogitor, and tools such as brushes can be used to do some modification. Just as the Far Cry 2's editor.
- In my previous project vegetation and terrain texturing are taken in consider as well. As shown in the second picture, grasses are located according to the altitude and slope.
- Further more, we also did erosion simulation to give the terrain ridges and ravines. The idea is like the one in [1].

I ever thought adding these features into the proposal, but I'm afraid of making the subject too big and decentralized. We can list them as optional. I'll implement them, during or after the gsoc.

[1] Jacob Olsen, Realtime Procedural Terrain Generation

This looks *very* related: http://www.ogre3d.org/forums/viewtopic.php?f=11&t=68026

aguru wrote:This looks *very* related: http://www.ogre3d.org/forums/viewtopic.php?f=11&t=68026

Yeah, I've started reading it.
Maybe do some adjustments on my proposal later.

aguru wrote:This looks *very* related: http://www.ogre3d.org/forums/viewtopic.php?f=11&t=68026

I already linked that in my first post . Since it got mentioned twice already, it *really* must be relevant .

We have briefly toyed with the idea of a GSoC for Ogitor, but this would be really close to being that!

All these hints

The new proposal sounds awesome for me, I really want to see this GSoC project accepted and completed!

I really like the idea of seeing finished&enhanced the last year GSoC terrain project and also add a robust demo which shows the Ogre terrain/paging system capabilities, IMO it'll be very important for Ogre, since it's a core business and a robust well-documented terrain system... makes a huge difference.

Xavier

I must say I'm also quite excited about the proposal now. Even though it might look a lot less adventurous than the initial version.
I think you're really reaching a target that a lot of people want to see done.

The brushes and such are a really interesting concept that will hopefully once end up in an editor like ogitor, but for them to be useful we need a good terrain to start with.

Thanks for all the support. I am full of confidence now

In the following 3 or 4 days I'll keep on doing some adjustments according to the feedback. And finally update the copy on the GSoC official site.
So, please let me know if you have any suggestions. Thank you in advance!

Just wait into the deep night to see the result (here is 3.00 a.m.), and it's really worth it. Thank the community for accepting me, and also congratulates to PhilipLB, robert_sasu and Karol Badowski!

Ah, time to sleep, now

Sleep good, you earned your sleep.
Happy to have you.
Great expectations from this project.

Assaf Raman wrote:Sleep good, you earned your sleep.
Happy to have you.
Great expectations from this project.

Actually, I'm wondering who is my mentor I didn't find a relationship map on both ogre's and google's site. Is it you, Mr. Assaf?
Anyway, I think I should create a repository on bitbucket first.

Hi Xiao, your mentor is David Rogers (masterfalcon). I assume that he will contact you soon (either via PM or here in the thread) to discuss the organizational stuff and the next steps. Until then, this list of Mattan can serve as a first guide: http://www.ogre3d.org/forums/viewtopic. ... 60#p456560

So, yes: Creating a fork on Bitbucket is definitely a good step .

Hi Xiao,

Nice to meet you. Mattan's list is a very good place to start with. Yes, start with a fork of the default branch(and post the link here of course). The next step that I would take is merging kuxv's work in and make sure that it compiles and functions at least as well as it had previously.

Then we can start on the bugs reported in the forum. Again, as Mattan pointed out, communication is very important so don't be afraid to post any issues and status updates here.

xiaoxiangquan wrote: Then I also summarized the needs [...] for example:

• -Stable, of course

It looks a little bit strange for me.
The simple but stable Terrain Scene Manager was removed from Ogre
and replaced by an instable, still unfinished, non-optimised terrain component.

Is it true?
If so, I wonder why the terrain alternative TSM was removed.
Or is it false?
What's the current state?

TSM was stable, but it was severely limited and not flexible enough.

What is being referred to as 'unstable' is not the terrain component - which is stable - but the work of last GSoC performed by Kuvx. Which didn't reach a stable stage, hence the reason why it didn't make it into Ogre main branch.

masterfalcon wrote:Hi Xiao,

Nice to meet you. Mattan's list is a very good place to start with. Yes, start with a fork of the default branch(and post the link here of course). The next step that I would take is merging kuxv's work in and make sure that it compiles and functions at least as well as it had previously.

Nice to meet you, too!
I'm going to merge kuxv's work into my branch firstly. If no big problems, merge trunk HEAD into it. Then I can start my process.
This will be done in one or two weeks. I'll report the status here every Sunday.

Have you created a fork on bitbucket yet? If so, what's the URL for it?

masterfalcon wrote:Have you created a fork on bitbucket yet? If so, what's the URL for it?

Yes, just imported from kuxv's: https://bitbucket.org/xiaoxq/ogre_soc_tpi

Thanks, I've got it all cloned now. Assaf brought up a good point in another thread, could you also check out the patch list to see if any are relevant? http://sourceforge.net/tracker/?limit=2 ... mit=Filter

And here the other relevant link: http://www.ogre3d.org/mantis/view_all_bug_page.php