Editable Terrain Manager [v2.2 released]

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
CABAListic
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 2903
Joined: Thu Jan 18, 2007 2:48 pm
x 57
Contact:

Post by CABAListic »

3) Yeah, then you are talking about material/shader properties. Look at the provided .material and .program file, you can set the parameters in either, but I'm not sure where I put them ;)

OgreUser
Gnoblar
Posts: 13
Joined: Mon Jul 16, 2007 7:51 pm

Post by OgreUser »

Hi,

I implemented ETM in my own code, but I'm having an error dialog when I quit the application. Seems to be quite similar as what Ayrik posted on page 2 of this topic : uninitialisation.

Could that concern the reference "mTerrainMgr->getTerrainInfo();" ?

I built ETM on Eihort 1.4.5 with VS2003, sample works fine.

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

Post by CABAListic »

I'm sorry, you MUST use a debugger and track the place where it goes havoc, otherwise I can't help you. Destroying ETM objects by themselves is error-free, at least for my own usage. Of course, if you destroy the terrain and then try to call getTerrainInfo(), then that won't work as you no longer have any terrain.

OgreUser
Gnoblar
Posts: 13
Joined: Mon Jul 16, 2007 7:51 pm

Post by OgreUser »

Hey CABAListic,

False alarm, I debugged and found my mistake :roll:
Gotta think more before posting :oops:

Thanks,
OgreUser

Laser
Halfling
Posts: 44
Joined: Sun Jul 08, 2007 3:50 am

Post by Laser »

Pls forgive the newbish question:

Is it a valid idea to create (and destroy) more than one Editable Terrain Manager, based on distance to camera? Wouldn't this implement paging ok? - provided that some methods are created, that can create/destroy terrain incrementally (for example, to load first the lowest LOD, then the next one - and to unload in the opposite order).

Thank you,
Laser

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

Post by CABAListic »

Well, you can construct more than one TerrainManager. But that won't give you paging, as that is more complex. For paging to work properly, the managers must know of each other, since otherwise you can't correctly place them next to each other (you would get cracks between them due to LOD). Also, as you already mentioned, you'd probably need more steps in-between than just terrain loaded / terrain unloaded.
Therefore, if you need paging, ETM is not the right choice.

User avatar
KungFooMasta
OGRE Contributor
OGRE Contributor
Posts: 2087
Joined: Thu Mar 03, 2005 7:11 am
Location: WA, USA
x 16
Contact:

Post by KungFooMasta »

I have recently been creating and destroying ETM terrain, and its taking a bit of time to create, I don't remember it taking ~8 seconds to load. (In debug.. release isn't so bad at all. I'm using a 1025 x 1025 heightmap with 1024 x 1024 texture map, no splatting. dimensions (1000,200,1000))

I would say hide/show terrain as you move away/towards terrain, but then you'd have a lot of terrain in memory (I think). ETM isn't meant for paging.

CABAListic, that book you mentioned, about RTS in Direct3D, do they describe any terrain paging implementation? I actually bought the book, since my team is working on an RTS. (hasn't arrived yet) I don't need paging, but I'm curious how they implement their terrain, in comparison with available terrain solutions.
Creator of QuickGUI!

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

Post by CABAListic »

No, they don't - simply for the reason that a standard RTS does not need paging. It wouldn't even work since the player can reposition the camera from the bottom of the map to the top instantaneously - if the top of the map was not loaded at that moment, you're in trouble. But if it was, what were you paging?
Paging, as it is commonly done, needs a maximum rate of camera movement so that it can preload areas in the background which might be needed soon and unload those which won't be needed for some time. RTS just don't satisfy that condition, you need the whole map in memory at all times. You could only optimise culling.

User avatar
KungFooMasta
OGRE Contributor
OGRE Contributor
Posts: 2087
Joined: Thu Mar 03, 2005 7:11 am
Location: WA, USA
x 16
Contact:

Post by KungFooMasta »

Excellent explanation! It isn't really feasible to add paging into my requirements, even if I wanted it. :lol:

Or make a terrain system where you can enable/disable paging. 8) (easier said than done, I know. Just tossing out an awesome idea that I don't need)
Creator of QuickGUI!

Laser
Halfling
Posts: 44
Joined: Sun Jul 08, 2007 3:50 am

Post by Laser »

Thank you for answer, CABAListic!

I finally got the time to read through the whole thread. It seems i'm not the only one asking about multiple ETMs and paging :)

Of course, me being a stubborn one, i still think that if at least the corect LOD between neighboured ETM's feature would be implemented (quoting you some pages (pun) ago):
I may eventually add the possibility to link TerrainManagers together as neighbours to correct this, but it's not a high priority task for me.
- then, because everything depends on camera speed, IMHO it could be enough to implement a VerySimplePagingSolution. If needed, on this, i think a time sliced ETM creation would not be hard to implement, even for me (creation algorithm same as now, just separating any loop iterations per slices).

User avatar
KungFooMasta
OGRE Contributor
OGRE Contributor
Posts: 2087
Joined: Thu Mar 03, 2005 7:11 am
Location: WA, USA
x 16
Contact:

Post by KungFooMasta »

Having neighboring ETMs with matching LOD would definately be a nice feature. But I believe the creating/destroying of ETMs in real time will have great impacts on performance. Well, maybe you can experiment and let us know. To temporarily get around the LOD issues, you can disable LOD entirely. :twisted:
Creator of QuickGUI!

jeng
Gnoblar
Posts: 5
Joined: Mon Nov 12, 2007 9:45 pm

Post by jeng »

I've been doing some work with the ETM. Here's a shot of a test with 4 terrain managers in a 2x2 grid. (I wrote a convertor from L3DT).

The separate terrain managers get their own splatting manager/lightmap/etc... and it is really quite cool and performs great!!!

Image

The obvious thing already mentioned is that there are seams both in geometry and texture coordinates. It should be possible to lock the edges from LOD and then line up the texture coords. Once this is done, a 9x9 grid of terrain managers could be used for simple paging.

-JE

User avatar
KungFooMasta
OGRE Contributor
OGRE Contributor
Posts: 2087
Joined: Thu Mar 03, 2005 7:11 am
Location: WA, USA
x 16
Contact:

Post by KungFooMasta »

Awesome! Locking the edges from LOD is a great idea! I don't know how LOD is implemented, so I don't know if this is feasible or not. Thanks for posting your results, for the people that are interested in using multiple ETM instances. :)
Creator of QuickGUI!

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

Post by CABAListic »

Yes, that is possible, but it requires that one TerrainManager instance knows about any adjoining others. So you'd have to "connect" them when building up, and I do not currently provide that functionality. As I said, I might add it some day, just not anytime soon, so if someone desperately needs it, please go ahead and send me a patch :)

User avatar
KungFooMasta
OGRE Contributor
OGRE Contributor
Posts: 2087
Joined: Thu Mar 03, 2005 7:11 am
Location: WA, USA
x 16
Contact:

Post by KungFooMasta »

What about disabling LOD from affecting edges at all times? Then the user can just raise/lower them to meet, and there shouldn't be any problems.
Creator of QuickGUI!

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

Post by CABAListic »

That's what I was planning to do initially (setting the highest LOD level at the edges of a terrain), but unfortunately, that doesn't quite work with the way that the GeoMipmapping algorithm does the stitching between lod levels. It does the reverse - more detailled lod levels stitch down to meet their lower level neighbours, not the other way around, so stitching to highest lod at the edges of a TerrainManager does not fit the lod index buffer creation scheme at all and would cause much extra work.
So to resolve this properly, the outer tiles need to know their neighbours from the other TerrainManagers.

Laser
Halfling
Posts: 44
Joined: Sun Jul 08, 2007 3:50 am

Post by Laser »

Is it related only with changing the TerrainImpl::getNeighbourState by storing pointers to the neighbour managers and considering their nearby tiles, or is it more than that?

That's the first time i got so far as to check what a Renderable is in the API.

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

Post by CABAListic »

You are correct, that's pretty much what needs to be done.

User avatar
KungFooMasta
OGRE Contributor
OGRE Contributor
Posts: 2087
Joined: Thu Mar 03, 2005 7:11 am
Location: WA, USA
x 16
Contact:

Post by KungFooMasta »

I'm tempted to look at the code sometime to see how it all works. I don't think knowledge of neighbors will work either, consider the case where you have one longer strip of terrain, with 3 square neighbors sharing the same edge. All terrain edges should match up. Hopefully there is a way to disable LOD, or put it in highest/lowest stitch, and manually deform the terrain to smoothly transition to its neightbor.

Does LOD only work when the camera is inside the plane AABB? Why does the edge of one terrain look different than another, since they are roughly the same distance to the camera. Maybe we can set our own AABB bounds, which would include multiple ETM instances?
Creator of QuickGUI!

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

Post by CABAListic »

D'oh, well, if you want to have TerrainManagers of different dimensions, then you're going straight to hell ;)
No seriously, that's going to get real ugly. Besides, what would you need that for? Not for paging, since paging would divide the world into equally sized components.

LOD is applied to a complete tile based on the camera distance (from the center of the tile) and an estimated pixel error for this particular tile. If you have a rather flat tile, then the maximal pixel error a lower detail lod might cause is not as high, therefore it will switch to lower LOD sooner. Doesn't have anything to do with bounding boxes.

User avatar
KungFooMasta
OGRE Contributor
OGRE Contributor
Posts: 2087
Joined: Thu Mar 03, 2005 7:11 am
Location: WA, USA
x 16
Contact:

Post by KungFooMasta »

:lol:

So in Tile::_notifyCurrentCamera, what is happening?

Code: Select all

...
// find the next LOD after the current one
...
Why are we looking for the next LOD? I'm trying to see how the LOD buffers are selected, which looks related to mLastNextLevel and nextLevel. Maybe we can set the edge Tiles to have a set vertex buffer for binding at all times, or skip binding LOD vertex buffers if its an edge Tile. Hard to say, I'm not so great at absorbing terrain implementations. :P
Creator of QuickGUI!

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

Post by CABAListic »

We're looking for the next LOD level to do vertex morphing; this is supposed to smoothen the switch from one level to the next by continously transforming a vertex to the position it will have in the next lod level (or rather, it would have, since it will no longer be rendered in the next level).

Of course you could always keep the edge tiles at highest lod, but that's kind of a bummer. You could have in view quite a few edge tiles which would always be at highest LOD - not exactly what LOD is there for in the first place, is it? ;) You would really need to only have the edges of the edge tiles at full lod, but as I explained that's the contrary of what the usual stitching algorithm does and would therefore require quite a bit of work (if at all possible) to work inside the GeoMipmap scheme.
Of course, other possibilities include to look for completely different LOD techniques than GeoMipmap, there are a few out there nowadays, and some of them might be more friendly to such endeavours. But that's also quite a bit of work. Besides, I said it before, ETM is really not aimed at doing such things; that it's actually possible to have more than one TerrainManager is just a by-product of the library's design, but not a supported feature in that regard ;)

Laser
Halfling
Posts: 44
Joined: Sun Jul 08, 2007 3:50 am

Post by Laser »

CABAListic wrote:You are correct, that's pretty much what needs to be done.
TY CABAListic :)

The second 'issue' seems to be just to make sure at all times (e.g. when deforming) that height values at the border of 2 terrains are the same (as they represent the same information actually) - or use their mean value.

Regards

User avatar
KungFooMasta
OGRE Contributor
OGRE Contributor
Posts: 2087
Joined: Thu Mar 03, 2005 7:11 am
Location: WA, USA
x 16
Contact:

Post by KungFooMasta »

Last night on the drive home I thought up a cool idea, but forgot to post it.

When creating the *Delta Buffers* for any given Tile, do not calculate a LOD'd position for the outter vertices of the Tile. So all Tiles will have no LOD applied to their border vertices (same as highest LOD). I doubt it would be noticeable, and it shouldn't be hard to implement right?
Creator of QuickGUI!

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

Post by CABAListic »

I think that the outer vertices might already be excluded from delta morphing since that could produce seams. But no, they have nothing to do with the chosen LOD levels and this would not help the problem at all.
The problem with LOD is that certain vertices are excluded from the index buffers of those LOD levels. The delta buffers are only there to smoothen the transition from included to excluded state of a vertex.

Post Reply