Editable Terrain Manager [v2.2 released]
-
- OGRE Retired Team Member
- Posts: 2903
- Joined: Thu Jan 18, 2007 2:48 pm
- x 58
- Contact:
-
- Gnoblar
- Posts: 13
- Joined: Mon Jul 16, 2007 7:51 pm
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.
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.
-
- OGRE Retired Team Member
- Posts: 2903
- Joined: Thu Jan 18, 2007 2:48 pm
- x 58
- Contact:
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.
-
- Halfling
- Posts: 44
- Joined: Sun Jul 08, 2007 3:50 am
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
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
-
- OGRE Retired Team Member
- Posts: 2903
- Joined: Thu Jan 18, 2007 2:48 pm
- x 58
- Contact:
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.
Therefore, if you need paging, ETM is not the right choice.
- KungFooMasta
- OGRE Contributor
- Posts: 2087
- Joined: Thu Mar 03, 2005 7:11 am
- Location: WA, USA
- x 16
- Contact:
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.
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!
-
- OGRE Retired Team Member
- Posts: 2903
- Joined: Thu Jan 18, 2007 2:48 pm
- x 58
- Contact:
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.
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.
- KungFooMasta
- OGRE Contributor
- Posts: 2087
- Joined: Thu Mar 03, 2005 7:11 am
- Location: WA, USA
- x 16
- Contact:
Excellent explanation! It isn't really feasible to add paging into my requirements, even if I wanted it.
Or make a terrain system where you can enable/disable paging. (easier said than done, I know. Just tossing out an awesome idea that I don't need)
Or make a terrain system where you can enable/disable paging. (easier said than done, I know. Just tossing out an awesome idea that I don't need)
Creator of QuickGUI!
-
- Halfling
- Posts: 44
- Joined: Sun Jul 08, 2007 3:50 am
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 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):
- 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).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.
- KungFooMasta
- OGRE Contributor
- Posts: 2087
- Joined: Thu Mar 03, 2005 7:11 am
- Location: WA, USA
- x 16
- Contact:
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.
Creator of QuickGUI!
-
- Gnoblar
- Posts: 5
- Joined: Mon Nov 12, 2007 9:45 pm
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!!!
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
The separate terrain managers get their own splatting manager/lightmap/etc... and it is really quite cool and performs great!!!
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
- KungFooMasta
- OGRE Contributor
- Posts: 2087
- Joined: Thu Mar 03, 2005 7:11 am
- Location: WA, USA
- x 16
- Contact:
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!
-
- OGRE Retired Team Member
- Posts: 2903
- Joined: Thu Jan 18, 2007 2:48 pm
- x 58
- Contact:
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
- KungFooMasta
- OGRE Contributor
- Posts: 2087
- Joined: Thu Mar 03, 2005 7:11 am
- Location: WA, USA
- x 16
- Contact:
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!
-
- OGRE Retired Team Member
- Posts: 2903
- Joined: Thu Jan 18, 2007 2:48 pm
- x 58
- Contact:
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.
So to resolve this properly, the outer tiles need to know their neighbours from the other TerrainManagers.
-
- Halfling
- Posts: 44
- Joined: Sun Jul 08, 2007 3:50 am
-
- OGRE Retired Team Member
- Posts: 2903
- Joined: Thu Jan 18, 2007 2:48 pm
- x 58
- Contact:
- KungFooMasta
- OGRE Contributor
- Posts: 2087
- Joined: Thu Mar 03, 2005 7:11 am
- Location: WA, USA
- x 16
- Contact:
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?
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!
-
- OGRE Retired Team Member
- Posts: 2903
- Joined: Thu Jan 18, 2007 2:48 pm
- x 58
- Contact:
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.
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.
- KungFooMasta
- OGRE Contributor
- Posts: 2087
- Joined: Thu Mar 03, 2005 7:11 am
- Location: WA, USA
- x 16
- Contact:
So in Tile::_notifyCurrentCamera, what is happening?
Code: Select all
...
// find the next LOD after the current one
...
Creator of QuickGUI!
-
- OGRE Retired Team Member
- Posts: 2903
- Joined: Thu Jan 18, 2007 2:48 pm
- x 58
- Contact:
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
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
-
- Halfling
- Posts: 44
- Joined: Sun Jul 08, 2007 3:50 am
TY CABAListicCABAListic wrote:You are correct, that's pretty much what needs to be done.
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
- KungFooMasta
- OGRE Contributor
- Posts: 2087
- Joined: Thu Mar 03, 2005 7:11 am
- Location: WA, USA
- x 16
- Contact:
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?
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!
-
- OGRE Retired Team Member
- Posts: 2903
- Joined: Thu Jan 18, 2007 2:48 pm
- x 58
- Contact:
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.
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.