On Fri, Jul 29, 2011 at 6:21 PM, ThorstenB wrote:
> 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.
Good to know.
However, I don't think my change will have affected this.
While the number of trees displayed is increased, the total number
of trees in the scenery is unaffected, it's just that more of those
trees are visible at any given time.
I'm also not sure if the tree model is shared in this way. It's not
really a model
in the .ac sense anyway.