[GSoC 2011 - Accepted] Terrain paging improvements

Threads related to Google Summer of Code
User avatar
sinbad
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 19261
Joined: Sun Oct 06, 2002 11:19 pm
Location: Guernsey, Channel Islands
Contact:

Re: [GSoC 2011 - Accepted] Terrain paging improvements

Post by sinbad » Tue Jul 12, 2011 3:12 pm

And just to be clear on that - PageStrategy was really only there to deal with the 'outer' layer of paging, ie loading / unloading a Page (which can be applied to any type of paged content, and each may itself be a more complex container which does its own progressive loading). So don't feel that you need to make the LOD loading work within a PageStrategy, unless that turns out to make sense. It's OK to have an internal structure within the implementation of the terrain-specific page which deals with the LOD loading, because in practice that is specific to the nature of the terrain data, and not a generic concept.
0 x

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

Re: [GSoC 2011 - Accepted] Terrain paging improvements

Post by kuxv » Wed Jul 13, 2011 5:43 pm

I decided to move background loading from TerrainGroup to Terrain. So increaseLodLevel is located in Terrain as well. I implemented automatic LOD loading for terrain as well. It is currently just a function (updateLodByDistance) in Terrain Paging sample and it is driven by distance from QuadTree nodes(i.e. from specific LOD level). User can change holdDistance which specifies difference of distance from distance LOD level is actually changed and rendered. So if you set it to 1000 it means that next LOD level will start loading when LOD camera is 1000 units away from that LOD level. There is not unloading so far but that is going to be added really soon. There is also an issue when camera's position "jumps" i.e. if it goes big distance from one frame to another as some LOD level load can be missed. But sample is now quite functional and I'm now going to fix those issues...
0 x
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: 19261
Joined: Sun Oct 06, 2002 11:19 pm
Location: Guernsey, Channel Islands
Contact:

Re: [GSoC 2011 - Accepted] Terrain paging improvements

Post by sinbad » Wed Jul 13, 2011 5:50 pm

Great stuff, keep it up :)
0 x

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

Re: [GSoC 2011 - Accepted] Terrain paging improvements

Post by kuxv » Thu Jul 14, 2011 2:19 pm

Added mechanism for automatic LOD level loading. There is abstract class TerrainAutoUpdateLod with only one method

Code: Select all

void autoUpdateLod(Terrain *terrain, const String& filename, bool synchronous, const Any &data)
User creates implementation of it and passes it to Terrain via setAutoUpdateLod(). This then gets called by Terrain::autoUpdateLod(this,filename,synchronous,data).
autoUpdateLod() should call something like Terrain::increaseLodLevel() inside or anything else and actually takes care of LOD level load/unload. There is also similar functionality in TerrainGroup like autoUpdateLodAll() which just calls autoUpdateLod() on all terrains. In TerrainPaging sample automatic update is called in frameRenderingQueued to update all terrains. There is also one implementation of TerrainAutoUpdateLod called TerrainAutoUpdateLodByDistance which loads/unloads LOD levels based on distance from camera. It works now with many terrains and also does unloading as well as loading. Hope that makes sense ;)

It looks like everything is working now. There are some places where code needs some cleanup or little optimizations. I think I will leave this for now and move to Paging. It crashes now so I'm going to look at that. So after all I think I caught up with my schedule ;)
0 x
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

Re: [GSoC 2011 - Accepted] Terrain paging improvements

Post by kuxv » Thu Jul 14, 2011 4:57 pm

Paging now works with separate LOD loading ;)
0 x
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: 19261
Joined: Sun Oct 06, 2002 11:19 pm
Location: Guernsey, Channel Islands
Contact:

Re: [GSoC 2011 - Accepted] Terrain paging improvements

Post by sinbad » Thu Jul 14, 2011 5:18 pm

Dude, now I can't keep up! :D

I like how you've abstracted the decision on how the LOD should be updated into a strategy class (TerrainAutoUpdateLod), that could be useful later on. Do you think you might use a different implementation of that in editing tools for example, to make sure the data is available to modify?
0 x

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

Re: [GSoC 2011 - Accepted] Terrain paging improvements

Post by kuxv » Thu Jul 14, 2011 6:39 pm

Yes that sounds possible. I can imagine you add some parameter which would tell autoupdate function to load full detail instead of incremental load.
0 x
My Google summer of code 2011 topic: Terrain paging improvements
My Google summer of code thread
My Google summer of code wiki page

swq0553
Gnoblar
Posts: 1
Joined: Thu Jul 14, 2011 4:35 pm

Re: [GSoC 2011 - Accepted] Terrain paging improvements

Post by swq0553 » Sat Jul 16, 2011 1:42 pm

hello!
I want to know, if this component can be used to render earth? just like google earth!
thank you!
0 x

noorus
Halfling
Posts: 75
Joined: Wed Apr 20, 2011 9:55 pm
Location: Helsinki, Finland

Re: [GSoC 2011 - Accepted] Terrain paging improvements

Post by noorus » Sun Jul 17, 2011 9:45 pm

I just want to say that all the progress posted in this thread sounds great, and I really hope this project finishes well :)
As others have said already, I think to a lot of people this is the most important of the GSoC projects (not to bash any of the other GSoCs; terrain improvements just happen to be very relevant to a lot of projects.)

Our game project's paging considerations, and whole editor, are actually on a standstill while I wait for this project to finish 8)
Keep up the good work!
0 x

reptor
Ogre Magi
Posts: 1120
Joined: Wed Nov 15, 2006 7:41 pm
Location: Finland

Re: [GSoC 2011 - Accepted] Terrain paging improvements

Post by reptor » Mon Jul 18, 2011 9:45 pm

I agree that it's very important. Thank you for your work.
0 x

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

Re: [GSoC 2011 - Accepted] Terrain paging improvements

Post by kuxv » Mon Jul 25, 2011 11:44 am

@swq0553: You can render wast terrains using terrain paging components but you have to do preprocessing of terrain heightfield first. You need to create terrain.dat file from your image(or what you use as input). Then you can easily swap terrains in/out.

About progress I was just testing new functionality and I see little delay when paging is turned on. I suspect problem is with terrain's prepare() method. It reads in a lot of data IMHO(i.e. terrain textures like composite/lightmap/...). So I will try to make prepare() work in background as well. Can someone here tried this separate LOD loading with paging yet? Do you see tearing when terrain is paged in as well?

And thank you all for your support guys! ;)
0 x
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
sleo
Gremlin
Posts: 171
Joined: Sun Jun 05, 2011 6:49 am
Location: Vodka Federation

Re: [GSoC 2011 - Accepted] Terrain paging improvements

Post by sleo » Fri Jul 29, 2011 5:13 am

kuxv wrote:About progress I was just testing new functionality and I see little delay when paging is turned on. I suspect problem is with terrain's prepare() method. It reads in a lot of data IMHO(i.e. terrain textures like composite/lightmap/...). So I will try to make prepare() work in background as well. Can someone here tried this separate LOD loading with paging yet? Do you see tearing when terrain is paged in as well?
For me it is oblivious that prepare must be done in background thread. Also synchronization barrier is needed then player comes too near to a page (loadRadius of createWorldSection()), which will cause stall on slow computers (under minimum hardware requirements of a game). I think holdRadius should be considered as preloadRadius too. I'm using Ogre 1.7.3, so names comes from that version.

Do your terrain with LOD subloading supports loading from DeflateStream?
0 x

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

Re: [GSoC 2011 - Accepted] Terrain paging improvements

Post by kuxv » Fri Jul 29, 2011 11:09 am

I'm just working on moving prepare stage into background thread as well. I want it to read all data into temp buffers and then just copy them to terrain class. That should eliminate any stalls. But I spent a lot of time testing performance of terrain's separate LOD loading together with paging. It seems to me that it is actually little slower then old implementation and that is not acceptable. I need to postpone implementation of new paging strategy until I find out what is the problem with terrain load speed as that is more important. I think that new paging strategy is not really needed as much as fluent background loading. But if you prove me I'm wrong I would reconsider that.
Do your terrain with LOD subloading supports loading from DeflateStream?
Not yet, but that is definitely on my todo list.
0 x
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
Wolfmanfx
OGRE Team Member
OGRE Team Member
Posts: 1525
Joined: Fri Feb 03, 2006 10:37 pm
Location: Austria - Leoben
x 1
Contact:

Re: [GSoC 2011 - Accepted] Terrain paging improvements

Post by Wolfmanfx » Fri Jul 29, 2011 11:27 am

If you have an windows machine (there is also an linux version but i just used the windows version) you could use the trial version of http://software.intel.com/en-us/article ... udio-home/ to profile the performance and detect the bottelnecks.
0 x

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

Re: [GSoC 2011 - Accepted] Terrain paging improvements

Post by kuxv » Mon Aug 01, 2011 2:07 pm

I have some news about my progress on terrain load speed. I did some timing of the code and here are the results:

16ms .. Terrain::prepare()
4ms ... Terrain::readLodData()
1ms ... Terrain::fillLodData()
1ms ... Terrain::createCpuData()
8ms ... Terrain::checkLayers()
5ms ... Terrain::createOrDestroyGPUNormalMap()
4ms ... Terrain::createOrDestroyGPUCompositeMap()
6ms ... Terrain::createGpuData()

Biggest part is taken by prepare() method but that is not a problem here as it could be called any time prior terrain's load.
readLodData() and createCpuData() runs in background thread so that is not an issue as well.
I figured out that biggest problem here is(not surprisingly) CPU->GPU data transfer. Blend/normal/composite maps takes a lot of time to copy into GPU. It takes a lot of time compared to heightmap CPU->GPU copy. So what could be solution here? With multithreading in mind I don't see any as I can't copy into GPU memory in background thread WITHOUT using locks and so GPU data can't be created faster. I have to say I'm not very skilled in this area so maybe there is some common solution for this problem but I didn't find anything about it. Well I guess texture streaming could help here but I don't know if that is a topic I can handle in rest of my time on the project.

I had an idea about creating whole terrain invisible and when loading is finished make it visible again. But for that I would have to use locks and so code would probably have stalls anyway so that is not a solution imho.

So I will now polish and clean up separate LOD loading code and implement new paging strategy. That is my plan because I spent a lot of time trying to find out what could be the problem and now I really think there is no any other solution. But if we can find out any other solution here I would be more than happy to try it out.
0 x
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: 19261
Joined: Sun Oct 06, 2002 11:19 pm
Location: Guernsey, Channel Islands
Contact:

Re: [GSoC 2011 - Accepted] Terrain paging improvements

Post by sinbad » Wed Aug 10, 2011 1:39 am

Firstly, sorry for the delay in catching up with this thread. I'm supposed to be subscribed to it but I haven't had any emails in a couple of weeks :(
kuxv wrote: I suspect problem is with terrain's prepare() method. It reads in a lot of data IMHO(i.e. terrain textures like composite/lightmap/...). So I will try to make prepare() work in background as well.
'prepare' has always been intended to be moved to the background - that's actually the whole point of it existing separately to 'load', and it's an idiom that's present in the resource system too. It's also why prepare() can only operate on CPU resources. I'm not actually sure why it never got moved to the background :? Good catch. I also agree with sleo that compression on the stream will help with the read performance - I remember you turned that off to remove the complexity of finding the various LOD sections but it might be worth turning it back on sometime, perhaps compressing only the individual LOD chunks rather than the whole stream or something. But that's for later.

As for your problems with the GPU resources and the stall there, a few thoughts:
  1. Creation / destruction of resources. To deal with that, pre-create a pool of GPU resources, and re-use them instead of creating them on demand and destroying them when you're done. This already happens in the terrain system for the vertex and index data, you can see this inside TerrainQuadTreeNode where it calls the Terrain::GpuBufferAllocator to get the index and vertex buffers it needs. These are pooled based on the fact that there will only ever be a certain number of variations, and that they will be needed temporarily depending on the LOD levels that are active. You could do the same thing with the textures, which are currently created & destroyed on demand - so create something similar to Terrain::GpuBufferAllocator like Terrain::TextureAllocator and have a pool of textures of a given size / format which are re-used across the terrain instances.
  2. Pipeline stalls on CPU->GPU copy. Because the GPU is actually rendering results a frame or three behind the commands that you're feeding in to it, it's possible to stall the pipeline and make it flush by requesting a sync point between them. Usually this happens when you try to read back from the GPU, because the results may not be up to date, but CPU->GPU is usually OK - what the driver will usually do is copy the data into a staging area in its own memory (so that the CPU code can continue and doesn't have to worry about deallocating / changing its own copy) and schedule the copy of the data to the actual GPU resource in the pipeline with all the other commands (it couldn't do it straight away anyway because there may be unprocessed commands in the pipe already which are supposed to run in the context of the GPU resource's previous state). So, everything should just be queued and should not stall if this happens. The only case where it would stall is if you then tried to copy the data back to the CPU, which I don't think happens?
  3. Transfer bottleneck. Lastly, maybe you're hitting the limit of how much data can be transferred through the bus. Everything has to share this bus, so maybe even if there isn't a stall, there is a 'spike' in the amount of bus activity at a particular point in the pipeline because all the textures are trying to upload at once in one frame, and this is enough to clog things up noticeably. To resolve this, you could spread the upload over multiple frames (say doing only one texture at a time, then waiting for the next frame event and requesting the next one etc until all are done), and only treat the terrain as loaded once everything has finished. This is in general a good approach when dealing with streaming - simply partitioning up the GPU work into multiple bits and doing it in stages means that it's spread out in the GPU pipeline and less likely to cause a spike, although of course it means you're finished a few frames later than you would otherwise have been.
Always remember that CPU timings don't tell you the whole story, because the GPU is running on a completely separate timeline. This is where tools like nvPerfHUD and gDEBugger come in, but I'm not sure what options you have on Linux...

I hope that helps a bit!
0 x

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

Re: [GSoC 2011 - Accepted] Terrain paging improvements

Post by kuxv » Wed Aug 10, 2011 9:47 pm

Nice see you ;)

I also had a problem with subscription to this thread at the beginning but now it is ok. Maybe some bug ;)

So I just did some more tests and the biggest problem are the terrain textures as it takes relatively long time to load them at the beginning. So I'm going to try some shared texture allocator as you suggested. My only thought is about it's usefulness as I'm not sure if people use same texture for all terrain patches at all. But I guess it is worth a try.
It's also why prepare() can only operate on CPU resources. I'm not actually sure why it never got moved to the background.
The thing here is that it is actually run in background. So no problem with that ;) It just needs to be called more earlier than it is now as sleo suggested. I'm going to add some preload function to paging strategy or maybe some other abstraction so users can add some stages to paging like preload/load/postload etc...
The only case where it would stall is if you then tried to copy the data back to the CPU, which I don't think happens?
Nope, there is not any GPU memory readback or whatsoever.
Transfer bottleneck
That could be. Will investigate and report my results.

Ok so I'm going to give loading mechanism another try and thus postponing new paging strategy. Your post was very informative for me and game me new ways to consider. I'm now much more confident about success of this project. See you soon.
0 x
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: 19261
Joined: Sun Oct 06, 2002 11:19 pm
Location: Guernsey, Channel Islands
Contact:

Re: [GSoC 2011 - Accepted] Terrain paging improvements

Post by sinbad » Thu Aug 11, 2011 12:30 am

kuxv wrote: So I just did some more tests and the biggest problem are the terrain textures as it takes relatively long time to load them at the beginning. So I'm going to try some shared texture allocator as you suggested. My only thought is about it's usefulness as I'm not sure if people use same texture for all terrain patches at all. But I guess it is worth a try.
Sorry, I meant that you'd use the pool of texture resources, not that they would have the same content. For example the vertex / index buffer pool that is used already is not re-using the same content, just the buffer space. Because it's likely that the size / format of the buffers needed has lots of overlap between sections of the terrain, it doesn't make sense to create / destroy them all the time, but to put the buffer back in a pool when you're done and pull it out again to fill it with other content later.

You can do the same with the textures, so instead of loading textures directly, create a texture with a given size / format and fill it with data via blitting, then when you're finished with it, put it back in the pool for someone else to use. It does mean that there needs to be an indirection between the name of the texture that is required for the content, and the actual texture resource which is actually holding that right now, which adds some complexity to the material setup. But it does put you in far more control of the resource creation / update process.
0 x

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

Re: [GSoC 2011 - Accepted] Terrain paging improvements

Post by kuxv » Thu Aug 11, 2011 7:35 pm

Oh yes that make sense. It actually came to my mind after I posted the reply ;)
0 x
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

Re: [GSoC 2011 - Accepted] Terrain paging improvements

Post by kuxv » Mon Aug 15, 2011 10:45 am

I finished TextureAllocator for terrain which takes new texture from resource pool of previously allocated textures instead of creating new one every time it is needed. I see difference in speed of paging when it is used. I'm much more satisfied with it now ;) I made terrain group to use it in same way as GpuBufferAllocator works. Today I hope I finish prepare stage in TerrainPaging. When that is done only thing that is left is to allow compression of terrain.dat files again which should take maybe 1 day. After that I want to improve TerrainPaging sample and write documentation and guess I'm done. I know there was new paging strategy planned as well but as I said I think that is really not an issue here and so I'm going to skip that part of my project. If you guys come up with any good reason for it I can continue to work on that after deadline.
0 x
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: 19261
Joined: Sun Oct 06, 2002 11:19 pm
Location: Guernsey, Channel Islands
Contact:

Re: [GSoC 2011 - Accepted] Terrain paging improvements

Post by sinbad » Mon Aug 15, 2011 11:11 am

Great to hear. The core objective of the project is to make the terrain paging smoother and therefore usable in real projects - if that means you needed to spend your time on other things (like the TextureAllocator) to achieve that rather than the detailed items you originally had in mind at the start, that's fine - that's what happens in projects all the time of course :)

I'm sure everyone would love you to carry on after the summer if you're willing. You'll also be able to recruit direct help from others if you want too once the Summer of Code is over - it's a solo effort during the programme but after that anyone can join in, and it can become a more traditional collaborative part of the project. After the summer, provided everything goes well, your fork can be re-integrated into the main project.
0 x

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

Re: [GSoC 2011 - Accepted] Terrain paging improvements

Post by kuxv » Mon Aug 22, 2011 4:45 pm

Hello. I pushed in another some more changes. Probably most important would be geometry data compression in terrain.dat file. The dat file is not compressed in as a whole now but just height and delta data are. I also moved them to separate chunks for easier seeking. Geometry data are now also saved in different format. It is not saved as plain mHeightData i.e. SIZE*SIZE. Now every LOD level is stored separately. Thanks to that it is easier to seek in file for specific LOD data and it is possible to read whole LOD level as a continuous memory(well file fragmentation can take this down). LOD levels are saved from lowest LOD level to highest LOD level and only difference from previous one is saved so no data duplication is present. Maybe to make it really clear you can look at this:

Code: Select all

Before:
01 02 03 04 05
06 07 08 09 10
11 12 13 14 15
16 17 18 19 20
21 22 23 24 25

Now:
01 05 21 25
03 11 13 15 23
02 04 06 07 08 09 10 12 14 16 17 18 19 20 22 24
Another change probably most visible one is at Terrain Paging sample. I added LOD level status information display for each terrain. It shows what LOD level user wants to be loaded, what highest LOD level is actually loaded and what LOD level is stored in memory. There is also possibility to hide this info. You can also switch on/off automatic LOD level loading/unloading. If it is disabled you can use Page Up/Page Down to increase/decrease LOD level of terrain at central coordinates(0,0). When you compile it with

Code: Select all

#define PAGING
you can see paging in action but don't forget to set count of pages first. That is the same as in sinbad's Terrain sample.

I added quite a few comments to make thinks more clear. Hopefully enough but I don't think there is such a think as a lot of comments really ;)

So as it is deadline of GSoC today I want to say I think I didn't manage to deliver all the things from my initial proposal but I hope I managed to deliver core feature: separate LOD level loading. I want and will continue on improving it and (maybe) fixing it as well ;) In next few days I would like to add compression of textures and other data in dat file for beginning. I'm going to update wiki now.

And last but not least ;) I would like to give BIG THANK YOU to my mentor sinbad for aaaaaaall his valuable advices and share of his insightul knowledge of Ogre internals. I couldn't do what I did without those really. Thanks go to all you guys here who participated in this discussion as well.
0 x
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: 19261
Joined: Sun Oct 06, 2002 11:19 pm
Location: Guernsey, Channel Islands
Contact:

Re: [GSoC 2011 - Accepted] Terrain paging improvements

Post by sinbad » Mon Aug 22, 2011 5:44 pm

Awesome, good job. I'm planning on taking a proper look in a day or two, sorry for any delay. But what you've described here sounds bang-on, and looking through your commits just quickly, it's looking good. The compression approach you describe sounds exactly what was needed, with each LOD being separately loadable and compressed within itself.

What performance results did you get in the end? It's OK if you didn't quite get it as smooth as you wanted, these things do tend to take a while of refinement, but hopefully if you compare the old implementation (in the default branch of the original repository) and your new implementation, you can see a noticeable difference?

Although it's 'pencils down' for the code, it would be great if you could update your wiki page with a summary of what you did, and what your results are, just to put a 'stake in the ground' at the end of the summer. It's nice to look back on too :)
0 x

User avatar
sinbad
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 19261
Joined: Sun Oct 06, 2002 11:19 pm
Location: Guernsey, Channel Islands
Contact:

Re: [GSoC 2011 - Accepted] Terrain paging improvements

Post by sinbad » Wed Aug 24, 2011 12:38 pm

Hmm, I seem to be having a problem with loading the LODs. I've deleted all my old data and run the new paging demo once, which calculates everything and renders correctly, saving the data in the usual .dat file.

When I run the demo again so that it picks up the .dat file, I get this:
ogrenewterrainproblem.jpg
Terrain problem
No matter where I fly in the terrain, it all looks the same, and none of the LOD data changes (either in the terrain render or the debug display).

Any ideas? It looks like sparsely populated data with only every nth vertex being loaded correctly or similar, although since the display never changes it seems like the LOD loading isn't working either.
0 x

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

Re: [GSoC 2011 - Accepted] Terrain paging improvements

Post by kuxv » Wed Aug 24, 2011 12:49 pm

I think what you see now is correct behavior. New LODs are not loaded because you don't have "Auto LOD" turned on. That is what makes "automatic" LOD load/unload. If you have it turned off you can use manual LOD load method using Page Up/Page Down to increase/decrease LOD. I'm working on wiki update to make it crystal clear. So just try to turn "Auto LOD" on or use Page Up to increase LOD level. That should work.
0 x
My Google summer of code 2011 topic: Terrain paging improvements
My Google summer of code thread
My Google summer of code wiki page

Post Reply