Re: [Flightgear-devel] Randomly-placed objects, take 2
David Megginson wrote: I've just checked in a major revision to my new randomly-placed object code: it cuts down the memory usage a fair bit and eliminates long pauses when complex tiles fall out of the cache. There are still some stutters at very high speeds (i.e. 3000kt), but at normal speeds, all seems smooth now. Yep, it settles down at about 32 Mb free memory compared to about 39 Mb free memory without the dynamic objects. Good work! The basic principle is that I add only a placeholder to the scene graph for the objects in each triangle. When it falls into range, a callback creates the objects, and when it falls out of range, another callback frees them again. That way, we have objects added only to triangles that are close to the plane, and there is no need to free hundreds or thousands of objects at once when a tile falls off the cache. I also modified the material code so that an object and its texture are loaded only once, no matter how many materials use it. Marvellous, I already wondered about this. According to some quick tests, with randomly-placed objects disabled, FlightGear uses 214MB of which 79MB are RSS; with randomly-placed objects enabled, FlightGear uses about 237MB of which 102MB are RSS. That's a bit of a blow-up, but not nearly as bad as it was, and after a while the memory usage stops increasing and sometimes actually falls a bit. Please everyone give this a brutal workout to find any further problems. To enable randomly-placed objects, use fgfs --prop:/sim/rendering/dynamic-objects=true Hmm framerates dropped fro 6~7 fps to 1~2 fps. I realy think the O2 graphics options isn;t suitable enough for FlightGear anymore :-( When I started FlightGear about 4(?) years ago I still had 18 fps ... Anyway, fancy options are likely to drop framerates anyhow. Thankfully they can be disabled. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Randomly-placed objects, take 2
Curtis L. Olson writes: Here's what I get sitting still at the default location, no panel or hud, with a GeForce2Go, 32MB, 800x600x32, with the latest Linux drivers (I'm using the latest plib CVS, but I assume you are as well): no dynamic objects: ~40fps dynamic objects (latest code): ~34fps dynamic objects (old code): ~32fps My frame rate trends typically are more in line with yours. However, with the latest cvs code, default startup aiport, no hud, no panel, I'm seeing: dynamic objects (latest code): ~23-24fps no dynamic objects (latest code): ~75fps So I am seeing a huge difference with dynamic objects on vs. off. Trying fresh this morning, I can see a bigger difference, though not so big as yours. For consistency, I'm using the following command line (substituting false where appropriate): fgfs --start-date-gmt=2002:07:18:20:00:00 --disable-panel --prop:/sim/rendering/dynamic-objects=true As soon as FlightGear starts, I hit Shift-B to hold the plane in place. dynamic objects: ~28fps no dynamic objects: ~41fps Note that the plane is not moving, so the new object loading/unloading code should have little effect after the first couple of seconds. I have a couple of hypotheses: 1. Removing per-object LOD tests and using only per-triangle LOD tests has hit us harder than expected, possibly because of some large triangles. 2. Bypassing culling for empty object branches is more expensive than expected. I'm going to experiment with #1 first, since it's simpler to change. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Randomly-placed objects, take 2
Norman Vine writes: eg. When starting up over the open ocean where all the tiles are 'generated' I get ~375fps reported with 800x600x32 when looking straight down.What do you get ? I get only ~64fps on my notebook LCD. What puzzles me, though, is why you'd get lower absolute framerates than me in some circumstances, i.e. 17fps against my 28fps. I am finding this quite bewildering ?? When you're moving, you pay the cost of clearing and populating triangles, but when you're sitting still, that should not be a significant factor. I have a couple of hunches: 1. As an experiment, I eliminated individual ssgRangeSelectors for objects to speed up calculations, and simply put on ssgRangeSelector for all objects of each type in each triangle. Very large triangles might be coming up and biting us. 2. I used callbacks to prevent empty object branches from being culled. Perhaps a placeholder with a dummy bounding sphere would be better, since we'd still get FOV culling, but this will need more work. As I mentioned in my last posting, I'm going to experiment with #1 now. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Randomly-placed objects, take 2
Erik Hofman writes: Anyway, fancy options are likely to drop framerates anyhow. Thankfully they can be disabled. Yes. Some day we may decide to make this the default, but it should always be possible to turn it off. It would be even better if we could choose a default based on the card time, so that first-time users with powerful cards get the extra stuff while first-time users with older cards get OK framerates. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Randomly-placed objects, take 2
David Megginson writes: 1. As an experiment, I eliminated individual ssgRangeSelectors for objects to speed up calculations, and simply put on ssgRangeSelector for all objects of each type in each triangle. Very large triangles might be coming up and biting us. Nope, that's not it. There was no measurable framerate difference using individual ssgRange selectors for each object. However, if I used the group LOD for the triangle and individual LOD for each object, my framerate halved, so back to individual LOD for the triangle and nothing for each object. 2. I used callbacks to prevent empty object branches from being culled. Perhaps a placeholder with a dummy bounding sphere would be better, since we'd still get FOV culling, but this will need more work. I'll look more closely at this one. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Randomly-placed objects, take 2
David Megginson wrote: Norman Vine wrote: Win2k PIII 733 256meg Geforce2 GTS 32 meg Latest certified WQL GFX drivers from NVIDIA at default startup location no HUD no Panel Latest changes~17fps your original code~32 fps no dynamic objects ~75fps Here's what I get sitting still at the default location, no panel or hud, with a GeForce2Go, 32MB, 800x600x32, with the latest Linux drivers (I'm using the latest plib CVS, but I assume you are as well): no dynamic objects: ~40fps dynamic objects (latest code): ~34fps dynamic objects (old code): ~32fps I actually see numbers that are more in line with Norman's (Athlon 1800XP, Geforce 3 Ti200, 1280x1024 32bpp, current code as of last night): the ~70 fps I see without dynamic scenery at startup at SFO drops to 40 or so when I turn the dynamic object on. This effect isn't severe, but it's enough to be worrisom. Certainly the dynamic scenery is taking up a significant chunk of the current render time, which makes it a good candidate for optimization. This is something that I think we need to look at more generally: right now, FlightGear is making rather poor use of the graphics hardware on fast cards. There was a thread on plib recently that showed that the current tile renderer is rendering lots of tiny ssgLeafs instead of a single large buffer. This tickles a bad code path through ssg, which wants to render each ~10 vertex leaf from a separate vertex array (drivers don't optimize this case well -- the fix being discussed was to use plain old glVertex (!) calls, which turn out to be faster for such small objects). Almost everything we render (other than the cockpit and model animations) is static geometry. In principle, we should be able to ship this off to the card in a big chunk. In practice, though, we end up no better than 1990-era code, which sent each vertex across the bus in a separate transaction. As we start adding geometric complexity to the scene, we really should look hard about how it's done. I see some support in plib for using display lists, although it looks like it's #ifdef'd out. Andy -- Andrew J. RossNextBus Information Systems Senior Software Engineer Emeryville, CA [EMAIL PROTECTED] http://www.nextbus.com Men go crazy in conflagrations. They only get better one by one. - Sting (misquoted) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Randomly-placed objects, take 2
Andy Ross writes: I actually see numbers that are more in line with Norman's (Athlon 1800XP, Geforce 3 Ti200, 1280x1024 32bpp, current code as of last night): the ~70 fps I see without dynamic scenery at startup at SFO drops to 40 or so when I turn the dynamic object on. I think it's fixed in today's CVS. Give it a spin when you get home from work, and let me know what you find. Almost everything we render (other than the cockpit and model animations) is static geometry. In principle, we should be able to ship this off to the card in a big chunk. In practice, though, we end up no better than 1990-era code, which sent each vertex across the bus in a separate transaction. As we start adding geometric complexity to the scene, we really should look hard about how it's done. I see some support in plib for using display lists, although it looks like it's #ifdef'd out. Actually, I'm getting dlist buffer overflow warning messages when I allow random objects to get too dense, so they must be used somewhere. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Randomly-placed objects, take 2
David Megginson writes: Actually, I'm getting dlist buffer overflow warning messages when I allow random objects to get too dense, so they must be used somewhere. That's a confusing error message, I've run into that myself. Dlist stands for dynamic list, not display list. A plib dynamic list is plib's answer to vector since it is their policy not to use anything STL. Basically this means that you are creating structures bigger than plib can handle so you start seeing it spew this message and portions of the scenery start dropping out. It's arguable that on today's modern hardware, we could use a larger upper bound on plib's dlist size. 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
[Flightgear-devel] Randomly-placed objects, take 2
I've just checked in a major revision to my new randomly-placed object code: it cuts down the memory usage a fair bit and eliminates long pauses when complex tiles fall out of the cache. There are still some stutters at very high speeds (i.e. 3000kt), but at normal speeds, all seems smooth now. The basic principle is that I add only a placeholder to the scene graph for the objects in each triangle. When it falls into range, a callback creates the objects, and when it falls out of range, another callback frees them again. That way, we have objects added only to triangles that are close to the plane, and there is no need to free hundreds or thousands of objects at once when a tile falls off the cache. I also modified the material code so that an object and its texture are loaded only once, no matter how many materials use it. According to some quick tests, with randomly-placed objects disabled, FlightGear uses 214MB of which 79MB are RSS; with randomly-placed objects enabled, FlightGear uses about 237MB of which 102MB are RSS. That's a bit of a blow-up, but not nearly as bad as it was, and after a while the memory usage stops increasing and sometimes actually falls a bit. Please everyone give this a brutal workout to find any further problems. To enable randomly-placed objects, use fgfs --prop:/sim/rendering/dynamic-objects=true All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Randomly-placed objects, take 2
David Megginson writes: I've just checked in a major revision to my new randomly-placed object code: i Please everyone give this a brutal workout to find any further problems. To enable randomly-placed objects, use fgfs --prop:/sim/rendering/dynamic-objects=true Frame Rate report Win2k PIII 733 256meg Geforce2 GTS 32 meg Latest certified WQL GFX drivers from NVIDIA at default startup location no HUD no Panel Latest changes~17fps your original code~32 fps no dynamic objects ~75fps Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Randomly-placed objects, take 2
Norman Vine writes: Frame Rate report Win2k PIII 733 256meg Geforce2 GTS 32 meg Latest certified WQL GFX drivers from NVIDIA at default startup location no HUD no Panel Latest changes~17fps your original code~32 fps no dynamic objects ~75fps Here's what I get sitting still at the default location, no panel or hud, with a GeForce2Go, 32MB, 800x600x32, with the latest Linux drivers (I'm using the latest plib CVS, but I assume you are as well): no dynamic objects: ~40fps dynamic objects (latest code): ~34fps dynamic objects (old code): ~32fps Here's a fairer test: moving at 120kts, 1500ft AGL starting at the default location: no dynamic objects: ~35fps dynamic objects (latest code): ~28fps So yes, there is a hit, but I'm not seeing a significant difference between the old and new code, and nothing like the spreads you're seeing. The default location is a complex one; I get much better framerates in simpler terrain. To be fair, I've never been able to reproduce your framerate reports. Patches that, say, add or subtract 20 or 50% framerate for you (Norm) usually make a difference of less than +-5% for me. I wonder what difference in our systems could account for this. What framerates are showing up for other people? Thanks, and all the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Randomly-placed objects, take 2
David Megginson writes: Here's what I get sitting still at the default location, no panel or hud, with a GeForce2Go, 32MB, 800x600x32, with the latest Linux drivers (I'm using the latest plib CVS, but I assume you are as well): no dynamic objects: ~40fps dynamic objects (latest code): ~34fps dynamic objects (old code): ~32fps That's with AGP disabled. At AGP 4x I get ~41fps and ~36fps. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Randomly-placed objects, take 2
David Megginson writes: Norman Vine writes: Frame Rate report Win2k PIII 733 256meg Geforce2 GTS 32 meg Latest certified WQL GFX drivers from NVIDIA at default startup location no HUD no Panel Latest changes~17fps your original code~32 fps no dynamic objects ~75fps Here's what I get sitting still at the default location, no panel or hud, with a GeForce2Go, 32MB, 800x600x32, with the latest Linux drivers (I'm using the latest plib CVS, but I assume you are as well): no dynamic objects: ~40fps dynamic objects (latest code): ~34fps dynamic objects (old code): ~32fps David, My frame rate trends typically are more in line with yours. However, with the latest cvs code, default startup aiport, no hud, no panel, I'm seeing: dynamic objects (latest code): ~23-24fps no dynamic objects (latest code): ~75fps So I am seeing a huge difference with dynamic objects on vs. off. This is with a 1Ghz class cpu, 256Mb RAM, and GeForce2MX running Linux. With dynamics objects on I'm also seeing a lot of choppiness (i.e. inconsistant frame rates.) Regards, Curt. Here's a fairer test: moving at 120kts, 1500ft AGL starting at the default location: no dynamic objects: ~35fps dynamic objects (latest code): ~28fps So yes, there is a hit, but I'm not seeing a significant difference between the old and new code, and nothing like the spreads you're seeing. The default location is a complex one; I get much better framerates in simpler terrain. To be fair, I've never been able to reproduce your framerate reports. Patches that, say, add or subtract 20 or 50% framerate for you (Norm) usually make a difference of less than +-5% for me. I wonder what difference in our systems could account for this. What framerates are showing up for other people? Thanks, and all the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel -- 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
RE: [Flightgear-devel] Randomly-placed objects, take 2
David Megginson writes: To be fair, I've never been able to reproduce your framerate reports. Patches that, say, add or subtract 20 or 50% framerate for you (Norm) usually make a difference of less than +-5% for me. I wonder what difference in our systems could account for this. I believe your GFX system is 'fill limited' in comparison to mine so you don't get to 'see' the effect of the code as much. eg. When starting up over the open ocean where all the tiles are 'generated' I get ~375fps reported with 800x600x32 when looking straight down.What do you get ? FYI I have recompiled fgfs with the old and the new 'dynamic-objects' several times (5 each) tonight and once the new code was 'slightly' faster, similar to your results. All other times it is roughtly 50% the speed of the older code. I am finding this quite bewildering ?? Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
