PagedLOD: Difference between revisions
No edit summary |
m (merge) |
||
Line 1: | Line 1: | ||
{{Mergeto|Scenery LoD}} | |||
{{Stub}} | {{Stub}} | ||
{{Main article|Scenery LoD}} | {{Main article|Scenery LoD}} | ||
Revision as of 07:37, 21 May 2020
This article is a stub. You can help the wiki by expanding it. |
See Scenery LoD for the main article about this subject. |
Rendering |
---|
Rendering Pipeline |
Effects and Shaders |
Ongoing Efforts |
Standalone Tools |
IPC/Networking |
Multicore |
---|
Configuration |
Ongoing Efforts |
Proposals & RFCs |
Background |
For developers |
PagedLOD is an enhanced LOD node supported by OpenSceneGraph. The conventional LOD node requires all of its immediate children be present in memory at-once (a requirement inherited from osg::Group
). For scenegraphs with large numbers of LODs, this can become prohibitively costly in terms of memory consumption, even though only one LOD child of each LOD Node is being drawn at any one time.
The answer to this predicament is the PagedLOD node. PagedLOD is derived from LOD, and adds the ability to defer the loading of child nodes until they are actually required. A PagedLOD node may have a child immediately present, or it may not have the child present, instead storing a path/name where the child node can be loaded from on-demand [1].
We’re now using PagedLOD for sub-elemts of the tile, including objects, random veg+buildings, and maybe lights too. This is a big win since base tile loading is faster and we don’t pay the memory cost until the relevant stuff is in view. (And, it can be paged out again)[1]
we use PageLoD nodes and the OSG paged loader to determine what stays in memory. Models are loaded in a separate thread, and then added to the scenegraph. In theory this should mean there is no impact due to model loading from disk. However, even though the model is loaded, mipmaps haven't been generated for all the textures at this point - this only happens when the texture is loaded into the graphics card memory. In theory, this mipmap creation should be handled by the graphics card itself, but it looks like there's a driver bug which means this is falling back to the CPU to perform, and causing additional work in the main thread. Additionally, there are OSG limits on the number of PagedLOD nodes that will be kept in memory at any one time.So, even after the model has been loaded, it may nevertheless end up paged to disk if it goes out of view. IIRC Matthias mentioned a number around 300. The workaround for the first problem is to manually generate the mipmaps for textures in the model loader thread, and indicate to the GPU that it doesn't need to generate mipmaps itself. This is something I plan to look into when I have the opportunity, though I'll need to ask for patience as it's outside my current expertise.[2]
References |
Background
one of the problems is that most of our objects have no concept of different LOD's. If we had objects with say 3 LOD, it would ease memory and — Adrian Musceac (2013-09-20). Re: [Flightgear-devel] Upcoming Random Buildings changes.
(powered by Instant-Cquotes) |
’ve checked with Mathias, and his alternate paging scheme (replaces the tile manager, using osgDB pager / pagedLODs for everything) is certainly a viable option here. It supports using a blue-marble style image as a base level of detail (think SGOceanTile, but with vertex colours at least showing land-cover), and he has support for coarse detail tiles too. ‘All’ that’s missing is generating some suitable tiles for this medium-level scheme, which I think is all work on TerraGear side.
— James Turner (2014-02-24). Re: [Flightgear-devel] Terrain Simplifier.
(powered by Instant-Cquotes) |
Tweaking
’ve added some optional features to reduce memory consumption, and since ‘next’ is for testing, I’ve switched them both on by default in current Git. They are:
Previous was effectively ‘true’, the default on next right now is ‘false’, so the tile cache is disabled. This leads to some visible popping when switching between tower and cockpit views, but otherwise I can’t see any problem with disabling the cache - and it saves an enormous amount of memory. Unless testing reveals any problem, I’d propose to make this default to ‘false’ for 3.2.0 too.
This exposes an OSG value, which we previously did not adjust. This is how many PagedLODs to keep around, even when they are inactive (outside the current view, in practice). This controls how quickly we unload Paged elements of tiles - trees & random buildings principally. The default value of 300 means we’re keeping many PagedLODs for tiles outside the view, so this has been lowered on next to 8. Some tuning of this value is welcomed, whether 0, 8, 16 or 32 make any appreciable difference to popping or memory consumption. I can imagine setting it to zero leading to more visible popping of trees & buildings when flying circuits around an airfield - that’s the motivation for the current value. — James Turner (2014-05-18). [Flightgear-devel] Memory consumption reduction.
(powered by Instant-Cquotes) |
If you comment out the new entries in prefrences.xml, the C++ code will use the old values (cache enabled, max-paged-lod=300) automatically.
Of course, the mose important test is if this makes the 2.0 scenery usable on 32-bit machines. I can’t perform that test, so hopefully some other people here can. — James Turner (2014-05-18). [Flightgear-devel] Memory consumption reduction.
(powered by Instant-Cquotes) |
LOD Bias
for fly by view, the new scheme will cause way more unloading and re-loading, which is wasteful - equally your old ‘spin around to trigger loading’ trick is a programmer level hack that a normal user would be mystified by.
— James Turner (2014-11-04). Re: [Flightgear-devel] Building of framerate doom.
(powered by Instant-Cquotes) |
The other LOD setting I keep debating about, is the ‘lod-bias’ feature the OSG pager has. This can be used to bias the LOD metrics arbitrarily, and in particular based on frame-rate. It would need a PID controller to drive it I think (but we have the code for one of those!), but the idea would be to bias LOD to achieve a target frame-rate; effectively ‘stuff’ which uses the OSG pager system (random building/trees, scenery models) would be unloaded if frame-rate dropped.
— James Turner (2014-11-19). Re: [Flightgear-devel] Improved LOD handling for AI Models.
(powered by Instant-Cquotes) |
I haven’t even made the experiments around this, but conceptually it feels nice to me - I’d much rather the system unload buildings/models to maintain a target 30fps. It would work even better with a ‘bare’ / ‘detailed’ BTG scheme of course, since we’d revert distant tiles to the bare version automatically.
— James Turner (2014-11-19). Re: [Flightgear-devel] Improved LOD handling for AI Models.
(powered by Instant-Cquotes) |
FGViewer
I have in fgviewer a PagedLOD whole world database tree running. This is similar to osg's marble — Mathias Fröhlich (2012-07-21). Re: [Flightgear-devel] Rendering passes question.
(powered by Instant-Cquotes) |
AI Traffic
I was not aware that we limit the OSG default of 300 to only 16 paged LODs. Given our usages of PLODs, this number is way to low. — Torsten Dreyer (2015-06-08). Re: [Flightgear-devel] max-paged-lod too low?.
(powered by Instant-Cquotes) |
64 seems OK for AI disabled but for AI enabled it's still too low. — Torsten Dreyer (2015-06-15). Re: [Flightgear-devel] max-paged-lod too low?.
(powered by Instant-Cquotes) |
aircraft disappearing from view but still being present in the pilot list may be due to OSG paging out the aircraft too aggressively.
Try increasing — Stuart Buchanan (2015-06-16). Re: [Flightgear-devel] The 707 on the multiplayer servers.
(powered by Instant-Cquotes) |
All AI models are now PagedLOD nodes, instead of plain LOD nodes, precisely so they can be unloaded.
— James Turner (2014-11-04). Re: [Flightgear-devel] Building of framerate doom.
(powered by Instant-Cquotes) |
Our AI Models are handled by so called PagedLOD nodes in OSG. These nodes get loaded and deleted on OSG's descretion. I have just added a — Torsten Dreyer (2014-11-19). [Flightgear-devel] Improved LOD handling for AI Models.
(powered by Instant-Cquotes) |
Random Buildings
t would really help memory use if we could defer tree/object/building generation until the tile is close to the viewer. Right now you generate lots of LOD nodes so we don't pay the rendering cost for distant tiles, but we're still paying a memory cost and loading time hit.
— James Turner (2013-09-18). Re: [Flightgear-devel] Upcoming Random Buildings changes.
(powered by Instant-Cquotes) |
Random objects are not generated when the tile is loaded. Instead they are deferred and loaded by a PagedLOD call when you get within ~ 15km of the — Stuart Buchanan (2014-11-22). Re: [Flightgear-devel] Building of framerate doom.
(powered by Instant-Cquotes) |
With the PagedLOD approach the random objects will be generated only when the aircraft gets into range, so I'm hoping I can simply check against — Stuart Buchanan (2013-10-11). Re: [Flightgear-devel] Upcoming Random Buildings changes.
(powered by Instant-Cquotes) |
I've been working on using PagedLoD to deferred random object (buildings, trees, objects) so that they are — Stuart Buchanan (2013-12-06). [Flightgear-devel] Deferred/Paged random object loading.
(powered by Instant-Cquotes) |
The ReaderWriters run in the osgDB pager thread, which is exactly where the current ReaderWriterSTG runs (which ultimately does the current tree/object/building placement, I think) - so the threading should not change at all. Indeed, the more I think on it, the more it feels like this should be a very small restructuring of the code, just requiring some slightly delicate PagedLOD plumbing to make it work. We're already doing the right work (building an osg::Node) and doing it in the right thread, we just need to change *when* we do it.
— James Turner (2013-09-18). Re: [Flightgear-devel] Upcoming Random Buildings changes.
(powered by Instant-Cquotes) |
- ↑ James Turner (Jan 19th, 2014). Re: [Flightgear-devel] segfault SGMaterialLib .
- ↑ Stuart Buchanan (Nov 5th, 2014). Re: [Flightgear-devel] Building of framerate doom .