General thoughts on terrain

Threads related to Google Summer of Code
Post Reply
User avatar
aguru
Goblin
Posts: 236
Joined: Tue Feb 26, 2008 5:48 pm

General thoughts on terrain

Post by aguru » Thu Mar 29, 2012 8:00 am

Seeing a lot of these years gsoc propsials seem to be related to terrain enhancements, something has been on my mind.

In last years gsoc, kuvx has implemented terrain paging improvements that have not made it into trunk yet. I feel there is a certain danger of feature fragmentation here. Shouldn't all further terrain improments be made compatible with the paging compontent?

Maybe I'm hoping for too much here, but this would be an ideal case (provided the projects get accepted at all): I use xiaoxiangquan's gsoc project to procedurally generate an interesting grid of 20x20 pages. Then I use PhilipLBs project to further refine my terrain. Finally, kvux paging/lod component displays what I've created using PhilipLBs LODs to performantly render the whole thing.

Maybe I'm misunderstanding some concepts or you guys have already considers those things, just making sure we get a chance to think about the bigger picture now.

Btw, I have a strong feeling that Giliams Scape implementation could be very interesting here, too: http://www.ogre3d.org/forums/viewtopic.php?f=11&t=68026
Last edited by aguru on Thu Mar 29, 2012 12:26 pm, edited 1 time in total.
0 x

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

Re: General thoughts on terrain

Post by jacmoe » Thu Mar 29, 2012 12:23 pm

Why wasn't it integrated, the paging improvements of last years GSoC?
0 x
/* Less noise. More signal. */
Ogitor Scenebuilder - powered by Ogre, presented by Qt, fueled by Passion.
OgreAddons - the Ogre code suppository.

CABAListic
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 2903
Joined: Thu Jan 18, 2007 2:48 pm
Contact:

Re: General thoughts on terrain

Post by CABAListic » Thu Mar 29, 2012 12:33 pm

Because far as I understand, it wasn't stable or at least not thoroughly tested, so it couldn't be pulled into the default branch at the time as it would have polluted the 1.8 release. Since 1.8 now has a separate branch, it should probably be pulled in, but that should be done by someone who knows the state of the project.
0 x

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

Re: General thoughts on terrain

Post by jacmoe » Thu Mar 29, 2012 1:38 pm

A pity. :)
Makes sense, though.
0 x
/* Less noise. More signal. */
Ogitor Scenebuilder - powered by Ogre, presented by Qt, fueled by Passion.
OgreAddons - the Ogre code suppository.

Shaun
Halfling
Posts: 79
Joined: Wed May 05, 2010 1:43 am

Re: General thoughts on terrain

Post by Shaun » Sat Mar 31, 2012 12:02 pm

Well as far as I see things, (not very far xD) I am also of the same opinion and what you said "does" make sense to me. In fact I kind of took it for granted that those projects would be selected for good. Apart from the fact that they will fit so well together when completed... I don't think that we'd be very far away from volumetric differential implementation of terrain... which in nice words could be said to be... "entire super massive worlds that are completely destructible" or in yet other words it could be called "awesome".

I wanted to implement completely destructible environments for a looooooooong time. :P

So you can say I'm "thrilled" to say the least =D
0 x

User avatar
duststorm
Minaton
Posts: 921
Joined: Sat Jul 31, 2010 6:29 pm
Location: Belgium
Contact:

Re: General thoughts on terrain

Post by duststorm » Sat Mar 31, 2012 1:02 pm

I think the projects are not compatible with each other.
That is to say: there are two totally different techniques for representing terrain
- kuvx's last year's GSoC component and xiaoxiangquan's
- PhilipLBs voxel terrain

I'm not an expert on the implementations of both, but I believe the way in which both are represented totally differs.
This means you need a different approach to caching them in memory (at least optimized), generating LOD levels, editing the terrain etc.

The big advantage of voxel terrain is that you can create holes in it and have overhangs. Voxel terrain however involves more complex algorithms, and is (I think) even with serious optimizations slower than regular geometry terrain.
If you are planning a project and need massive terrain, but don't really require overhangs and holes (or you believe you can do these overhangs using separate geometry) the geometry terrain would probably be the best choice (both in terms of memory as processor usage)

Kuvx and xiaoxiangquan are focused on the same type of terrain. That's why it's a good idea to make sure xiaoxiangquan starts where kuvx left off, so that we don't lose effort spent.
I fear that voxel terrain is something totally different and not much can be shared between the two. (of course, if it is possible as much as possible should be shared, maybe brushes or something, but I fear for it)

I also believe that it's not possible or at least not sensible to create a hybrid between the two systems. So they really are two separate systems fit for different types of projects.

As always, I might be wrong ;)
0 x
Developer @ MakeHuman.org

Alexiss
Halfling
Posts: 74
Joined: Wed Aug 10, 2011 2:11 pm

Re: General thoughts on terrain

Post by Alexiss » Sat Mar 31, 2012 1:27 pm

I agree with duststorm, there's probably nothing to share between voxels implementation and regular terrain.
At least not without making huge changes to Ogre::Terrain.

Although, it could be very interesting to create an hybrid terrain system, which would use both representation.
Ideally, it would allow to create terrains of any shape in a transparent manner. Internally use heightmaps as
much as possible, and voxels where needed.

However, regarding voxels, although they are a lot more resource hungry than regular terrain (especially in memory usage),
if you do not use destructible terrains, you can use voxels to model your terrain and export it to a regular mesh.
It can be very productive for level designing, as modeling terrain with voxels is very fast and convenient.
0 x

User avatar
duststorm
Minaton
Posts: 921
Joined: Sat Jul 31, 2010 6:29 pm
Location: Belgium
Contact:

Re: General thoughts on terrain

Post by duststorm » Sun Apr 01, 2012 2:13 pm

Alexiss wrote:However, regarding voxels, although they are a lot more resource hungry than regular terrain (especially in memory usage),
if you do not use destructible terrains, you can use voxels to model your terrain and export it to a regular mesh.
It can be very productive for level designing, as modeling terrain with voxels is very fast and convenient.
Very interesting idea.

For editing terrain, voxels are probably a lot more useful than modeling on terrain meshes directly. If the voxel cloud is meshed afterwards, maybe the algorithm can use geometry more intelligently.
The way it is done now using regular terrain geometry is that the terrain is subdivided in equally sized tris. This often forces you to make a tradeoff between wasting too many triangles and not being able to have enough detail in the terrain.
If having equally sized tris is not really a requirement of terrain this could be useful, so more geometry could be used where it is needed, and polycount could be minimized on large flat planes (limited by a maximum polygon size parameter).

Maybe a hybrid between the two would make sense in a way: one could edit one tile (or a few), those tiles being stored as voxels in memory. Once they are finished, they could be finalized and stored as meshes, reducing memory space needed.
That way you can voxel edit a massive terrain, since distant terrain pages are efficient geometry.

An algorithm could allow converting a page from mesh to voxels and back.
This would require a common interface between the existing Ogre::Terrain and the voxel terrain, where things as terrain pages can be handled uniformly (even though underlying caching strategies will probably differ).

I believe, however, that transitioning between voxels and geometry will not be possible at runtime in a live application because the algorithmic complexity of such an operation will probably cause some waiting times. So it would be good for an editor, but I fear it would not work as a tradeoff between destructible terrains and massive world sizes in a realtime 3D application.
0 x
Developer @ MakeHuman.org

PhilipLB
Google Summer of Code Student
Google Summer of Code Student
Posts: 550
Joined: Thu Jun 04, 2009 5:07 pm
Location: Berlin

Re: General thoughts on terrain

Post by PhilipLB » Sun Apr 01, 2012 3:21 pm

Voxels and Heightmaps are indeed completly different approaches.

For sparse triangulation of heightmaps: Checkout ROAM ( https://graphics.llnl.gov/ROAM/roam.pdf )
0 x
Google Summer of Code 2012 Student
Topic: "Volume Rendering with LOD aimed at terrain"
Project links: Project thread, WIKI page, Code fork for the project
Mentor: Mattan Furst


Volume GFX, accepting donations.

Post Reply