David Megginson writes: > Erik Hofman writes: > > > If it would be 27Mb only, there wouldn't be a problem for me because > > FlightGear without dynamic objects leaves 39Mb spare memory. > > The problem seems to be that there are a lot of extra SSG nodes > attached to every tile in the cache (one ssgTransform and one ssgRange > for every dynamic object, whether currently visible or not). The > solution, I think, will involve using callbacks under the group LOD > node to manage things so that SSG nodes are created only when needed. > During a high-speed cross-country magic carpet ride, the memory usage > got as high as 180MB before stabilizing (vs. 80MB without > dynamically-placed objects).
David, Right now you have the individual object LOD node attached to the model so there is only one copy of it in memory. It might be interesting to make a per instance LOD node above each instance of the object so that we could vary the range for each instance of the object. This would allow us to see just a few of the random objects way out in the distance, but not too many to kill frame rates. <lunch passes> Ok, I think I have something working that I like: I moved the code that creates the object LOD node over to obj.cxx where the object is actually positioned. Now every instance of every 'random' object has it's own unique LOD node. The LOD range is calculated as range/(random(0,1)*range) + range. So if the specified object range was 2000m you would get a distribution that follows the form of 1/x. The minimum range would be 2000m, but a few would be much higher than that. The visual result is that you'd get a few objects way out in the distance and then others would fill in between more and more as you got closer in. It looks very similar to what you had originally but with a bit more variety and a few interesting objects in the distance, and there isn't a 'hard line' where all the objects pop in. You still see popping but it is maybe a slight fraction less noticable. I think this change makes the random objects look really good. Do you mind if I commit them (you can always back them out if you don't like them, or think of a better way do do this.) Regards, Curt. -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Cities [EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org _______________________________________________ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
