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

Reply via email to