20,741
edits
FlightGear Newsletter September 2012: Difference between revisions
Jump to navigation
Jump to search
m
FlightGear Newsletter September 2012 (view source)
Revision as of 18:59, 10 September 2012
, 10 September 2012→Random Buildings: copy/edit based on: http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg38219.html
m (→Scenery corner) |
m (→Random Buildings: copy/edit based on: http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg38219.html) |
||
| Line 7: | Line 7: | ||
Note to all contributors: Please also copy your newsletter additions to the changelog of the upcoming release: [[Changelog_3.0.0]]. | Note to all contributors: Please also copy your newsletter additions to the changelog of the upcoming release: [[Changelog_3.0.0]]. | ||
<!-- These are currently just a bunch of placeholders for the latest projects (as of 08/2012) --> | |||
=== Random Buildings === | === Random Buildings === | ||
Shortly after the 2.8 release, a number of users reported severe memory growth issues related to a new feature: [[Random Buildings]]. | |||
Unfortunately, the buildings are generated when the tiles are loaded, and it is this that causes the memory occupancy problems rather than visibility itself (subject to big view ranges causing the loading of more tiles). Aggressively limiting the maximum available visibility range might help, if it's causing more tiles to be loaded, but it is very dependent on the amount of Urban and Town terrain. | |||
For performance reasons, all the buildings within a tile are a single object currently. The memory capacity could be addressed by changing the implementation to something closer to the trees, where a (relatively) small number of buildings are instantiated at different locations. I don't know what this would do for performance though. | |||
Stuart has now managed to get a prototype running using an instantiation of a shared geometry rather than a huge single object per tile. | |||
So far the results are promising. Stuart's standard test is at KSFO with the c172p, waiting until the intial set of tiles is loaded with standard weather conditions (e.g. no excessive visibility). With random buildings switched off FG uses ~1GB memory. With v2.8.0 | |||
random buildings, it's 2GB. With instantiated buildings at present it is 1.5GB. | |||
At KLAX, it's down even further, from 2.7GB to 1.6GB. So far, without any frame-rate impact. | |||
There's still quite a lot of work to do, but Stuart hopes to have this available before the next release. | |||
=== Project Rembrandt === | === Project Rembrandt === | ||