[Flightgear-devel] Re: gui theming
* Jim Wilson -- Wednesday 13 July 2005 01:11: [dialog transparency] As far as making it user adjustable, that sounds great. It *is* user adjustable, just like most of fgfs: (1) Edit the XML file. :-) (2) $ fgfs --prop:/sim/gui/colors/background/alpha=0.8 (3) change this value in the property browser and re-init the GUI (could be automated with a key binding) But there was a bug that I introduced very late, after which I hadn't tested transparency any more. This is fixed in CVS, but I'm sure there are other bugs left. The style is still available as http://members.aon.at/mfranz/test-style.xml [3 kB] and can be tested like this: $ fgfs --config=/tmp/test-style.xml updating plib to CVS/HEAD is recommended. (Otherwise text starting from negative coordinates disappears.) Further plib fixes to come. m. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: gui theming
* Melchior FRANZ -- Wednesday 13 July 2005 08:51: [dialog transparency] The GUI style is now switchable at runtime. I've put the two available styles into $FG_ROOT/gui/styles/ -- Shift-F10 cycles through all (two) styles in this directory. Of course, the new style can be chosen from the command line or ~/.fgfsrc, too: $ fgfs --prop:/sim/current-gui=1 But why not simply replace the old style with the new? - the old style is faster -- two or three frames per second on my archaic graphics card! - in bright environments the old style may be better suited - for hysterical raisins I didn't intend $FG_ROOT/gui/styles/ to become a collection of dozens of styles. Just two or three for different purposes (and as many local styles as people want to have there, of course :-). m. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Scenery files triangles
While looking at the scene graph I saw that the .btg files are generating a lot of leafs. This is not new, but perhaps it is becoming worse each time the source data resolution used to build the tile becomes finer. I have added a few traces in simgear's sgBinObjLoad functions, an example : sgBinObjLoad (F:/FlightGear/data/Scenery/Terrain/w130n30/w123n37/942058.btg) get_wgs84_nodes.size=1543 get_tris_v.size=0 get_strips_v.size=0 get_fans_v.size=928 leafMap.size=12 local_terrain-getNumKids()=928 sgBinObjLoad (F:/FlightGear/data/Scenery/Terrain/w130n30/w123n37/942043.btg) get_wgs84_nodes.size=1671 get_tris_v.size=0 get_strips_v.size=0 get_fans_v.size=1045 leafMap.size=14 local_terrain-getNumKids()=1045 sgBinObjLoad (F:/FlightGear/data/Scenery/Terrain/w130n30/w123n37/KNUQ.btg) get_wgs84_nodes.size=3500 get_tris_v.size=43 get_strips_v.size=3 get_fans_v.size=0 leafMap.size=33 local_terrain-getNumKids()=46 sgBinObjLoad (F:/FlightGear/data/Scenery/Terrain/w130n30/w123n37/KPAO.btg) get_wgs84_nodes.size=685 get_tris_v.size=11 get_strips_v.size=3 get_fans_v.size=0 leafMap.size=10 local_terrain-getNumKids()=14 We can see that : - tile objects use only fans - airport objects use strips and regular tris - for an equal number of triangles a tile object uses 50 times more leafs than an airport object ; - the number of leafs from a tile has nothing to do with the number of materials ( leafMap ) When the leafs are inserted in the scene graph they are sorted by materials, so my concern is not about OpenGl material switching but rather on the number of calls needed to draw a few triangles. The use of display list has divided the number of calls to opengl, that's why there was a substancial gain. If we do one call per material we can divide this number of calls by 50 for tile objects. And yes I know strips or fans are supposed to be faster than triangles, but no this is not true in the current situation (1000 calls to draw a 10 triangle strips/fans can't be faster than 10 call to draw 1000 regular triangles). Is there a reason why we are using fans and not strips for tile objects ? Harald. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Scenery files triangles
Harald JOHNSEN wrote: Is there a reason why we are using fans and not strips for tile objects ? http://baron.flightgear.org/pipermail/terragear-devel/2005-June/001219.html Erik ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Scenery files triangles
Erik Hofman wrote: Harald JOHNSEN wrote: Is there a reason why we are using fans and not strips for tile objects ? http://baron.flightgear.org/pipermail/terragear-devel/2005-June/001219.html Erik lol ok, I didn't saw that ;) Harald. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Shadows
Harald JOHNSEN wrote ... snip ... Perhaps can we use a real ogl light for the aircraft landing light and fake light for the airport lights, and since the view is centered on the aircraft the hack could be good enought. Are you going to progress OGL lights for aircraft landing lights? I'm holding off doing fake landing lights on my models pending a better solution (that's my excuse anyway :-) ) Regards V. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Scenery files triangles
Harald JOHNSEN wrote: Is there a reason why we are using fans and not strips for tile objects ? These days, it's usually faster to use indexed vertices. Strips and fans are faster because they reduce the number of vertices that need to be transformed by (and sent to) the hardware by saving 1 or 2 from the last triangle drawn. But modern cards have vertex caches that are much (!) larger than 1 or 2 entries. If someone wants to change the terrain format, I'd suggest trying indexed vertices first -- it's simpler, too. Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Scenery files triangles
On 13 Jul 2005, at 15:36, Andy Ross wrote:These days, it's usually faster to use indexed vertices. Strips and fans are faster because they reduce the number of vertices that need to be transformed by (and sent to) the hardware by "saving" 1 or 2 from the last triangle drawn. But modern cards have vertex caches that are much (!) larger than 1 or 2 entries. If someone wants to change the terrain format, I'd suggest trying indexed vertices first -- it's simpler, too. Whilst wishing to avoid a 'me too' post, I fully agree with this; writing a strip-ifier is a complex job, storing each tile as several, or maybe even one vertex array with indices is easier to generate, involves fewer SSG nodes, and is easier for drivers to optimise on the card, than either fans or strips.James___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Airport LFPO Paris Orly Update
Rather than keeping on my side a new version of the Airport Paris Orly I guess that you could be interested to get it. That Airport in the existing Scenery is wrong regarding the apt.dat Here an update which suit to that apt.dat and the Scenery File e000n40 The Airport and the corresponding tile as been rebuilt. Everything done with Terragear. You only have to replace the old files by these new ones. http://ghours.club.fr/LFPO-update.tar.gz -- Gerard ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] New super/turbo MP code is in
Andy Ross Vivian Meazza wrote: Meanwhile, you are distracting Andy from updating the awaited supercharger code. Heh, fair enough. This is checked in now, with a general rewrite to clarify things and fix the bug where MP was reported before the wastegate application. The only new property is boost-gauge-inhg, which represents the delta between the actual MP and ambient pressure (not strictly correct, of course, but good enough for a first cut). I ran the solver over a bunch of piston planes, and didn't see much change, so I think this should be OK. If everyone could fly a circuit or two in their favorite piston-engined plane and report success, that would be helpful. Back from a holiday in France. The modified software tests OK here. One small snag: the MP is not ambient when the engine is not running. Strictly, this should be turning, I suppose, because a wind-milling supercharger will produce some pressure. Near enough though. I've wasted a couple of days coming to the conclusion that the published graphs for the Merlin show the so-called boost pressure in psi absolute, with zero at 1 atmosphere. Illogical, but by making that assumption, I can readily adjust the turbo-mul parameter to make the full-throttle height accord with the published figures. Once this is adjusted, the rest of the simulation seems very close. Overall, most satisfying. Moving on, the Boost Control/Boost Control Cutout has been written in Nasal. This works well, but YASim needs to be told to ignore the wastegate. I tried setting an improbable value for the wastegate, but of course, YASim uses the wastegate value when solving, so this doesn't work. I attach a patch which addresses both issues. This adds a Boolean parameter supercharger to the config file. If this is true, the wastegate function is skipped over, so that the supercharger output can be controlled by the Boost Controller via the throttle. Vivian yasim4.diff Description: Binary data ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] New super/turbo MP code is in
Vivian Meazza wrote: Back from a holiday in France. The modified software tests OK here. One small snag: the MP is not ambient when the engine is not running. Strictly, this should be turning, I suppose, because a wind-milling supercharger will produce some pressure. Near enough though. Yeah, good point. But it's more complicated than running vs. not running I think. If a normally aspirated engine is turning with the throttle closed (whether or not it is burning fuel), it will try to suck a vacuum in the manifold. Superchargers will produce the same RPM-to-boost curve as they do when the engine is running, because their impeller is being driven at the same speed. But turbochargers don't, because their impeller is driven by exhaust pressure; in a windmilling situation, the exhaust pressure is going to be *less* than ambient and the turbo will want to turn backwards! (No idea if this actually happens or not -- is there a relief system to prevent this?) Anyway, the bug here is obvious: playing with the throttle on the ground with the engine shut down cause the manifold pressure gauge to move up and down, which clearly doesn't happen in reality. But a fix is going to be subtle and hard, so I'm willing to live with this until we can come up with a realistic set of requirements. While we're listing obvious shortcomings of the current model, note that it also doesn't handle intercooling, which I'd argue is more important than getting idle/windmilling manifold pressure correct. :) I've wasted a couple of days coming to the conclusion that the published graphs for the Merlin show the so-called boost pressure in psi absolute, with zero at 1 atmosphere. You mean gauge, right? Normally absolute pressure connotes interpreting zero as vacuum. Moving on, the Boost Control/Boost Control Cutout has been written in Nasal. This works well, but YASim needs to be told to ignore the wastegate. I tried setting an improbable value for the wastegate, but of course, YASim uses the wastegate value when solving, so this doesn't work. I'm a little confused. The boost cutout works by mapping a property name to the wastegate setting. You can set that property to any value you like (say, 100) during solution. Note that the improbably high wastegate mechanism is actually the way that YASim implements this internally. For a normally aspirated engine, the _maxMP value is set to 1.0e06, so I know that this will work. The supercharger boolean isn't a bad idea in principle, as it will be needed eventually to handle the difference between turbocharging and supercharging. But I'd rather wait until we have an actual implementation in mind before adding it. I'm pretty sure your current requirements can be met with existing code. Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Linux Expo, UK
Hi All, Although I've not recently been active, I've just spotted something. After last years success I was wondering if anyone was interested in returning to the .org Village again? This year I can bring some hardware. Hotel arrangements - If anyone needs a hotel, I might be able to help out. Regards, Chris ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] France file Signs : France South Est available
Dedicated to Signs users: A first part of France territory is available = France South-Est at http://ghours.club.fr/france-SE.tar.gz I divided the task in four parts, will come later on = North-Est, South-Ouest, North-Ouest. -- Gerard ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] 3dconvert.exe
Does anyone have a copy of 3dconvert.exe built for dos/windows that they can send me [offline]? Thanks, Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
