New Terrain Early Shots

A place to show off your latest screenshots and for people to comment on them. Only start a new thread here if you have some nice images to show off!
Post Reply
User avatar
stealth977
Gnoll
Posts: 638
Joined: Mon Dec 15, 2008 6:14 pm
Location: Istanbul, Turkey
x 42

Re: New Terrain Early Shots

Post by stealth977 »

Ok, now its time to bug you with questions (asking here since everyone may want to know about):

1 - The demo loads a single 513x513 terrain, thats fine, but how do we load for example a 8192x8192 terrain? Does OgreTerrain support heightmap chunks like 16x16 chunks, each chunk being 513x513, or do we need to pass all of the 8192x8192 data?

2 - In the case of big terrains (well actually i think thats why people are waiting for this component), how will the layers treated? One layer list for the whole terrain? or layer lists per chunk? Lets say i have a 8192x8192 terrain, will i be limited to only 6 normal mapped textures for the whole terrain, or 6 unique normal mapped textures per chunk of it?

3 - Will they be handled by the current terrain implementation, or do we need to supply our own page sources to handle the situations above?

ismail,
Ismail TARIM
Ogitor - Ogre Scene Editor
WWW:http://www.ogitor.org
Repository: https://bitbucket.org/ogitor
User avatar
sinbad
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 19269
Joined: Sun Oct 06, 2002 11:19 pm
Location: Guernsey, Channel Islands
x 66
Contact:

Re: New Terrain Early Shots

Post by sinbad »

1. Theoretically you can add as large an area as you like to one terrain instance and it will be decimated according to 16-bit index sizes and the batch sizes you configure. However in practice you're likely to want to split up your terrain into multiple pages of terrain, each of which is a Terrain instance. The code for doing this with the Paging component is already there to a degree but this is hugely untested so far, so don't blame me if it doesn't work yet. This is all early access stuff :) You can also use multiple Terrain instances outside the paging system if you want.

2. A layer list for each Terrain instance. So each chunk or page of terrain can have a different number of layers with different textures applied, but within one Terrain instance you have a single layer list. This is because of the batching - the terrain chunk has to be capable of being rendered as a single batch at the lowest level of detail.

3. The new terrain has its own storage format for quick loading (testing still todo on this), and this is what the paging system will use, but you can populate it yourself too since it's inherently editable. No 'page source' is required as with TSM because you can edit it directly.
spong3bob
Gnoblar
Posts: 5
Joined: Tue Jun 16, 2009 7:42 pm

Re: New Terrain Early Shots

Post by spong3bob »

where/how can i get the demo??
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: New Terrain Early Shots

Post by jacmoe »

Get SVN trunk and compile. :wink:
/* Less noise. More signal. */
Ogitor Scenebuilder - powered by Ogre, presented by Qt, fueled by Passion.
OgreAddons - the Ogre code suppository.
User avatar
sinbad
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 19269
Joined: Sun Oct 06, 2002 11:19 pm
Location: Guernsey, Channel Islands
x 66
Contact:

Re: New Terrain Early Shots

Post by sinbad »

GL is working now, although I had to require fp40 under Cg which I know excludes ATI cards. I intend to write a GLSL shader generator too to cover this, but I'm going to wait until the Cg/HLSL generator is feature-complete.

And just for fun, here's a shot with another splat layer. Each layer doesn't seem to drag the framerate that much lower on my machine, which is a good sign - because I'm accessing textures I can't genuinely use shader branching to avoid the entire overhead when blend values are 0 but it doesn't seem to be too bad.
newterrain_5.jpg
newterrain_5.jpg (112.95 KiB) Viewed 6467 times
CABAListic
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 2903
Joined: Thu Jan 18, 2007 2:48 pm
x 58
Contact:

Re: New Terrain Early Shots

Post by CABAListic »

sinbad wrote:GL is working now, although I had to require fp40 under Cg which I know excludes ATI cards.
Or you could try my CgProgram patch for glslv/glslf support ;) With the recent fixes you did to sparkprime's glsl problems, chances are the generated programs might not crash anymore. It would be interesting if they are in any form usable, because so far I haven't had much luck with Cg's glsl output :(
User avatar
sinbad
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 19269
Joined: Sun Oct 06, 2002 11:19 pm
Location: Guernsey, Channel Islands
x 66
Contact:

Re: New Terrain Early Shots

Post by sinbad »

I'd like to, but actually I have to write GLSL code directly anyway, because I need to provide a solution for people that don't run the Cg plugin (that was the primary reason for having a GLSL shader generator). I'm lucky that I can use the same shader code for HLSL though for Dx9-without-Cg.
spong3bob
Gnoblar
Posts: 5
Joined: Tue Jun 16, 2009 7:42 pm

Re: New Terrain Early Shots

Post by spong3bob »

this screen looks totally awesome :P
i just dont like the grass texture
User avatar
sinbad
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 19269
Joined: Sun Oct 06, 2002 11:19 pm
Location: Guernsey, Channel Islands
x 66
Contact:

Re: New Terrain Early Shots

Post by sinbad »

I've updated the first post since those first shots were already looking a bit rubbish ;)

Parallax mapping is in now, global colour mapping (to break up patterns) is coming soon.
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: New Terrain Early Shots

Post by jacmoe »

Looking good! The feeling I get from watching those screen shots is pretty close to how I feel when trekking the Norwegian mountains. :)
I need to see it in motion.
/* Less noise. More signal. */
Ogitor Scenebuilder - powered by Ogre, presented by Qt, fueled by Passion.
OgreAddons - the Ogre code suppository.
User avatar
Praetor
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 3335
Joined: Tue Jun 21, 2005 8:26 pm
Location: Rochester, New York, US
x 3
Contact:

Re: New Terrain Early Shots

Post by Praetor »

Have you noticed a decent quality improvement with parallax mapping? I would have assumed that on terrain, parallax maps would hurt performance more than they're worth. It's nice the capability is provided anyway.
Game Development, Engine Development, Porting
http://www.darkwindmedia.com
User avatar
sinbad
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 19269
Joined: Sun Oct 06, 2002 11:19 pm
Location: Guernsey, Channel Islands
x 66
Contact:

Re: New Terrain Early Shots

Post by sinbad »

Yeah, it definitely adds to the effect close-up. It does cost a little more, but I'm still running at about 450-520fps here on my 9800 so I'm not too worried yet :) But you can turn it off selectively (also the normal mapping and specular mapping).
User avatar
sinbad
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 19269
Joined: Sun Oct 06, 2002 11:19 pm
Location: Guernsey, Channel Islands
x 66
Contact:

Re: New Terrain Early Shots

Post by sinbad »

Here's a shot showing how to use an additional global colour map to introduce extra variety; another optional feature but it can help make your terrains look more unique.
newterrain_8.jpg
newterrain_8.jpg (108.53 KiB) Viewed 6233 times
User avatar
Praetor
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 3335
Joined: Tue Jun 21, 2005 8:26 pm
Location: Rochester, New York, US
x 3
Contact:

Re: New Terrain Early Shots

Post by Praetor »

It's looking really awesome.
Game Development, Engine Development, Porting
http://www.darkwindmedia.com
User avatar
Xavyiy
OGRE Expert User
OGRE Expert User
Posts: 847
Joined: Tue Apr 12, 2005 2:35 pm
Location: Albacete - Spain
x 87

Re: New Terrain Early Shots

Post by Xavyiy »

Really beautiful sinbad :)
User avatar
DanielSefton
Ogre Magi
Posts: 1235
Joined: Fri Oct 26, 2007 12:36 am
Location: Mountain View, CA
x 10
Contact:

Re: New Terrain Early Shots

Post by DanielSefton »

Looking great! The batching sounds nice.

Going to spend tonight -trying- to add it to my project. :)

What is there left to do for the terrain feature wise? I guess you've finished most of the geometry stuff, and now it's just a matter of polishing the default material generator?

Can't think what else there might be - any more feature ideas from MyRddin? :P

Slope autosplatting would make it look much better *hint* :D, but I'm not sure if you'd leave that for the editor folks to implement (since I know you've left that bit fairly low level)
User avatar
Pyritie
Gnome
Posts: 363
Joined: Wed Feb 25, 2009 6:15 pm
Location: UK
x 8
Contact:

Re: New Terrain Early Shots

Post by Pyritie »

zomg new terrain is sexeh!
I use Mogre, BulletSharp, LuaNetInterface, irrKlang, and Miyagi! | Ponykart (Showcase)
Image
User avatar
sinbad
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 19269
Joined: Sun Oct 06, 2002 11:19 pm
Location: Guernsey, Channel Islands
x 66
Contact:

Re: New Terrain Early Shots

Post by sinbad »

There's lots left to do, sadly:

- fixing the ray query (in progress)
- Shadows (options for real-time and baked)
- Fog
- Fallback profiles for SM1 and fixed function
- Material LOD - drop parallax first, then normal mapping later
- paging integration refinements - normal/shadow calculation between pages for example
- real-time editing tests (code is there, but not really used yet); might be able to delegate this to others like stealth977 :)
- LOD tweaking - I can still see an occasional pop which I think is down to the LOD fading not always dealing with the transition up the hierarchy properly
User avatar
stealth977
Gnoll
Posts: 638
Joined: Mon Dec 15, 2008 6:14 pm
Location: Istanbul, Turkey
x 42

Re: New Terrain Early Shots

Post by stealth977 »

sinbad wrote:There's lots left to do, sadly:
- real-time editing tests (code is there, but not really used yet); might be able to delegate this to others like stealth977 :)
Started working on it yesterday :) Already implemented the decal cursor, but, waiting for your intersectsRay() fix, cant start editing without knowing where the mouse cursor is :)

EDIT: Btw, editing support is built-in in ogitor (abstracted) all i need to do is wire them to Terrain's functions, so it wont take much time to see how its working after the intersectsRay fix...

ismail,
Ismail TARIM
Ogitor - Ogre Scene Editor
WWW:http://www.ogitor.org
Repository: https://bitbucket.org/ogitor
User avatar
KungFooMasta
OGRE Contributor
OGRE Contributor
Posts: 2087
Joined: Thu Mar 03, 2005 7:11 am
Location: WA, USA
x 16
Contact:

Re: New Terrain Early Shots

Post by KungFooMasta »

I glanced at the code this morning, it looks like the Terrain's dimensions will always have the same width/depth? Did I misread, or are there factors that make it difficult to have terrain with differing width/depth dimensions?
Creator of QuickGUI!
User avatar
stealth977
Gnoll
Posts: 638
Joined: Mon Dec 15, 2008 6:14 pm
Location: Istanbul, Turkey
x 42

Re: New Terrain Early Shots

Post by stealth977 »

KungFooMasta wrote:I glanced at the code this morning, it looks like the Terrain's dimensions will always have the same width/depth? Did I misread, or are there factors that make it difficult to have terrain with differing width/depth dimensions?
Although Ogre::Terrain covers a square area, actually, OgreTerrain is just a page, for example in ogitor, you can add as many pages as you like, an extreme case below:

P01 P02 P03 P04
P05 P06 P06 P07
P08 P06 P06 P09

As you can see above, you can combine the pages to make any shape you like, even some pages like P06 in the example can cover much more space than other pages with few vertexes (imagine a desert area in the middle of usual hills)

Also each Page (Ogre::Terrain) can have its unique set of layers / textures / normal maps / colourmaps / lightmaps...

Sinbad's system is actually pretty flexibile...

ismail,

NOTE: Also by using terrain alignments, you can create a Page (Ogre::Terrain) with vertical alignment and a relatively low vertex count to simulate overhangs etc..

EDIT: By the way, using a layout like above you can use P01-p09 as for example 513x513 and p06 as 65x65, but of course such setups would need very good editing support to make borders compatible, thinking of adding some kinda automation to aid this process to ogitor... (like weld vertices in 3d editors)
Last edited by stealth977 on Fri Jun 19, 2009 10:29 pm, edited 1 time in total.
Ismail TARIM
Ogitor - Ogre Scene Editor
WWW:http://www.ogitor.org
Repository: https://bitbucket.org/ogitor
User avatar
Pyritie
Gnome
Posts: 363
Joined: Wed Feb 25, 2009 6:15 pm
Location: UK
x 8
Contact:

Re: New Terrain Early Shots

Post by Pyritie »

stealth977 wrote:NOTE: Also by using terrain alignments, you can create a Page (Ogre::Terrain) with vertical alignment and a relatively low vertex count to simulate overhangs etc..
OMG AWESOME
I use Mogre, BulletSharp, LuaNetInterface, irrKlang, and Miyagi! | Ponykart (Showcase)
Image
User avatar
KungFooMasta
OGRE Contributor
OGRE Contributor
Posts: 2087
Joined: Thu Mar 03, 2005 7:11 am
Location: WA, USA
x 16
Contact:

Re: New Terrain Early Shots

Post by KungFooMasta »

So if I have a heightmap of size 512 x 1024, and I want a terrain that matches it in world units (512 wide by 1024 deep), I'd need to create multiple pages and put them together? (pages of size 512) What about a narrow terrain level that was 1000 x 300? Would I have to have pages of size 100, and put together a 10 block x 3 block page structure?
Creator of QuickGUI!
User avatar
stealth977
Gnoll
Posts: 638
Joined: Mon Dec 15, 2008 6:14 pm
Location: Istanbul, Turkey
x 42

Re: New Terrain Early Shots

Post by stealth977 »

KungFooMasta wrote:So if I have a heightmap of size 512 x 1024, and I want a terrain that matches it in world units (512 wide by 1024 deep), I'd need to create multiple pages and put them together? (pages of size 512) What about a narrow terrain level that was 1000 x 300?
the sides must be power of 2 anyway(*)(**) :) and 2 dimensions both are power of 2 always have a common divisor :) so your terrain can only be 1025x257 which means you can put four pages of 257x257 together :)

And another note, please dont think that having 4 pages would behave like having 4 ETMs in a scene, its completely different because it uses paging, think it as PLSM2, you have a page size of 257x257 and a map of 4x1 pages.... (but again, this is much more stable and each page can have its own set of layers/textures....)

ismail,

(*) Why power of 2? You know its the golden rule of nearly all kinds of terrain rendering engines since lod is achieved by dividing by 2
(**) By saying power of 2 i mean the tile count per side, the vertex count is of course ((power of 2) + 1)

EDIT: But also you have a point there, Sinbad's implementation uses ONE SCALE for both X and Z (WorldSize) which is not so much important for the implementation, it could be changed to Vector2, so Width can have a different scale and Length can have another scale which wouldnt break the implementation...
Ismail TARIM
Ogitor - Ogre Scene Editor
WWW:http://www.ogitor.org
Repository: https://bitbucket.org/ogitor
User avatar
sinbad
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 19269
Joined: Sun Oct 06, 2002 11:19 pm
Location: Guernsey, Channel Islands
x 66
Contact:

Re: New Terrain Early Shots

Post by sinbad »

Yep, power of two (+1) is a requirement, it's the only way that the terrain can divide by two at each LOD level. Each page has to be square because the hierarchical approach requires it - each level absorbs 4 children into one parent, a non-square arrangement would stop the hierarchy batching the same way.

ismail hit the nail on the head - if you want non-square worlds, use multiple square pages. Each terrain page instance is no more expensive than if the terrain page was non-square anyway, because the same limitations on batching / hierarchy would apply (that's why it's pointless complicating the code to make the hierarchy algorithms stop when they hit non-square conditions). If you configure them with the same min/max batch settings, they will be entirely equivalent of a non-square single page.

Other systems could support non-square (but still power of two +1) terrains because they decimated the terrain into fixed patches, which always remained separate from each other (therefore always a minimum number of batches). My system batches things up which means many things:
  • fewer batches at distance
  • much larger LOD range (in theory if your min batch size is 33, the entire terrain patch could reduce to 33x33 vertices at distance, something that is impossible in systems where each page is divided into fixed patches)
  • the ability to drop more detailed geometry at distance, saving VRAM. Because we have to be able to support rendering the entire terrain in one batch, the terrain data is held at multiple resolutions to deal with the fact that 16-bit indexes can't possibly address the entire terrain at the most detailed level, but have to be able to at low LOD levels. At distance, the higher resolution terrain data can be purged from VRAM to free up space, leaving only the lower resolutions to serve the low LOD levels. This makes the system much more scalable.
[edit]Oh, and on the non-uniform dimensions (Vector2 world size), personally I don't think that's a good idea. It would distort / complicate many of the calculations (normals, shadows, LOD deltas), make the tesselation visually inconsistent, and make paging much more complicated. I also do not intend to support the case that ismail shows where a 2 pages join on to one page along an edge. The grid paging strategy will be using a singe page of terrain per grid cell. Of course, if you choose to build Terrain instances like that, you can - but you'd have to provide your own 'neighbour' calculations for things like normal and shadow calculations. I'll be adding the 'neighbour' system when I integrate paging further and will try to allow for that while still making our paging system use a simpler approach.

Generally speaking, I do not intend to try to cater for every single edge case with this system. IMO, such an approach of trying to be all things to all men just creates fragile systems with poorly defined operational parameters. I'm trying to be flexible with this system, but within certain sensible boundaries that allow clearly defined, easy to understand assumptions to be made. Others are of course free to extend or adapt if they want, but I'm aiming to hit the requirements of the majority at a high level of quality, and not get distracted by edge cases. Sometimes clear design limits are a good thing.
Post Reply