New Terrain Early Shots

[sinbad]

Vertex compression is on the TODO too which would help.

[thegeek]

Sinbad: regarding the x64 crash issue, you both closed the issue and asked me to check that it's fixed.
Not wanting to reopen the issue; I can confirm it is fixed, the samplebrowser can now run the terrain sample when compiled as x64.

[Praetor]

I being able to limit the geometry created for distant pages will make a big difference. It'll enable expansive draw distances over many pages. Only when you get closer will the page's higher detail geometry even need to exist on the card.

[sinbad]

I being able to limit the geometry created for distant pages will make a big difference. It'll enable expansive draw distances over many pages. Only when you get closer will the page's higher detail geometry even need to exist on the card.

Yeah, and this is basically designed in already, since geometry is held at various different levels in the quad tree already - this was initially to deal with the problem of not being able to re-use high-detail geometry at lower, heavily batched LODs because 16-bit indexes could not address the required range. However, it also offers a perfectly good route to only storing geometry at certain levels of the tree and dropping others. It needs the load/purge hooks to do it though and a decision about whether we keep the data in main CPU memory all the time (probably yes for simplicity I think since otherwise lots of other code will change).

[Praetor]

Yeah I think the main goal here would be to manage GPU memory. Though, I don't exactly know how much pages are generally taking up in main memory either.

[stealth977]

IMO Paging Component should guarantee that only the data that will be used will be in CPU memory... (Although being able to load the data from disk in various resolutions would speedup paging, but would also increase disk usage)

[sinbad]

No, the paging component handles things at a higher level, what we're talking about here is scaling the data within a specific page based on distance, without actually paging it in/out in a high-level sense. The paging component does have a level where this could be expressed (the page collection) but in this case the data is so strongly associated with the internal terrain data structures (quadtree) it makes sense to keep it as an internal thing, it wouldn't help to abstract it to the page level. Basically it's just like mesh LOD, except with some data actually being removed from GPU memory.

[jacmoe]

I have a small question.

From the terrain sample:

Code: Select all

		entPos.y = mTerrainGroup->getHeightAtWorldPosition(entPos) + 65.5 + mTerrainPos.y;

From where is '65.5' coming from?

[moagames]

hmm...isn't this just the half height of the entity ?
So that the entity is placed with the bottom point on the terrain and not the center point.

[jacmoe]

Probably, if the origin is at the centre instead of at the base. That actually crossed my mind while posting it.

[adanar]

I looked around the forums a little bit but could not locate a definitive answer. Does core 1.7 support very large terrains now or is PLSM still necessary?

[jacmoe]

It's safe to say that you'd be much happier using the Terrain Component than PLSM.
Even if you have to write a paging manager yourself, until one is provided.
It's a lot more flexible in use, and a core component.
PLSM2 is not actively maintained (IIRC), and quite difficult to setup and use.
There's no limit to the size of your terrain when using the terrain component.
So, go for that.

[Tango]

FYI, TerrainGroup::mOrigin isn't being initialized in the constructor.

So if any of you using TerrainGroup are experiences issues where sometimes terrain is loaded but just not visible, there's a good chance its off in "unhappy random offset land".

I submitted a one line patch. Took me a while to track this one down today.

[jacmoe]

FYI, TerrainGroup::mOrigin isn't being initialized in the constructor.

I know.
Which is why I call mTerrainGroup->setOrigin in my own code.

[stealth977]

Sinbad:

Is there a way to define which directional light to use for terrain shadows? It seems to pick one random light from the list... (Yes i guess it can be tweaked by making other lights not cast shadows, but in case we need to, is there a way to specify the light to be used?)

[stealth977]

One little Feature Request:

Please add internal support for terrain resizing. Like a TerrainGroup->ResizeAllTerrain(newwidth,newheight, mode) which does:
- Resizes the internal heightmap image depending on the sampling mode

Ex: 129x129 to 257x257 with bilinear sampling

Yes, it can be done OUTSIDE of the terrain code, but its too much complicated since you need to save all terrain properties like heightmap,blendmaps, layers, colourmap etc and delete and re-create the terrain + restore all properties etc... But if done internally, its much cheaper and easier to replace heightmap data and then re-calculate derived data...(there will be no need to touch blendmaps/colourmaps and even lightmap)

EDIT: Another function for adjusting WorldSize would be great, it would be much cheaper compared to first request, only repositioning the pages and adjusting worldsizes of each...Those functions are a must have for an Editor, so i am asking you those features since they are much cheaper when internally implemented and since you wanna have some support functions for editors...

[adanar]

There's no limit to the size of your terrain when using the terrain component.
So, go for that.

Maybe there is not theoretical limit but there is obviously a limit due to memory, right? since there is no paging manager to load/unload parts of the terrain from memory..

[jacmoe]

Maybe there is not theoretical limit but there is obviously a limit due to memory, right? since there is no paging manager to load/unload parts of the terrain from memory..

Er, hello? I said:

It's safe to say that you'd be much happier using the Terrain Component than PLSM.
Even if you have to write a paging manager yourself, until one is provided.

[sinbad]

Actually there is a paging component already there. Just uncomment the

Code: Select all

#define PAGING

.. at the top of the Terrain.h sample plugin file to make it use it, and change the values of TERRAIN_PAGE_MIN_X etc.

I'm not 100% happy with the speed of the paging yet which is why I'm not promoting it heavily. But it works.

Oh, but you MUST really have already run the demo with that page range at least once to get a decent page load time, because the paging is only at its fastest when loading the pre-compiled terrain data files (of the form testTerrain_0000ffff.dat etc). When it's loading them from images the first time, it's super-slow because it has to calculate all the lightmaps and everything else from scratch. Once it's done this it saves the .dat file and then the page is vastly more efficient to use in future.

[sinbad]

Is there a way to define which directional light to use for terrain shadows? It seems to pick one random light from the list... (Yes i guess it can be tweaked by making other lights not cast shadows, but in case we need to, is there a way to specify the light to be used?)

The lightmap is generated from a direction you give manually. The dynamic lighting uses OGRE's standard light ordering as used by every other material - it only supports one light though so picks the first directional light in the list.

[sinbad]

One little Feature Request:
Please add internal support for terrain resizing. Like a TerrainGroup->ResizeAllTerrain(newwidth,newheight, mode) which does:
- Resizes the internal heightmap image depending on the sampling mode

EDIT: Another function for adjusting WorldSize would be great, it would be much cheaper compared to first request, only repositioning the pages and adjusting worldsizes of each...Those functions are a must have for an Editor, so i am asking you those features since they are much cheaper when internally implemented and since you wanna have some support functions for editors...

I'd encourage you to submit a patch if you need these in the short term. I can put this on a list but my priorities are elsewhere for the moment, I need to get 1.7 done and I'm concentrating on bugfixes and other related issues for the moment.

[stealth977]

I'd encourage you to submit a patch if you need these in the short term. I can put this on a list but my priorities are elsewhere for the moment, I need to get 1.7 done and I'm concentrating on bugfixes and other related issues for the moment.

Ok, I completed the WorldSize setting part, will post a patch soon (after some tests), the MapSize setting is more trickier considering my insufficient knowledge on internal workings of Ogre::Terrain

Anyway, i can supply a working patch for setting MapSize (soon) and you can perfect it when you have time

I really need them both bad since the workaround (OUTSIDE Implementation) is so time consuming (processor time wise)

NOTE: Btw, much more built-in functionality may be needed for an editor since your BINARY FORMAT is not much hackable compared to separate hmap, blend, lmap etc. files..

[sinbad]

NOTE: Btw, much more built-in functionality may be needed for an editor since your BINARY FORMAT is not much hackable compared to separate hmap, blend, lmap etc. files..

I have several people using it in their editors without complaint so far 'Hacking' should not be required if your editor handles everything, the binary format is designed with that in mind. No, it's not designed to be hacked on piecemeal afterwards like separate image maps are, that was a conscious decision. There's simply no fully efficient way to support this and have the fastest loading times & predictability as well (people hacking on the hmap aren't also going to hack on the deltas file because they don't understand them - so you introduce variances and awkward edge cases that just need dealing with at load time, which slows things down and complicates things, which is precisely what I didn't want).

If you want full hackability, use the import route. That's the 'hackable' one and comes with the same sorts of inherent inefficiencies. The binary file is unashamedly packed and designed for machine consumption rather than human modifying.

[stealth977]

Yup, i know, not against it, infact i am changing how Ogitor saves the terrain (will use native binary format instead of separate files -> Import). But things like re-sampling the heightmap (resizing) easier when separate files are used, but harder when packed binary is used, thats why i said more support functions will be needed in the future.

Yes, all can be done by external code, but external code means

- fetching data from page and storing somewhere
- destroying page
- re-creating page with the changed data

and takes too long (maybe a few seconds per page but lots of minutes for a multi-page production map), so some internal functionality is always cool

And another issue is the light & shadows issue. Supporting 1 directional light is understandable, but not being able to decide which light to use has some issues (we may want to use all available lights for some of the stuff we render in the scene where we can getaway with only 1 light for terrain, but this time, we cant simply setCastShadows(false) for all lights).

So, instead of AUTO fetching the first light from OGRE, the terrain could let user define the light to use and pass that lights parameters to shader... Anyway, yes I know, thats whats provided, if i want more options i better write my own material generator

Still, my 2 cents...

[Praetor]

Something like this: http://www.ogre3d.org/forums/viewtopic.php?f=4&t=53559? Read the bottom posts. Basically, if the terrain were to expose the light flags then you should be able to control which light affects the terrain using this mechanism. The light flags/mask stuff should be in 1.7. The stuff I added to allow materials to reference it is what is in HEAD now.