On 28.07.2011 00:30, Stuart Buchanan wrote: > On my machine I don't see any performance impact, despite the fact > that more trees are displayed. I'd appreciate it if those with more > graphics-constrained systems than my own would test this and let me > know if they think the frame-rate hit is acceptable given the > improvements in apparent tree coverage.
Not sure if trees were also affected, but I remember a very ugly issue from last year. OSG is quick in sharing a single object multiple times into the a scenery ( O(1) ), but removing such a shared object is very expensive. OSG uses a single thread for loading and removing. Dropping a scenery area with an object shared a few thousand times only took a fraction of a second. But when the number of shares increased even further, then suddenly the OSG "database" thread blocked for minutes - while no new scenery could be loaded. O(n^2) bites you eventually. That's why we reduced or got rid of cattle, horse, ... objects scattered across the scenery. I'm not sure if increasing the tree count could trigger the same problem. And no idea if OSG3 has improved on this issue. The problem is only observed after the tile cache is full, so scenery tiles need to be dropped from memory for the first time. A good way for testing is to take the UFO and race at maximum speed across the scenery. Make sure scenery tiles keep continually loading and appearing at the same speed - so that even after a few minutes of flying, loading doesn't get blocked and you're flying into the void. cheers, Thorsten ------------------------------------------------------------------------------ Got Input? Slashdot Needs You. Take our quick survey online. Come on, we don't ask for help often. Plus, you'll get a chance to win $100 to spend on ThinkGeek. http://p.sf.net/sfu/slashdot-survey _______________________________________________ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel