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.
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
- -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
- -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
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.
- -Using paging, LOD, background loading
-World is large-scale
-Terrain changes from time to time
==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
- 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
- 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
- 8.13-8.20 (1 week) Bugfix and improve documents
- 8.20-8.24 Deal with the final evaluation
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.
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>
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)
-24 hour lighting
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
===============================================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  and . 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 . It's said to have been repaired. I'll confirm it.
- Wrong LOD calculation, and the sample crashes accidently 
- Flexibility, such as dealing with many small terrain blocks 
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.
 http://www.ogre3d.org/tikiwiki/SoC2011+ ... _delivered
 http://www.ogre3d.org/forums/viewtopic. ... 25#p432577
 http://www.ogre3d.org/forums/viewtopic. ... 75#p437557
 http://www.ogre3d.org/forums/viewtopic. ... 75#p446856
 http://www.ogre3d.org/forums/viewtopic. ... 75#p450679