[GSoC 2011 - Accepted] Terrain paging improvements

Threads related to Google Summer of Code
kuxv
Google Summer of Code Student
Google Summer of Code Student
Posts: 53
Joined: Wed Jan 09, 2008 7:51 pm
Location: Czech Republic
x 16

Re: [GSoC 2011 - Accepted] Terrain paging improvements

Post by kuxv »

Ok, that sounds all right. I've just implemented little feature to Terrain sample. Now there is LOD level shown above each terrain's patch. It will help me to debug separate LOD loading later on. It is possible that I will move it away to separate demo of its own(i.e. paging). I'm using overlay for text rendering which game me little headache thanks to this bug http://www.ogre3d.org/mantis/view.php?id=324 . It just didn't show anything until I resized window. I can live with that now and I'll just start working on separate LOD loading. I will polish it later(i.e. allow for enable/disable).

You can see in my commit (https://bitbucket.org/kuxv/ogre_soc_tpi ... 07941e3ea1) some changes which are just for my personal needs like change to make Fly mode default. I think those are not things which should be commited but what would be best way to avoid that? I'm going to revert that at the end of my project thou.

I also noticed that I have my scheduled start of coding set on 25th of May. I don't know why but I see it on GSoC's timeline as well. Well anyway I have 2 additional days for coding. Great ;)
My Google summer of code 2011 topic: Terrain paging improvements
My Google summer of code thread
My Google summer of code wiki page
User avatar
Zonder
Ogre Magi
Posts: 1168
Joined: Mon Aug 04, 2008 7:51 pm
Location: Manchester - England
x 73

Re: [GSoC 2011 - Accepted] Terrain paging improvements

Post by Zonder »

kuxv wrote:It is possible that I will move it away to separate demo of its own(i.e. paging).
That is probably a good idea people won't necessarily want paging support and they look to the samples to get started so it would compilcate somthing when they don't need it.
There are 10 types of people in the world: Those who understand binary, and those who don't...
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: [GSoC 2011 - Accepted] Terrain paging improvements

Post by sinbad »

I agree - because paging wasn't really finished I just left it as commented out bits, but you're probably best to make a separate sample for your purposes.

The first time the terrain loads it has to do a lot of pre-processing on the lighting and composite maps, which when you add paging has 2 effects:

1) It takes a lot longer!
2) The lightmaps and LOD can only be calculated on the full data, so the first time you actually need to load everything up-front

So this means the sample will probably need to load everything in a non-paging style the first time (if the data isn't present), generate all the lightmaps, calculate LODs and split data up into its paging structures, save all that, then unload it all and start again with the proper paging behaviour, loading this time progressively from all that pregenerated / split data. So this in itself will be much easier to organise if you have a separate sample.

Also editing of the terrain still throws some spanners in the works here, but even so gradual editing is easier to handle than the bulk initial calculation.

Of course in a real application this calculation & splitting process would be done before shipping and just the results used (except for any dynamic modifications if they use that). The only reason we don't in Ogre is because the data files get too large to include in the source repository.
kuxv
Google Summer of Code Student
Google Summer of Code Student
Posts: 53
Joined: Wed Jan 09, 2008 7:51 pm
Location: Czech Republic
x 16

Re: [GSoC 2011 - Accepted] Terrain paging improvements

Post by kuxv »

Progress update:

I have successfully modified Terrain and TerrainQuadTreeNode classes to allow separate loading of LOD levels. So I can now load specific LOD I want at the beginning and load/unload other levels on the fly. It is not in final shape but as a proof of concept it does it's job and works. I have done some temporary modifications to the code which are not supposed to stay as they are so I don't want to commit them now. Although I can do that if you are interested and just use my repository as a backup and clean it all at the end.

Currently loading/unloading takes care of GPU hardware buffers(vertex and index) as CPU buffers are freed anyway. Basically all structures used by terrain classes are kept in place as they were. It is no problem except mHeightData and mDeltaData. Those 2 hold heightfield and delta data of terrain and they could go as big as is your heightmap's resolution. The problem is they can't be freed by parts because it is currently used like a 2D array of heights/deltas. So even if you keep just lowest LOD you can't free unused fields because you can't make holes in an array. So you need to have it all in memory even if you don't use it. Another thing is you need them also for editing mode and for querying height at point. Solution would be to reorganize those arrays so all vertices from lowest LOD are stored on the beginning of the array and highest at the end. So they can be allocated/deallocated as needed. For compatibility there could be just a function like getHeightDataPoint(x,y) which would translate coordinates from modified array organization to classic one. Or it should be possible to free them all and load them whole in just when used in edit mode or when user wants to use query functions(like getPointAt()). I like second solution more because editing should be done offline and querying could be done on physics model. But I would like to know your thoughts guys. I'm also counting on the fact that preprocessing of composite/lightmap etc would be done already before separate LOD loading would be used.

One thing to notice: To allow separate read of height data stream seeking is needed and currently prepare() method takes StreamSerializer which can't do seek by bytes(at least I didn't find out how to) thus I can't skip reading of height/delta data. So I added another prepare() which takes just DataStreamPtr. There is also load() method which takes StreamSerializer as argument. So those functions have to load all height/delta data at the beginning. But their equivalents using Filename could use separate LOD load.

Everything goes well according to my planned schedule and I have basically more then 2 weeks left to finish this stage(separate LOD loading) which seems to be maybe more then enough ;)
My Google summer of code 2011 topic: Terrain paging improvements
My Google summer of code thread
My Google summer of code wiki page
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: [GSoC 2011 - Accepted] Terrain paging improvements

Post by sinbad »

kuxv wrote:I have done some temporary modifications to the code which are not supposed to stay as they are so I don't want to commit them now. Although I can do that if you are interested and just use my repository as a backup and clean it all at the end.
Please commit early & often - it's your fork so it doesn't matter if it has some temporary hacks in it - just mark them with a comment in the proximity so people don't start telling you it's hacky when you already know ;)
Solution would be to reorganize those arrays so all vertices from lowest LOD are stored on the beginning of the array and highest at the end. So they can be allocated/deallocated as needed. For compatibility there could be just a function like getHeightDataPoint(x,y) which would translate coordinates from modified array organization to classic one.
The two issues you mentioned (editing and height queries) are valid ones. For editing, you can justify having to force a load of the full precision data, because you can't edit down-sampled data, but for the height query, if this just during runtime most applications would probably be happy to accept the lower quality results based on the currently loaded data, because that's what they're rendering anyway. Therefore you probably want to have some way to force the loading to full detail, which would be called for editing, but when this hasn't been called, just sample the currently loaded data as accurately as is possible, and interpolating the rest.
One thing to notice: To allow separate read of height data stream seeking is needed and currently prepare() method takes StreamSerializer which can't do seek by bytes(at least I didn't find out how to) thus I can't skip reading of height/delta data. So I added another prepare() which takes just DataStreamPtr. There is also load() method which takes StreamSerializer as argument. So those functions have to load all height/delta data at the beginning. But their equivalents using Filename could use separate LOD load.
StreamSerializer is just a wrapper around DataStream in order to simplify the reading / writing of a chunk-based file. Feel free to add a seek in bytes method to it, the only reason it's not there is that no-one has needed it before. Please note: the whole concept of a chunked file is that there are blocks of data preceded by a header, which tells you how big the following data is. This is very robust and is generally much better than just laying out the file arbitrarily. You could just use a single chunk to contain all of the sections of data for the terrain, and just have a data header section which describes how that data is internally partitioned, which would provide the information needed to calculate the seeks. The nice thing about this is that it's self-describing, and therefore easier to debug / test.
kuxv
Google Summer of Code Student
Google Summer of Code Student
Posts: 53
Joined: Wed Jan 09, 2008 7:51 pm
Location: Czech Republic
x 16

Re: [GSoC 2011 - Accepted] Terrain paging improvements

Post by kuxv »

Please commit early & often - it's your fork so it doesn't matter if it has some temporary hacks in it - just mark them with a comment in the proximity so people don't start telling you it's hacky when you already know
Alright, committed ;)
For editing, you can justify having to force a load of the full precision data, because you can't edit down-sampled data, but for the height query, if this just during runtime most applications would probably be happy to accept the lower quality results based on the currently loaded data, because that's what they're rendering anyway. Therefore you probably want to have some way to force the loading to full detail, which would be called for editing, but when this hasn't been called, just sample the currently loaded data as accurately as is possible, and interpolating the rest.
I will just load highest LOD when editing function is called. Other solution would be to let this responsibility on user. I mean it could take a big lag when edit mode is used for first time(or after highest LOD level unload) so that could be "surprise" for user. But if it is up to user to do it it could be more under control. It is also possible to let user decide if he wants to load it automatically or not. I will go this way probably. Sampling height data is good idea and it makes perfect sense as it will copy height at distance perfectly.
StreamSerializer is just a wrapper around DataStream in order to simplify the reading / writing of a chunk-based file. Feel free to add a seek in bytes method to it, the only reason it's not there is that no-one has needed it before. Please note: the whole concept of a chunked file is that there are blocks of data preceded by a header, which tells you how big the following data is. This is very robust and is generally much better than just laying out the file arbitrarily. You could just use a single chunk to contain all of the sections of data for the terrain, and just have a data header section which describes how that data is internally partitioned, which would provide the information needed to calculate the seeks. The nice thing about this is that it's self-describing, and therefore easier to debug / test.
I think understand purpose of StreamSerializer but I just need raw seek by bytes because in my case I need to skip individual vertices and not just whole chunks. I will add seek function so all current methods could work with that. But it won't be backward compatible then I suppose.
My Google summer of code 2011 topic: Terrain paging improvements
My Google summer of code thread
My Google summer of code wiki page
kuxv
Google Summer of Code Student
Google Summer of Code Student
Posts: 53
Joined: Wed Jan 09, 2008 7:51 pm
Location: Czech Republic
x 16

Re: [GSoC 2011 - Accepted] Terrain paging improvements

Post by kuxv »

Hello there,
it was a long time since last update mainly caused by death of my computer. I reworked terrain's LOD loading mechanism so now it removes/adds whole vertex data as opposed to vertex data belonging to single LOD. I think this better maps to terrain's internals and it is actually more memory efficient. I updated TerrainPaging sample as well and it shows some statistics of what data are currently in memory/cpu/gpu. I just finished bilinear interpolation of heightfield for height queries when full heightmap detail is no available. I'm actually behind schedule but I remain optimistic about future progress. My next week's tasks are integration of separate LOD loading into TerrainGroup with background loading and user notification/configuration system.

Perhaps little documentation for current TerrainPaging sample. You can add/remove LOD levels using keys + - You can also set specific LOD using numeric keys. It is mainly for debug it crashes if you are removing LOD level you are viewing so be prepared.

Cheers
My Google summer of code 2011 topic: Terrain paging improvements
My Google summer of code thread
My Google summer of code wiki page
User avatar
Jabberwocky
OGRE Moderator
OGRE Moderator
Posts: 2819
Joined: Mon Mar 05, 2007 11:17 pm
Location: Canada
x 218
Contact:

Re: [GSoC 2011 - Accepted] Terrain paging improvements

Post by Jabberwocky »

I'm really happy to see the terrain paging improvements are moving forward.
All the GSoC projects are cool this year, but this is the one I'm personally most excited about.
Image
kuxv
Google Summer of Code Student
Google Summer of Code Student
Posts: 53
Joined: Wed Jan 09, 2008 7:51 pm
Location: Czech Republic
x 16

Re: [GSoC 2011 - Accepted] Terrain paging improvements

Post by kuxv »

Hello,
I figured out how to load terrain data in background thread and implemented stepped LOD loading in TerrainGroup. It works just for my test case now but hardest work is done. In next few days I will add unloading as well and polish whole interface and do final fixes. From design side point of view TerrainGroup works as a high level class which calls Terrain's "low level" methods to load/unload LODs. So state about what LOD should be loaded/unloaded next is held in TerrainGroup's slot instead of in each Terrain. I decided to do it that way. If you guys have any notes about that or anything else please feel free to post them here as I would like to know other's opinions as well.
My Google summer of code 2011 topic: Terrain paging improvements
My Google summer of code thread
My Google summer of code wiki page
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: [GSoC 2011 - Accepted] Terrain paging improvements

Post by sinbad »

Great, I'll have a look at the code in more detail tomorrow.

So we can all understand how you've structured this, can you explain in more detail how you split the terrain data loading from a single load for an entire page, to a load per LOD? Also please clarify what this means for people not using paging (so just a Terrain instance)

Using the TerrainGroup as an organiser is the right approach, since that's how the paging has been done already.
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: [GSoC 2011 - Accepted] Terrain paging improvements

Post by sinbad »

I haven't been able to run your updated code yet, it crashes during the load process. I thought at first that it might be that the .dat file I had was from a previous save (and therefore would be compressed, which the updates don't support yet - something that might be resolvable by compressing within each block of data in future), so I deleted that. However, that just caused another crash in the load process of the terrain paging demo.

So I thought I might need to run the non-paging version to at least generate & save the data for the .dat (since escalating the load enough to be able to save the pre-built terrain data isn't done yet), but that crashes too.

How are you testing this right now, and is there something we need to do to see what you see? Details welcome!
kuxv
Google Summer of Code Student
Google Summer of Code Student
Posts: 53
Joined: Wed Jan 09, 2008 7:51 pm
Location: Czech Republic
x 16

Re: [GSoC 2011 - Accepted] Terrain paging improvements

Post by kuxv »

Separate LOD loading: I modified Terrain classes methods prepare() and load(). prepare() now takes parameter readData which enables old behavior i.e. it reads in all heightfield data and then creates CPU vertex data and assigns them to QuadTree. Then load() method creates GPU vertex data and creates layers. load() takes parameter which you can tell whether to create GPU data or not. Those extra parameters for load() and prepare() have default values which make them work in a way old Terrain component worked. That is basically to keep backward compatibility. If you want to use separate LOD loading then you change those default values to false. This way prepare() reads in everything except height and delta data. After user calls prepareLodLevel(int) which takes number of LOD level he wants to load in. prepareLodLevel() opens file, reads in height&delta data of LOD level specified and then creates CPU data in QuadTree. Next step is to call loadLodLevel(int) which creates GPU data for given LOD level(it creates whole vertex data range) and possibly creates layers. There are also helper functions addLodLevel(), setLodLevel(), removeLodLevel() which just calls prepareLodLevel() and loadLodLevel() methods but makes it easier for user to work with.
Then there is TerrainGroup which holds information about Terrain's status about what LOD levels are loaded stored in each slot. Then there is method loadTerrainLodNextHigher(slot coords) which just calls terrain's prepare(), prepareLodLevel(), loadLodLevel() and loads next LOD level which is not loaded yet(from lowest to highest detail). When you call this method it finds out what is number of next LOD level to load, adds it to queue and calls load in background thread. In this thread prepareLodLevel() takes LOD level number from queue and reads data in and creates CPU data. After this it starts reading in next LOD level from queue in background and creates GPU data in main thread via loadLodLevel(). I added method like this(loadTerrainLodNextHigher) as I think it is more convenient for user as mostly everybody want to increase/decrease actual LOD level instead of setting one specific level.

About problems with Terrain demo and Paging demo crashing. I'm using noncompressed terrain .dat file which I generated using Terrain demo but without using compression. I know that import from image is now broken because I was focused just on separate LOD load functionality and was ignoring the rest around. This is going to be fixed soon as I finish whole functionality in TerrainGroup. Terrain's .dat file is not changed so you can use your own from old Ogre version's but without compression turned on. I uploaded my .dat file if you would like to try mine(which is default one from unmodified Ogre without compression). Just unzip it and put it inside Samples/Media/ directory. You can find it here: http://www.uloz.to/9571567/testterrain-00000000-zip

Uff, sorry for longer post. Any questions welcome.
My Google summer of code 2011 topic: Terrain paging improvements
My Google summer of code thread
My Google summer of code wiki page
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: [GSoC 2011 - Accepted] Terrain paging improvements

Post by sinbad »

No problem, I figured it was something like that. Thanks for the confirmation and data file, that should keep everyone going in the mean time!

Thanks for confirming your changes - I implied most of this from reading your changes but these things are always clearer when explained holistically. I think you've structured things correctly, with Terrain having the individual mechanisms for loading the LODs (or all at once), and higher level classes like TerrainGroup organising it at a higher level (which you'll then tie into a paging strategy later I assume). From what you've said, importing from images will work the old way, with the intention that you'd save the terrain data, then re-load it to get the lod paging support - and this would also I think tie into the need to 'escalate' the LOD loading for editing cases.

Looking forward to seeing the next steps!
kuxv
Google Summer of Code Student
Google Summer of Code Student
Posts: 53
Joined: Wed Jan 09, 2008 7:51 pm
Location: Czech Republic
x 16

Re: [GSoC 2011 - Accepted] Terrain paging improvements

Post by kuxv »

Ok I added LOD removal to TerrainGroup. I renamed methods for LOD add/remove as well. It is now increaseLodLevel() and decreaseLodLevel(). I fixed image import function as well. So now you can easily see how that works. Just start for first time and let demo create terrain .dat file. Then start demo again and you can increase/decrease LOD level using +/- keys. LOD loading works in background thread but unloading runs in main as it is not time consuming operation. It just frees some memory. So basic functionality is all there now and I will continue with bug fixing(i.e. correct LOD statistics in demo) and such. I will modify loading mechanism in TerrainGroup a little as it needs to read data in background thread somewhere else as well as some other tweaks concerning thread safe code. Hope you enjoy it ;)
My Google summer of code 2011 topic: Terrain paging improvements
My Google summer of code thread
My Google summer of code wiki page
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: [GSoC 2011 - Accepted] Terrain paging improvements

Post by sinbad »

Great stuff, I'll have a proper play with everything at the weekend. :) So just to confirm - for now the loading / unloading of individual LODs is all manual, and you'll be hooking it in to the paging process as the next major feature item, correct?
kuxv
Google Summer of Code Student
Google Summer of Code Student
Posts: 53
Joined: Wed Jan 09, 2008 7:51 pm
Location: Czech Republic
x 16

Re: [GSoC 2011 - Accepted] Terrain paging improvements

Post by kuxv »

Yes, that is exactly my intention ;)
My Google summer of code 2011 topic: Terrain paging improvements
My Google summer of code thread
My Google summer of code wiki page
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: [GSoC 2011 - Accepted] Terrain paging improvements

Post by sinbad »

Awesome. All sounds good then - keep up the great work!
kuxv
Google Summer of Code Student
Google Summer of Code Student
Posts: 53
Joined: Wed Jan 09, 2008 7:51 pm
Location: Czech Republic
x 16

Re: [GSoC 2011 - Accepted] Terrain paging improvements

Post by kuxv »

I just changed LOD load controls from +/- to PAGE UP/PAGE DOWN so they don't collide with terrain editing keys. Terrain editing now allowed only when full LOD is loaded. Added whole terrain class removal/unload when last LOD removed. Only segfault you can get now is when hitting PAGE UP too fast because terrain data load in background thread is still not thread safe. Working on that now.
My Google summer of code 2011 topic: Terrain paging improvements
My Google summer of code thread
My Google summer of code wiki page
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: [GSoC 2011 - Accepted] Terrain paging improvements

Post by sinbad »

Cool - remember, try not to use locking to resolve thread safety issues, instead try to use non-shared data with queued synchronisation points which are as quick and cheap as possible - the WorkQueue helps you do this.
kuxv
Google Summer of Code Student
Google Summer of Code Student
Posts: 53
Joined: Wed Jan 09, 2008 7:51 pm
Location: Czech Republic
x 16

Re: [GSoC 2011 - Accepted] Terrain paging improvements

Post by kuxv »

Hello, I've just made TerrainGroup's LOD loading thread safe. Currently LOD load works in 5 stages:
  • prepare (0)
  • data read (1)
  • data fill/copy (2)
  • CPU vertex data creation (3)
  • GPU vertex data creation (4)
Stage 0 is done only when terrain isn't initialized. It reads in terrain info like terrain size, layers, etc from file. Because it modifies terrain's data it runs in main thread. Stage 1 reads height and delta data from file into own buffer. Buffer is created as big as needed for requested LOD level. This runs in background thread. Stage 2 then takes this buffer and copy data into terrain's own structures(mHeightData, mDeltaData) thus it runs in main thread. After that CPU vertex data are created(stage 3) in background thread. Then finally GPU vertex data are created in main thread.
My Google summer of code 2011 topic: Terrain paging improvements
My Google summer of code thread
My Google summer of code wiki page
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: [GSoC 2011 - Accepted] Terrain paging improvements

Post by sinbad »

Excellent, that sounds perfect - nicely done :)
Nodrev
Gremlin
Posts: 193
Joined: Fri Jan 25, 2008 6:55 pm
Location: Nantes / France
x 17

Re: [GSoC 2011 - Accepted] Terrain paging improvements

Post by Nodrev »

Hey,

It seems that you had done some good work here, so I couldn't resist about try your fork.
But, as there is one "but", I cannot get it to work, cause my compilator crashes when i try!

Code: Select all

1>d:\programmation\lib\ogrenewterrain\components\terrain\src\ogreterrain.cpp(1443): fatal error C1001: Une erreur interne s'est produite dans le compilateur.
1>  (fichier du compilateur 'f:\dd\vctools\compiler\utc\src\p2\main.c[0x56DC18C0:0x00000004]', ligne 183)
1>   Pour résoudre ce problème, essayez de simplifier ou de modifier le programme à proximité des emplacements répertoriés ci-dessus.


In two words, it said that "an internal error occurs in the compilator" and "try to simplify or modify the code around the files listed before".
I assume that your are developping using a 64b environment, did you try to compile it on 32b (i'm using vs2010 express, I should try to compile it on ubuntu 32, but no time for now...)?
kuxv
Google Summer of Code Student
Google Summer of Code Student
Posts: 53
Joined: Wed Jan 09, 2008 7:51 pm
Location: Czech Republic
x 16

Re: [GSoC 2011 - Accepted] Terrain paging improvements

Post by kuxv »

Hi there. I'm doing my development under 32bit linux using gcc 4.4.5. In the error message there is mentioned line 1443 and if I'm correct that is where interpolation of heightfield data is done(Terrain::getHeightAtPointInterpolated). You can try to comment whole body of that function or just that line because it is not currently used. Let me know if that helps.
My Google summer of code 2011 topic: Terrain paging improvements
My Google summer of code thread
My Google summer of code wiki page
kuxv
Google Summer of Code Student
Google Summer of Code Student
Posts: 53
Joined: Wed Jan 09, 2008 7:51 pm
Location: Czech Republic
x 16

Re: [GSoC 2011 - Accepted] Terrain paging improvements

Post by kuxv »

I just started working on integration of separate LOD loading into paging component. I decided to create new paging strategy which will work with LOD levels instead of pages. So it will increase/decrease/hold LOD level(s) opposed to pages. For this I will add new TerrainLODPaging and TerrainLODPagedWorldSection which will load/unload LOD levels opposed to whole terrain(s) in TerrainPaging and TerrainPagedWorldSection. I'm going to use distance from camera from Terrain as metric for LOD level loading/unloading in similar way it is used in Terrain to find out what LOD level should be rendered. I could look as duplicity but I think decision of when should be specific LOD level loaded should be in separate place i.e. in Paging Strategy even if meaning of page is in this case LOD level. On the other hand it could happen that SceneManager would want to render Terrain's LOD level which is not loaded and thus it would crash or display holes in terrain. But this would be case of bad configuration of PageStrategy and Terrain's LOD Camera. I don't have much experience in this area what would be best approach so I wanted to ask people here what you think of this idea or what would you suggest here. Looking forward to hear your thoughts ;)
My Google summer of code 2011 topic: Terrain paging improvements
My Google summer of code thread
My Google summer of code wiki page
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: [GSoC 2011 - Accepted] Terrain paging improvements

Post by sinbad »

The original design for the paging system was that you could have different levels - the loading / holding / unloading of Page was the top-level, which was generalised and observable by anything that understood the paging system, regardless of the actual type of page. I still think this maps well to a single Terrain instance.

Now, there's nothing to say that within each Page, there isn't some other kind of dynamic loading going on which alters the internal content of that page more appropriately. Right now all that happens is that loadPage / unloadPage is implemented to map down to one slot of the TerrainGroup, but for example the loadPage part may only need to perform the 'prepare' step in your description above, after which the loading of the LOD is handled internally. So the abstract paging system is only there to trigger the loading or unloading of the outer container Terrain, and after that more detailed tracking of the camera can be done inside that to load LOD individually.

I basically designed it so that there was an overall concept of loading / unloading pages and a trigger system for that, but not to limit or make assumptions about what could be done within that. Now, this hasn't really been proven as a design yet, you're probably the first one to really put it to the test, so if you find it doesn't quite pan out as a design with the current implementation yet, feel free to add or change bits where necessary. But hopefully you can see the overall intention :)
Post Reply