[Flightgear-devel] Bug in uiuc_menu.cpp
The function void d_1_to_1(double array1[100], double array2[100] ) passes an incorrect size to memcpy. The correct value should be 100*sizeof(double) since sizeof(array2) is actually sizeof(double*). Alternatively the size could be passed as a parameter effectively making d_1_to_1 a pointless wrapper around memcpy. Cheers, Bernie ___ 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: 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
[Flightgear-devel] Randomly-placed objects, take 3
David Megginson writes: 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. Yes, that was it. I made the changes, and now here are my results for sitting still at the default location in daylight: With dynamic objects: 41fps Without dynamic objects: 41-42fps Here's a fairer test, since more scenery is visible and triangles are coming in and out of dynamic-object range: 1500ft AGL, 120kt in magic-carpet mode starting over the default location: With dynamic objects: 38-39fps Without dynamic objects: 38-39fps (I cranked it up to 240kt and 360kt with no noticable framerate hit for dynamic objects, though there was a stutter when a new tile loaded [I always get that]). I simply extended ssgEntity with a singleton class and provided my own bounding-sphere method that always returns a sphere of 10m radius centred at 0,0,0. That still allows culling to the Frustum, but ensures that the in-range and out-of-range are still visited. I will check in the changes now, and would appreciate it if everyone could give them another good workout (thanks to Norm, Curt, and Erik for your feedback on the last take). 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 3
David Megginson writes:
David Megginson writes:
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.
Yes, that was it. I made the changes, and now here are my results for
sitting still at the default location in daylight:
With dynamic objects: 41fps
Without dynamic objects: 41-42fps
This is MUCH better :-)
FWIW - This should help the 'stutter' while loading a 'bit'
void
makeWorldUpRotationMatrix (sgMat4 ROT, double hdg_deg,
double lon_deg, double lat_deg)
{
SGfloat sin_lat = sin( lat_deg * SGD_DEGREES_TO_RADIANS );
SGfloat cos_lat = cos( lat_deg * SGD_DEGREES_TO_RADIANS );
SGfloat sin_lon = sin( lon_deg * SGD_DEGREES_TO_RADIANS );
SGfloat cos_lon = cos( lon_deg * SGD_DEGREES_TO_RADIANS );
SGfloat sin_hdg = sin( hdg_deg * SGD_DEGREES_TO_RADIANS ) ;
SGfloat cos_hdg = cos( hdg_deg * SGD_DEGREES_TO_RADIANS ) ;
ROT[0][0] = cos_hdg * sin_lat * cos_lon - sin_hdg * sin_lon;
ROT[0][1] = cos_hdg * sin_lat * sin_lon + sin_hdg * cos_lon;
ROT[0][2] = -cos_hdg * cos_lat;
ROT[0][3] = SG_ZERO;
ROT[1][0] = -sin_hdg * sin_lat * cos_lon - cos_hdg * sin_lon;
ROT[1][1] = -sin_hdg * sin_lat * sin_lon + cos_hdg * cos_lon;
ROT[1][2] = sin_hdg * cos_lat;
ROT[1][3] = SG_ZERO;
ROT[2][0] = cos_lat * cos_lon;
ROT[2][1] = cos_lat * sin_lon;
ROT[2][2] = sin_lat;
ROT[2][3] = SG_ZERO;
ROT[3][0] = SG_ZERO;
ROT[3][1] = SG_ZERO;
ROT[3][2] = SG_ZERO;
ROT[3][3] = SG_ONE ;
}
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Randomly-placed objects, take 3
Norman Vine writes: FWIW - This should help the 'stutter' while loading a 'bit' Thanks -- I've committed the 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
[Flightgear-devel] Barnstorming
Here's the current state of randomly-placed scenery objects in FlightGear. This shot shows a farm with a city in the background: http://www.megginson.com/flightsim/farm-and-city.png Note also the framerate, which is pretty-much identical to my framerate without random objects now. To try it out, grab the latest CVS of FlightGear and the base package, then type fgfs --prop:/sim/rendering/dynamic-objects=true If you want to enable randomly-placed scenery objects by default, just add --prop:/sim/rendering/dynamic-objects=true to your $HOME/.fgfsrc. Contributions of other buildings and scenery objects are earnestly solicited. Note that my basic rule is to use very few polys (one quad for a tree, five for a basic building) and small textures (max 64x64, except for extremely large buildings; 32x32 when possible). Usually, objects will be a fair distance away, and I think it is a better use of our texture memory to have a lot of low-res variety rather than only a few high-res objects. Enjoy, 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 3
David Megginson wrote: David Megginson writes: 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. Yes, that was it. I made the changes, and now here are my results for sitting still at the default location in daylight: With dynamic objects: 41fps Without dynamic objects: 41-42fps Confirmed. Although it adds some more memory usage (13 Mb free compared to 31 Mb free in the previous situation), the framerate drops just by one frame (still got 5 left ;-) ) Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Barnstorming
David Megginson wrote: Here's the current state of randomly-placed scenery objects in FlightGear. This shot shows a farm with a city in the background: http://www.megginson.com/flightsim/farm-and-city.png How peacefull :-) Now, adding some nice urban textures might even further improve the scenery (cough, cough). Nice work David! Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Randomly-placed objects, take 3
Erik Hofman writes: Confirmed. Although it adds some more memory usage (13 Mb free compared to 31 Mb free in the previous situation), the framerate drops just by one frame (still got 5 left ;-) ) That's much more memory than I would have expected. There is only a single extra ssgRangeSelector for each model type -- the models are referenced many places, but it is always the same leaf data. I'm glad to hear that the framerate is still OK. 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
[Flightgear-devel] Dynamic scenery notes
I got a chance to try the dynamic scenery last night (in lieu of implementing the gear bounce/damp tuning for Dave Perry -- sorry). Wow. Simply stunning. :) Abject praise out of the way, here are the nits: The cowbox is too small. At only 1m high, it's really a more appropiate size for a sheepcase. Cows (at least the big north american ones that match the texture) are 1.5-2m tall at the shoulder, and often 3m long. I doubled the size to 2x4, and found the results more satifactory. The slightly-too-large size is hidden by the sparseness of the scenery. At the other extreme the 8 story building, while scaled correctly, is too large. Buildings this large are very rare, and occur in large numbers only in downtown areas that are better handled by real static scenery. I'd suggest replacing the urban scenery object with something like a 2-3 story building, or perhaps a cluster of small buildings. Right now, you can look accross the bay from San Francisco and see a huge urban skyline stretching from Oakland to Fremont which isn't even close to what's there in real life. My reading of the code is that there is a separate ssgTransform node in front of every one of the objects. That's likely to be a performance bottleneck, if the OpenGL matrix state has to change every four vertices (most GPUs want to flush the stream when the matrix changes). Instead, why not pre-compile the scenery objects for each tile into a single vertex buffer at load time. This is really easy -- step through each object and add the appropriate offset to each model vertex as you copy it into the vertex array(s). Then you could draw them all at once with no state changes whatsoever (and even get fancy in the future with stuff like compiled vertex arrays, NV_vertex_array_range and whatnot if you like). Even better, you could get a very cheap continuous LOD by drawing a distance-dependent prefix of this vertex buffer. That is, draw only the first N objects based on your distance from the tile centroid. Writing a new ssgLeaf node type really isn't so hard -- take a look at the fgPanelNode implementation for a minimalist example. 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
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] Barnstorming
Erik Hofman writes: Now, adding some nice urban textures might even further improve the scenery (cough, cough). They're in my queue -- apologies for the delay. I got pretty obsessive over the weekend fighting plib to get the random objects working. 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] Dynamic scenery notes
Andy Ross writes: The cowbox is too small. At only 1m high, it's really a more appropiate size for a sheepcase. OK, I'll fix that. Next time I'll go to the Central Experimental Farm near my house with a measuring tape. I'm pretty sure, though, that the sheep are no more than 1.5-2ft high at the shoulder. At the other extreme the 8 story building, while scaled correctly, is too large. Buildings this large are very rare, and occur in large numbers only in downtown areas that are better handled by real static scenery. Yes, I agree -- 8-story apartment buildings are not uncommon even in cities of 15,000 people, but they rarely have three sections like that one. I made the building originally to be placed manually at the turn to base leg on the rwy 22 approach at my local airport, and I used it for the urban scenery simply because it was already available. WE NEED BUILDINGS! Preferably we need buildings that are (a) generic and (b) big enough to be clearly identifiable from the air, but no matter what, they must be easy on the texture and poly budgets. Something the size of a barn or house, say, is distinguishable in the middle of a field but not in the middle of a town or city. We need strip malls, three-story suburban office buildings, apartment buildings, low rises of various types, and maybe even the occasional shopping mall or parking garage or row houses. Mostly, we need a variety of non-descript low-rises and stip malls. I'd suggest replacing the urban scenery object with something like a 2-3 story building, or perhaps a cluster of small buildings. Right now, you can look accross the bay from San Francisco and see a huge urban skyline stretching from Oakland to Fremont which isn't even close to what's there in real life. Agreed. My reading of the code is that there is a separate ssgTransform node in front of every one of the objects. That's likely to be a performance bottleneck, if the OpenGL matrix state has to change every four vertices (most GPUs want to flush the stream when the matrix changes). Instead, why not pre-compile the scenery objects for each tile into a single vertex buffer at load time. Unfortunately, then we'd lose LOD granularity and overwhelm the GPU. I agree that we could get away with some grouping, but even individual triangles can be extremely large in flat terrain and can create hundreds or thousands of trees all in range at the same time. We could also pregroup, so that we have clusters of buildings and trees as single objects. That would look nice, but it would cause trouble near the edges of triangles, where several trees or buildings might stick out into the middle of a lake or river (or a runway, for that matter). What framerates are you getting with and without random objects, using today's CVS? I can no longer see any measurable difference on my system. Even better, you could get a very cheap continuous LOD by drawing a distance-dependent prefix of this vertex buffer. That is, draw only the first N objects based on your distance from the tile centroid. Writing a new ssgLeaf node type really isn't so hard -- take a look at the fgPanelNode implementation for a minimalist example. That would be wonderful, if someone wanted to contribute it. All the best, and thanks for the comments, 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
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] dumb suggestion
Wolfram Kuss writes: I know how MSFS nightlighting works (Its fairly trivial), so if we could change the lighting parameters for the 3D model only (I guess we do not want MSFS lighting for the rest), we could have night-lit aircraft. Often, this looks really great, I experimentally implemented it in PPE. You have bright windows, an illumintade tail logo etc. Can we handle this in some generic way through plib? I could add it as an XML-defined model animation. 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] Dynamic scenery notes
On Thu, 18 Jul 2002 15:44:41 -0400 David Megginson [EMAIL PROTECTED] wrote: WE NEED BUILDINGS! Preferably we need buildings that are (a) generic and (b) big enough to be clearly identifiable from the air, but no matter what, they must be easy on the texture and poly budgets. Something the size of a barn or house, say, is distinguishable in the middle of a field but not in the middle of a town or city. We need strip malls, three-story suburban office buildings, apartment buildings, low rises of various types, and maybe even the occasional shopping mall or parking garage or row houses. Mostly, we need a variety of non-descript low-rises and stip malls. Can you explain: 1) Which tools would one make these with? 2) What format should they be saved in? 3) What guidelines should be followed regarding complexity, textures, etc.? Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re: [Flightgear-devel] Problem with clouds?
Tony Peden writes: Does anyone know why cloud.cxx is putting out: Error: base = 0,-0.00112949 Error: base = 0,0 There's probably something wrong with your cloud-layer configuration (are you using an old or modified preferences.xml?). I've downgraded it from alert to debug level for 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] FW: [Plib-devel] ssg vertex tables tuning
Norman Vine writes: I got a considerable boost in the frame rate from the following patch to PLib. ~25% at default startup location I am trying to determine if this also true for 'most' systems before advocating it's inclusion into PLib I saw a pretty-nice boost as well, for what it's worth. GeForce2Go 32MB, Linux drivers, 1600x1200x32 LCD. I don't remember what it was, because I've been using the patched plib now for over a week, but it was at least 15-20%. 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] FW: [Plib-devel] ssg vertex tables tuning
David Megginson wrote: Norman Vine writes: I got a considerable boost in the frame rate from the following patch to PLib. ~25% at default startup location I am trying to determine if this also true for 'most' systems before advocating it's inclusion into PLib I saw a pretty-nice boost as well, for what it's worth. GeForce2Go 32MB, Linux drivers, 1600x1200x32 LCD. I don't remember what it was, because I've been using the patched plib now for over a week, but it was at least 15-20%. I tried it too, and likewise saw a similar increase in framerate. Nonetheless, I think this is the Wrong Solution. What this patch does is test at render time whether or not the vertex array is small or not. If it is small, it renders the leaf with glVertex3f() calls instead of using the vertex arrays. Gack. Now, for plib as a library, this is a fine optimization that's probably worth including. I have no objections there. But for FlightGear as an application, the *real* performance bug is that we're generating really tiny ssgLeaf objects. Each tile is a single piece of static geometry. There's no reason that it couldn't live in just one vertex array (or maybe one per texture). Or be stored in a single display list, etc... But clearly the optimal performance solution we're looking for is not iterated glVertex() calls. :) 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
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
re: [Flightgear-devel] Problem with clouds?
David Megginson writes: Tony Peden writes: Does anyone know why cloud.cxx is putting out: Error: base = 0,-0.00112949 Error: base = 0,0 There's probably something wrong with your cloud-layer configuration (are you using an old or modified preferences.xml?). I've downgraded it from alert to debug level for now. I see this error message when I --disable-clouds (even though the cloud rendering is disabled, you still get the visibility reduction effects when you go through the hard coded layers.) 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
Re: [Flightgear-devel] FW: [Plib-devel] ssg vertex tables tuning
Andy Ross writes: I tried it too, and likewise saw a similar increase in framerate. Nonetheless, I think this is the Wrong Solution. What this patch does is test at render time whether or not the vertex array is small or not. If it is small, it renders the leaf with glVertex3f() calls instead of using the vertex arrays. Gack. Now, for plib as a library, this is a fine optimization that's probably worth including. I have no objections there. But for FlightGear as an application, the *real* performance bug is that we're generating really tiny ssgLeaf objects. Each tile is a single piece of static geometry. There's no reason that it couldn't live in just one vertex array (or maybe one per texture). Or be stored in a single display list, etc... But clearly the optimal performance solution we're looking for is not iterated glVertex() calls. :) I'm not claiming we are currently optimal, but you also need to consider that by grouping your low level structures into larger chunks, you reduce the ability of the scene graph to do an early cull of non-visible stuff. Making larger chunks needs to be balanced against the benefits of scene graph culling that smaller chunks bring. 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] crash
i was flying the a4 trying to dodge buildings when i crashed into one of them. the problem is i was some distance away from it as you can see from the picture at http://caliban.lbl.gov/a4_crash.pnm (it's a 1600x1200 picture so it might be pretty large). so either the crash code is wrong, or the crash boxes around buildings are too big. --alex-- -- | I believe the moment is at hand when, by a paranoiac and active | | advance of the mind, it will be possible (simultaneously with | | automatism and other passive states) to systematize confusion | | and thus to help to discredit completely the world of reality. | ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] FW: [Plib-devel] ssg vertex tables tuning
Curtis L. Olson wrote: I'm not claiming we are currently optimal, but you also need to consider that by grouping your low level structures into larger chunks, you reduce the ability of the scene graph to do an early cull of non-visible stuff. Making larger chunks needs to be balanced against the benefits of scene graph culling that smaller chunks bring. The majority (I'm guessing 70%) of tiles are either rendered in their entirety or culled in their entirety. The tile would seem, to me, to be just about the right granularity for doing culling. Certainly culling on tiny 10 vertex objects is too fine-grained, no? You can DMA a *lot* of vertices across the AGP bus in the time that it takes to do that cull. If my 70% guess is correct, then doing culling at a tile level will send 15% (the remaining 30% of tiles are on average half-invisible) too many vertices to the card for each frame. Rendering out of large vertex arrays instead of doing glVertex() calls has to be worth at *least* 15%. 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] FW: [Plib-devel] ssg vertex tables tuning
Curtis L. Olson writes: I'm not claiming we are currently optimal, but you also need to consider that by grouping your low level structures into larger chunks, you reduce the ability of the scene graph to do an early cull of non-visible stuff. Making larger chunks needs to be balanced against the benefits of scene graph culling that smaller chunks bring. To back Curt up here, culling matters a lot -- some people saw a 70% framerate drop when I tried disabling scene-graph culling for some branches. 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] crash
Alex Romosan writes: i was flying the a4 trying to dodge buildings when i crashed into one of them. the problem is i was some distance away from it as you can see from the picture at http://caliban.lbl.gov/a4_crash.pnm (it's a 1600x1200 picture so it might be pretty large). so either the crash code is wrong, or the crash boxes around buildings are too big. There are no crash boxes around buildings -- we're not doing collision detection at all. If you crashed, you must have hit the ground (possibly at one of those nasty tile intersections people have been talking about). 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] crash
On Thursday 18 July 2002 7:43 pm, David Megginson wrote: Alex Romosan writes: i was flying the a4 trying to dodge buildings when i crashed into one of them. the problem is i was some distance away from it as you can see from the picture at http://caliban.lbl.gov/a4_crash.pnm (it's a 1600x1200 picture so it might be pretty large). so either the crash code is wrong, or the crash boxes around buildings are too big. There are no crash boxes around buildings -- we're not doing collision detection at all. If you crashed, you must have hit the ground (possibly at one of those nasty tile intersections people have been talking about). All the best, David Same thing happened to me. Funny part is I flew through a different building first. I don't think I was on a tile boundary when I crashed though. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: crash
David Megginson [EMAIL PROTECTED] writes: There are no crash boxes around buildings -- we're not doing collision detection at all. If you crashed, you must have hit the ground (possibly at one of those nasty tile intersections people have been talking about). you can see from the picture i was about 275 feet off the ground. if i hit the ground, shouldn't my altitude be 0? anyway, i thought we were doing collision detection because the first time i tried it i purposefully crashed right into a building to see if i can do it. it looked really good, with just the wing and a bit of the tail sticking out. i should've taken a picture. i never saw these kind of crashes without the dynamic buildings... --alex-- -- | I believe the moment is at hand when, by a paranoiac and active | | advance of the mind, it will be possible (simultaneously with | | automatism and other passive states) to systematize confusion | | and thus to help to discredit completely the world of reality. | ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re: [Flightgear-devel] Re: crash
Alex Romosan writes: you can see from the picture i was about 275 feet off the ground. if i hit the ground, shouldn't my altitude be 0? anyway, i thought we were doing collision detection because the first time i tried it i purposefully crashed right into a building to see if i can do it. it looked really good, with just the wing and a bit of the tail sticking out. i should've taken a picture. i never saw these kind of crashes without the dynamic buildings... Hmm -- I guess that the buildings could be part of the HOT calculations now. Norm -- does that sound probable? I've been flying right through them with impunity. 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] Re: crash
On Thu, 2002-07-18 at 17:07, Alex Romosan wrote: David Megginson [EMAIL PROTECTED] writes: There are no crash boxes around buildings -- we're not doing collision detection at all. If you crashed, you must have hit the ground (possibly at one of those nasty tile intersections people have been talking about). you can see from the picture i was about 275 feet off the ground. if i hit the ground, shouldn't my altitude be 0? You're AGL altitude yes, but not pressure altitude. anyway, i thought we were doing collision detection because the first time i tried it i purposefully crashed right into a building to see if i can do it. it looked really good, with just the wing and a bit of the tail sticking out. i should've taken a picture. i never saw these kind of crashes without the dynamic buildings... --alex-- -- | I believe the moment is at hand when, by a paranoiac and active | | advance of the mind, it will be possible (simultaneously with | | automatism and other passive states) to systematize confusion | | and thus to help to discredit completely the world of reality. | ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel -- Tony Peden [EMAIL PROTECTED] We all know Linux is great ... it does infinite loops in 5 seconds. -- attributed to Linus Torvalds ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re: [Flightgear-devel] Virtual Cities
Norman Vine writes: http://virtualcities.ida.org/virtualcities/virtualcities.html These models are available for free see link to developers den These look great but they are very detailed -- the oil tanker, for example, uses over 1200 polys, and the shopping mall uses over 3000 (with over 4000 vertices). Ouch! Thats 1-fps territory if we include more than a few of those. Perhaps when our LOD support is more sophisticated, we could use them for extreme closeups. Unfortunately, the plib Openflight loader also loses the colors from the models on import (they're untextured). In the meantime, I might try stripping the tanker down by removing most vertices from the mesh and reassembling them into bigger tris, but I'm worried that it will take longer than just making a new tanker from scratch. 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] crash
Curtis L. Olson writes: David Megginson writes: Alex Romosan writes: i was flying the a4 trying to dodge buildings when i crashed into one of them. the problem is i was some distance away from it as you can see from the picture at http://caliban.lbl.gov/a4_crash.pnm (it's a 1600x1200 picture so it might be pretty large). so either the crash code is wrong, or the crash boxes around buildings are too big. There are no crash boxes around buildings -- we're not doing collision detection at all. If you crashed, you must have hit the ground (possibly at one of those nasty tile intersections people have been talking about). The height above terrain routine traverses the scene graph so it should return intersections with buildings or any other random/dynamic object. The aircraft moves in discrete steps though so with smaller objects there is a chance you could skip it without detecting ground above you. Right, but it seems as if the dynamic-objects aren't being detected by the hitlist routines. i.e you can fly through the buildings and there is no change in AOL when you fly over one Way this is so is not apparent to me :-( Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
