New Terrain Early Shots
- stealth977
- Gnoll
- Posts: 638
- Joined: Mon Dec 15, 2008 6:14 pm
- Location: Istanbul, Turkey
- x 42
Re: New Terrain Early Shots
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,
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
Ogitor - Ogre Scene Editor
WWW:http://www.ogitor.org
Repository: https://bitbucket.org/ogitor
- sinbad
- 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
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.
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.
-
- Gnoblar
- Posts: 5
- Joined: Tue Jun 16, 2009 7:42 pm
Re: New Terrain Early Shots
where/how can i get the demo??
- jacmoe
- OGRE Retired Moderator
- Posts: 20570
- Joined: Thu Jan 22, 2004 10:13 am
- Location: Denmark
- x 179
- Contact:
Re: New Terrain Early Shots
Get SVN trunk and compile.
/* Less noise. More signal. */
Ogitor Scenebuilder - powered by Ogre, presented by Qt, fueled by Passion.
OgreAddons - the Ogre code suppository.
Ogitor Scenebuilder - powered by Ogre, presented by Qt, fueled by Passion.
OgreAddons - the Ogre code suppository.
- sinbad
- 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
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.
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.
-
- OGRE Retired Team Member
- Posts: 2903
- Joined: Thu Jan 18, 2007 2:48 pm
- x 58
- Contact:
Re: New Terrain Early Shots
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 outputsinbad wrote:GL is working now, although I had to require fp40 under Cg which I know excludes ATI cards.
- sinbad
- 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
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.
-
- Gnoblar
- Posts: 5
- Joined: Tue Jun 16, 2009 7:42 pm
Re: New Terrain Early Shots
this screen looks totally awesome
i just dont like the grass texture
i just dont like the grass texture
- sinbad
- 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
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.
Parallax mapping is in now, global colour mapping (to break up patterns) is coming soon.
- jacmoe
- OGRE Retired Moderator
- Posts: 20570
- Joined: Thu Jan 22, 2004 10:13 am
- Location: Denmark
- x 179
- Contact:
Re: New Terrain Early Shots
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.
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.
Ogitor Scenebuilder - powered by Ogre, presented by Qt, fueled by Passion.
OgreAddons - the Ogre code suppository.
- Praetor
- 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
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
http://www.darkwindmedia.com
- sinbad
- 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
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).
- sinbad
- 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
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.
- Praetor
- 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
It's looking really awesome.
Game Development, Engine Development, Porting
http://www.darkwindmedia.com
http://www.darkwindmedia.com
- Xavyiy
- OGRE Expert User
- Posts: 847
- Joined: Tue Apr 12, 2005 2:35 pm
- Location: Albacete - Spain
- x 87
Re: New Terrain Early Shots
Really beautiful sinbad
Creator of SkyX, Hydrax and Paradise Sandbox.
Looking for Ogre3D consulting services?
Follow me: @Xavyiy
Looking for Ogre3D consulting services?
Follow me: @Xavyiy
- 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
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?
Slope autosplatting would make it look much better *hint* , 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)
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?
Slope autosplatting would make it look much better *hint* , 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)
- Pyritie
- Gnome
- Posts: 363
- Joined: Wed Feb 25, 2009 6:15 pm
- Location: UK
- x 8
- Contact:
Re: New Terrain Early Shots
zomg new terrain is sexeh!
- sinbad
- 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
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
- 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
- stealth977
- Gnoll
- Posts: 638
- Joined: Mon Dec 15, 2008 6:14 pm
- Location: Istanbul, Turkey
- x 42
Re: New Terrain Early Shots
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 issinbad 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
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
Ogitor - Ogre Scene Editor
WWW:http://www.ogitor.org
Repository: https://bitbucket.org/ogitor
- KungFooMasta
- OGRE Contributor
- Posts: 2087
- Joined: Thu Mar 03, 2005 7:11 am
- Location: WA, USA
- x 16
- Contact:
Re: New Terrain Early Shots
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!
- stealth977
- Gnoll
- Posts: 638
- Joined: Mon Dec 15, 2008 6:14 pm
- Location: Istanbul, Turkey
- x 42
Re: New Terrain Early Shots
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: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?
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
Ogitor - Ogre Scene Editor
WWW:http://www.ogitor.org
Repository: https://bitbucket.org/ogitor
- Pyritie
- Gnome
- Posts: 363
- Joined: Wed Feb 25, 2009 6:15 pm
- Location: UK
- x 8
- Contact:
Re: New Terrain Early Shots
OMG AWESOMEstealth977 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..
- KungFooMasta
- OGRE Contributor
- Posts: 2087
- Joined: Thu Mar 03, 2005 7:11 am
- Location: WA, USA
- x 16
- Contact:
Re: New Terrain Early Shots
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!
- stealth977
- Gnoll
- Posts: 638
- Joined: Mon Dec 15, 2008 6:14 pm
- Location: Istanbul, Turkey
- x 42
Re: New Terrain Early Shots
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 togetherKungFooMasta 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?
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
Ogitor - Ogre Scene Editor
WWW:http://www.ogitor.org
Repository: https://bitbucket.org/ogitor
- sinbad
- 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
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:
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.
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.
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.