On Thu, Aug 9, 2012 at 10:46 AM, Stuart Buchanan wrote: > For performance reasons, all the buildings within a tile are a single > object. 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.
I've (finally) 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. My 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. I've not noticed any frame-rate impact. There's still quite a lot of work to do, but I hope to have this available before the next release. -Stuart ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
