Re: [Flightgear-devel] Re: Sim Reset
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Vassilii Khachaturov schrieb: IIRC a destructor can't call virtual methods, so if the interface needs to do some kind of cleanup it can only be something pertaining to this instance and using just the compile-time resolved calls. I haven't looked at the code you cite above so this might be irrelevant there, but I am a bit suspicious because of the name FGInterface that hints at an abstract class. Not knowing if it helps (I don't even know about what part of the code you are talking about): Virtual functions can be avoided in many cases by using the so called Barton-Nackman trick (http://en.wikipedia.org/wiki/Barton-Nackman)... CU, Christian -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (MingW32) iD8DBQFDqFJFlhWtxOxWNFcRAr5eAJ42G38BOCWzN5QysINniU+2Tfp9sQCgt81Q 12s6Yq3RH93GlvlN3FUmcyA= =iW5n -END PGP SIGNATURE- ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Slashdot: Seasons Givings
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Martin Spott schrieb: Curtis L. Olson wrote: P.S. I can still photoshop out most of my gray hair ... :-) Being an OpenSource advocate I hope that you 'GIMP' our those grey hairs that accidentially might happen to be where you didn't expect them ;-) That wasn't grey hair. That was just the specular reflection of an light... CU, Christian -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (MingW32) iD8DBQFDpoJ3lhWtxOxWNFcRAqb/AJ9mGZ8YVSoQXv2Egni9VbAx0VMY6wCeNlLw ZlcOQjg+XRputVjvKYXJ158= =tDgE -END PGP SIGNATURE- ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Even more Scenery Objects
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Martin Spott schrieb: http://document.ihg.uni-duisburg.de/bitmap/FGFS/EDDI_01.jpg It's not that easy to create a screnshot of this large building without losing major detail Watch it at night ! Yes, the version on http://fgfsdb.stockill.org/modelthumb.php?id=121 is great! CU, Christian -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (MingW32) iD8DBQFDpeTSlhWtxOxWNFcRAvDRAJ9Cw23kY03palJpZKI29ODoyN4X4gCfbrbq B+VDTaUFlIM4HDYuiXt2p94= =rEMq -END PGP SIGNATURE- ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Proposal: New way to add commandline options
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Martin Spott schrieb: I see three reasons opposing this idea: 1.) I'm not sure but I assume you can't use : inside a command line option on certain platforms (Windows). I really can't imagine any problems that it might cause under windows (haven't tested it though) 2.) Too often people want to do 'command -h [-v] | grep -i keyword' in order to search for a certain option, they don't want to browse a supplemental text file. see next answer 3.) Every effort spent into another duplication of such information is waste. If someone really wants to revamp '-h -v' I suggest to create a method that browses the property tree and to force any available option to carry an explanation that is attached to the respective object in the mentioned tree. Duplication of such information unavoidable results in some sort of mess - _always_ :-)) If the '-h -v' can get the relevant information out of the property tree then that's the best way to go. The information would be aviable on the command line help and in the property tree browser. It would also stay up to date as there's only one source (redundancy is *bad*). CU, Christian -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (MingW32) iD8DBQFDpIy4lhWtxOxWNFcRAt+xAKCnxgY2tvxP9EZpNBslAAbhuCn3iwCfcBcJ 8vMGYAqv/e6z4fEJjkn+QlU= =oGav -END PGP SIGNATURE- ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] RenderTexture bug
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ampere K. Hardraade schrieb: However, there is some strange coloring issue: http://www.cs.yorku.ca/~cs233144/fgfs-screen-001.jpg You shouldn't take drugs and then fly!!! CU, Christian :) -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (MingW32) iD8DBQFDnqSplhWtxOxWNFcRAnsuAJ0RE85gDD2bwTX4gSnB/fyP0s9YlgCgh5mf aX6PZcM5x5jLliQ7ou7YUaA= =zu2G -END PGP SIGNATURE- ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] W2K or XP?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jon S Berndt schrieb: Anyone got a good reason why I should install W2K or XP as preferred over the other one? The difference isn't as big as Microsoft wants you to believe. On modern hardware I'd use XP, on a bit older and slower hardware W2K is better. A gut feeling tells me that the transition range is 1 GHz to 2 GHz and 256 MB to 512 MB. CU, Christian -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (MingW32) iD8DBQFDmzGmlhWtxOxWNFcRAlNVAJ4v/SbOVf6pdPlVJp83/M3owH/6EACglwGr UmsWAn6RjOg12UKB9icqgUY= =3Ad7 -END PGP SIGNATURE- ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [PATCH] Scenery/tileentry.cxx: new feature: allow objects on sea tiles ( generally don't drop objects)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Melchior FRANZ schrieb: If FG_SCENERY=A:B and both dirs contain a Terrain/ and Objects/ does the seperator have to be a double colon :? Or, more precisely, is it a ; under Windos? A double colon would cause real trouble under Windos... (imagine FG_SCENERY=D:\Scenery) CU, Christian -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (MingW32) iD8DBQFDkYL7lhWtxOxWNFcRAvayAJ4jczgJ/V1eXcO1bM0fpfOFbBhJegCgp02i dDKvV99NJ+hF8YMOio4NU9w= =wG9n -END PGP SIGNATURE- ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Possible new thinking for 2D/3D cockpit instruments
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Steve Hosgood schrieb: I was deliberately thinking that you **don't** want to use OpenGL for that sort of thing. The GPU has enough work to do rendering the view out of the windows, it would be a waste of its time rendering instruments for the fascia - they're always going to be displayed straight on with flat lighting. It's just a simple animation job for a normal window. That's why the future of the 2D desktops will be rendered by the 3D hardware (Windows Vista, the OpenGL based X-Server, ...). A while ago 2D desktops would profit from the graphic accelerator graphic cards. They had chips that could draw very fast lines, etc. pp. But today we've got 3D accelerators that can do even more. They are even programmable. So the new OSes use that functionality for a fast visual feedback. So it doesn't make sense to pass the rendering of some instruments back to the OS. It will just give it back to the graphics adapter - with the aditional overhead of going through the OS. The only alternative to reduce the load on the GPU is to draw it with the CPU by hand (note: this is really CPU intensive!). But if the CPU idles too long (what I really doubt) we could easily increase the FDM resolution, AI traffic, ... CU, Christian -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (MingW32) iD8DBQFDkC5JlhWtxOxWNFcRArQ2AJ0Y9W2z2ZlrQ3615T3LVUGOv3T10QCgq1Ac Lv9HbthiUs1IqdPu6uq5ZNo= =rjDA -END PGP SIGNATURE- ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Pressure distribution calculation on planes when landing?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Andy Ross schrieb: Dai Qiang wrote: I'm wondering, if it's possible to calculate and record the pressure distribution on all parts of a plane, e.g. gears, wings etc, when it's landing? Landing gear could be done fairly easily, as the force along the gear strut is known to the FDM. But stress on other aircraft parts are basically impossible with a FDM at our level of precision: you would need a full finite-element model of every load-bearing structure on the aircraft. That's definitely not a task for a real-time simulation. Dai Qiang, for what do you need that data? I can only think of animating the model. This works already for the gear model. And an reasonable animation of the wings could be easily faked. All you need is the amount of lift they produce. Divide that with a constant weight-force of the plane (e.g. MTOW * earth acceleration) and you get a number that is zero when the wings produce no lift and 1 during a steady flight (and somewhere above 7 when the wings break...) CU, Christian . -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (MingW32) iD8DBQFDjID1lhWtxOxWNFcRAp66AJ9Tnw97UCGc1Tr5gxwjtg6FLGwD3wCdEW3j TDdl2oi9/9eQGQI9Wm+Z2Ag= =Jtsq -END PGP SIGNATURE- ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Any chance for NURBS taxiways?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Roberto Inzerillo schrieb: Is there any chance we get NURBS instead of polygons for taxiways? That's not for me to decide, but I doubt that it will happen in the near future. Of course this would be a nice improvement for any object in the scenery. I guess Plib does not have any problem with that. Are there any reason why NURBS are not taken into account for building e.g. the terrain? OpenGL and thus PLIB can't handle NURBS themselves. This idea came into my mind while working with some modeling tools which let users build complex geometry with simple techniques using nurbs and I imagine a curved nurbs terrain would be a very high improvement in visual results :-) For modelling purposes NURBS are great (although they also have drawbacks, but those don't matter here). But to display a NURBS curve/surface it must be tesselated (i.e. converted to polygons/triangles). This process can easily be done - but it takes time. End even more time to get it right (there shouldn't be any edges vissible, it must fit with the rest of the scenery). So that process should happen offline, i.e. at the time the scenery is generated not at the time it's going to be displayed. AFAIK TerraGear already uses NURBS, so there's no problem at all. The limiting factor is IIRC the data format for the airport database - but I remember a discussion that its currently going to be enhanced. CU, Chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (MingW32) iD8DBQFDi20olhWtxOxWNFcRAtUxAJ9FVJEIDBrqUG0O8PIcDWOadaSwfACgm9N9 EOFWY81xqodKsh1350nMtBE= =jm35 -END PGP SIGNATURE- ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] [BUG] [PATCH] (announcement) throwing stale exceptions and missing copy ctor/assignment
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Vassilii Khachaturov schrieb: What has been done in the patch: * whenever an exception object was created on a stack and then thrown (thus causing the dtor for that object to fire!), it was replaced with a STATIC exception object use in the same scope. I've reviewed all the cases for the potential MT problems this might create, and think that there's nothing dangerous, but I'd appreciate your review of the code from this aspect. I wonder: what does actually happen when you create a static object in the middle of a method? Where does it get stored? When does it get released? Does it create a higher static memory footprint? (Does it's size matter?) I haven't really looked into the patches but what you describe sounds good to me. CU, Christian -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (MingW32) iD8DBQFDhx5olhWtxOxWNFcRAkbDAJ9tujvOi2dABEG3XB6lhXU5odhungCgs02+ UoPMci4sxXF+/HIuS4gLxpc= =elz8 -END PGP SIGNATURE- ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] OT: Tower Simulator
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Martin Spott schrieb: I just ran across this document http://www.adacel.com/prodserv/downloads/MAXSIM.pdf and thought: Isn't it great that FlightGear is so flexible to provide the visuals for such an application without modification ? Do they use FlightGear? I couldn't find any reference anywehere... CU, Christian -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (MingW32) iD8DBQFDfKb2lhWtxOxWNFcRAuPEAKCehPl9JrwaKkh0loTNNDUweQZMXgCfTO2W rTutzitNBH3bkBI0vaHYw9E= =ZP8O -END PGP SIGNATURE- ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] impending v0.9.9 release
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Curtis L. Olson schrieb: Hi all, I would really like to get v0.9.9 out the door this week ... Great! Will there be a Windows binary prerelease to test it? CU, Christian -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (MingW32) iD8DBQFDejaVlhWtxOxWNFcRAoOYAKCY+EQIEVYLxGe119ZR5vd97fMuNgCfe1rv T0a1k27gnv51OUiCanbFKxg= =l+7o -END PGP SIGNATURE- ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] AI Aircraft Models
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jon Stockill schrieb: Innis Cunningham wrote: I would think we are better ploting our own course this may mean we are a bit light on to start off with but with people helping it would take no time at all. Lots of airlines provide timetables in PDF format - fed into pdftotext and parsed with a bit of perl we should be able to build up a reasonable amount of data fairly quickly. Worst case is the formatting is horrid and it all needs to be done by hand - it's still not gonna take forever if there's a few people involved. Is there any documentation on the current AI schedule formats anywhere? I'll have a look at a couple of timetables tomorrow and see what I can do. The Star Alliance offers the timetable for *all* their airlines at http://www.staralliance.com/ under travel tools in various digital formats - including regular updates. Once we've got an import filter we could allways have up to date comercial traffic for daily 15000 flights... CU, Christian -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (MingW32) iD8DBQFDbfMjlhWtxOxWNFcRAhzhAJ9th+cIddap2FjldMuFRKd0JW25eACdGu7D JWGwJ30AapYbYy8Ino0MXCk= =iwpz -END PGP SIGNATURE- ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] AI Aircraft Models
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Durk Talsma schrieb: To get AI traffic going in the forseeable future, we could use quite a few low-polygon count aircraft models in various paint schemes. So, I'd be interested to know if anybody with reasonable 3d modeling skills would be interested in contributing in this field. Although the traffic system shouldn't be limited to commercial airliners, this is probably the area I'd be working on mostly initially. So, for starters, I would like to explore some models of the more popular airliners series, i,e., the Boeing 7[0-8]7, Airbus A3[0-8]0, and any [McDonnel] Douglas aircraft (and Fokkers of course :-)). Wouldn't it be better to add those models to the existing (and yet to come) high-poly models as a different LOD? This would also help with multiplayer setups (assuming that all models get a very low poly setup as well) CU, Christian -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (MingW32) iD8DBQFDa+NXlhWtxOxWNFcRAjnMAJ9yv+kvqX0pLJvRKxGAUj9Iesau9ACfRHpt doz58/mJJZDhZADJLyTgOH0= =Qscd -END PGP SIGNATURE- ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: A question regarding accurate taxiways
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Paul Surgeon schrieb: On Saturday 15 October 2005 23:44, Ralf Gerlich wrote: Hi, I hope I don't say too much if I say that there is work planned on defining taxiways by means of polylines in TaxiDraw. That's still very restrictive. It's a step in the right direction but is still far from what is needed. We need polygon editing and not just polylines. Taxiways are unfortunately too full of non-parallel sides for polylines to work properly everywhere. How would you draw these taxiways with polylines? Polylines should be sufficient (as long as you don't need things like bridges, i.e. stay 2D). To find out if you are outside (e.g. on grass) you do a line walk. I.e. you start on the outside (e.g. from far far away) and walk on a line to the desired position. On that walk you cound how often you've crossed a polyline. Each time you cross it you change from outside to inside (or the other way round). To get the final triangulation you'll only need a contraint delauney triangulation where you'll delete the outside triangles (or, better, asign them the outside material...) Doesn't TaxiDraw already use CGAL? With CGAL you've got all that you need for that. CU, Christian -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (MingW32) iD8DBQFDUljXlhWtxOxWNFcRAsHaAKCnLD1thK3IJYl5zP/H5yFFcPU1fwCgpXPk DPQApGan8ULq1O70gRGjy+U= =8g2S -END PGP SIGNATURE- ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: A question regarding accurate taxiways
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ralf Gerlich schrieb: I'm not sure how important giving back to Robin's DB is for the FlightGear community but in the OpenSource manner I'd say we should try to find a way of not doing things twice in two communities. We should try to scratch only our own itch. Robin's DB is a great start, but when it limits us it's not good enough anymore. BUT, of course, Robin should be able to use our data as well, when he likes to. So we could offer an DB enhancement and Robin can follow if he wants to. Polylines should be sufficient (as long as you don't need things like bridges, i.e. stay 2D). To find out if you are outside (e.g. on grass) you do a line walk. I.e. you start on the outside (e.g. from far far away) and walk on a line to the desired position. On that walk you cound how often you've crossed a polyline. Each time you cross it you change from outside to inside (or the other way round). You are probably talking about planar partitioning, where different faces are defined by separating lines. (The only links I can find in a quick google search on topological maps, planar maps or DCEL (doubly connected edge lists) are from the CGAL-manual or non-introductory papers) [SNIP] Doesn't TaxiDraw already use CGAL? With CGAL you've got all that you need for that. TaxiDraw doesn't use CGAL currently. Sorry, I mixed the CGAL useage up with the FlightGear scenery designer. But that doesn't change the perfect fit of a constrained delauney triangulation for this case... CU, Chrisitan -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (MingW32) iD8DBQFDUrCalhWtxOxWNFcRArU9AKC1Suw2+bCDm66pfbiecGmH0kph5wCfV4hl O9GFJRhGjS9/2XlxzpUvoMc= =xeZk -END PGP SIGNATURE- ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Question: Online forums?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Curtis L. Olson schrieb: I have a question I'd like to toss out to the group for discussion/comment. What would people think of abandoning our mailing lists and converting over to online/web-based forums? I hate forums. At a mailinglist I've got nothing to do - they come to me. At a forum I must think of querying it once in a while - I have to come to them. It's like the difference between polling and interrupts... - I'm getting really sick of spam. That's a valid point. But I think that can be handeld automatically. THe admins get 2 kind of mails: 1) valid mail that bounced 2) SPAM If you'll just have an autoresponder that tells all reasons why a mail bounced (like: your email address isn't registerd and/or your mail is bigger than 40kb) valid users know how to get their next mail through - and the SPAM doesn't affect *you* anymore. If you really want to switch to a forum I'd only use it for the fgfs-users mailinglist. There I can think that the advantages outweight the disadvantages - but we still need some people that poll that forum. An average developer probably hasn't got the time... CU, Chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (MingW32) iD8DBQFDKG3GlhWtxOxWNFcRAi5CAJwO2hL4oxdyFLMPJuPMx3YBGDd9CQCgmVSJ BIMR2XKw0zGNIhISL3dapnY= =GLzg -END PGP SIGNATURE- ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Announcement: First TerraGear landcover database export
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ampere K. Hardraade schrieb: On September 10, 2005 09:28 am, Curtis L. Olson wrote: My understanding is that for the USA, the X-Plane data for runways comes primarily from DAFIF. Taxiways are all hand drawn and placed. Outside the USA the runway data is manually generated by anyone who wants to submit new airports, so quality and accuracy is all over the map. Curt. Google has some pretty accurate taxiways for their map. Check out http://pigeond.net/flightgear/fg_server_map.html in map mode. Hey, that's a cool application of Google Maps! Does anybody where Google got their data from? Didn't they get the data when they bought keyhole (or so)? (The company Google Earth was original from) CU, Chrisitan -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (MingW32) iD8DBQFDI1CmlhWtxOxWNFcRAj41AJ4x6mLE3/xvlpSVgK5ZqXljetwRgQCdFJyh DTpPHcnPeP24FD5ZaYjRMSQ= =Gecy -END PGP SIGNATURE- ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [Flightgear-users] RE: Turbine Engine (Concorde, Hunter, and Citation Information Needed)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Georg Vollnhals schrieb: Curt, well argued - our real-world pilots handle these engine startup and shutdown procedures very seriously in helicopters without FADEC, ie. Eurocopter BO105, BK117. Getting the temperatures too high (hot start, ITT++) is a financial desaster. And what not might be generally known - the engines are even cooled by airflow after shutdown for a short time with the electric starter. This is something people with (nowadays so common) turbos in their cars should remember (although most don't know it): You should idle the engine a bit before stoping it, so the turbine has some time to cool down. (The most common problem: stoping at a petrol station after going for some time at full throttle). AFAIK Porsche were the only ones that have build an extra electrical motor to turn the turbo after shut down. As car turbos get turned only by aerodynamic forces it is much more difficult to add an extra motor than with gas turbines or jet engines (that allways need an gear box to get started - execpt perhaps the model engines) CU, Christian -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (MingW32) iD8DBQFDHeDllhWtxOxWNFcRApTbAJsFFRBXUU9G3BvSTHuz0+BBiNb7+QCgkLyh xiMR6GhaeSzVF0X+sMueXno= =2J3g -END PGP SIGNATURE- ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] OT: X-15 Pilots Finally Get Astronaut Wings
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 http://science.slashdot.org/science/05/08/24/1516255.shtml?tid=160tid=14 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (MingW32) iD8DBQFDDKHulhWtxOxWNFcRAuu5AKCI9YXHLI1Al3RZxuqWlm+uhCDDfQCgkfEV /UKFr/biGLZJ/iSy3+vluxg= =xAZj -END PGP SIGNATURE- ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: very long startup time
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Melchior FRANZ schrieb: On Mon, Aug 22, 2005 at 03:03:11PM -0700, Alex Romosan wrote: looking at the trace logs it looks like fgfs goes through every metar station out there: Initializing environment subsystem 2005/08/22 14:56 KSFO 221456Z 0KT 10SM SCT007 OVC010 13/11 A2995 RMK AO2 SLP142 T01280106 53002 METAR from weather.noaa.gov METAR data too old no metar at metar = KSFO Check if your system time is set correctly. If it's running in the future or past, every metar data set will be too old/new and fgfs searches for an acceptable one. (It should probably stop trying after the first 10 failed sets.) or it could ask an NTP-server for the correct time... but that's problaby going too far. CU, Chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (MingW32) iD8DBQFDCvK9lhWtxOxWNFcRAj3zAJ93ZV0x+zMqM+93TwvPrg9JPiUf0gCeMGL9 Z2CM5WoSuRpF/0w4M55GL1Q= =FSrU -END PGP SIGNATURE- ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] OT: decryption
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Josh Babcock schrieb: OK, so I ordered some flight manuals on CD from eflightmanuals.com, but what they didn't tell me is that they send them in a proprietary encryption scheme for PDF files that requires Windows ME of later which I don't have. According to the encryption software manufacturers it is AES 256 bit (FIPS-197) Now, I have the key of course, the question is how would I go about decrypting it in the absense of the proprietary software? Oh, There is also a second key for the software, probably tied to the specific machine it will be run on, I think I can sniff this with snort. Did you try the lastes Acrobat Reader for Linux? You could also try to run the program under wine (www.winehq.org) CU, Chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (MingW32) iD8DBQFC7/IUlhWtxOxWNFcRAiHcAJ9LEHmPOkf1F7w7yYImcw5Ilmng6gCfVzTj oUCKFUajUor1Fho1B4Sq4iY= =vnoF -END PGP SIGNATURE- ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] OT: decryption
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Andy Ross schrieb: * Which, at least for the US airplanes, are government documents and therefore uncopyrightable. The only legal restriction on their distribution would be their security classification, AFAIK. IANAL, blah blah blah. Shouldn't you then be able to get these documents easily by the freedom of information act? CU, Chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (MingW32) iD8DBQFC7/QqlhWtxOxWNFcRAoczAJ9XI1DBSwsCLIbIYPHSCpHuAPGcvQCdF74Z E9Zyx4xUfV0ZEIaGVI3rxeA= =uesq -END PGP SIGNATURE- ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] sprintf
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Erik Hofman schrieb: Jon Berndt wrote: IIRC, sprintf was a problem for some. Is that still the case? I've compiled under Cygwin, Borland C++, and I think I've also compiled code that uses sprintf under IRIX. sprintf is C standard - and very unsafe due to possible buffer overflows. It shouldn't be used. The inofficial (i.e. there's no standard yet AFAIK) C solution is snprintf: The real problem was snprintf(...) which isn't availble under Winodws: #if defined(_WIN32) !defined(__CYGWIN__) #define snprintf _snprintf #endif The real cross platform soultion would be the C++ std::string CU, Chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (MingW32) iD8DBQFC5fY9lhWtxOxWNFcRAn5KAJ4/ymkStSRQcOrUbIUpqdRy6D11rACgsHYs iveF3b6qmM5Yz393cHfX5gs= =q0Yi -END PGP SIGNATURE- ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] sprintf
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Erik Hofman schrieb: Christian Mayer wrote: The real cross platform soultion would be the C++ std::string No, you can't format (the f in printf) the string using the default C++ string class). You have to use the I/O manipulators (Stroustrup: 21.4.6.2, page 633ff.) like std::setprecision(). Compared to the fast printf syntax they are too annoying to write and not that flexible, but they are more readable and they can be combined to your own user defined I/O manipulators. So you can write easily very readable code without the need to retype everything. CU, Chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (MingW32) iD8DBQFC5gE/lhWtxOxWNFcRAguhAKCmz+gYRTu9b+vBoJuLNDm6VJs+rQCfSznC v0iykSBU97YqOiobZru7qFE= =eMKQ -END PGP SIGNATURE- ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] [Fwd: licensing problems in SUSE Linux]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Andy Ross schrieb: Curt forwarded from Lukas Tinkl: we at SUSE recently stumbled upon this problem: some of the code contained in FlightGear contains a non-commercial lincese which forbids us from further distributing it. The consequence is that FlightGear wouldn't be part of the upcoming SUSE Linux release. SuSE is (or was, or would be) shipping FlightGear? I had no idea. SuSE was shipping it for ages. They were even advertising with FlightGear (under the Games section though - but it has changed: http://www.novell.com/products/linuxprofessional/games.html). Current links are: http://www.novell.com/products/linuxpackages/professional/flightgear.html http://www.novell.com/coolsolutions/feature/11290.html CU, Christian -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (MingW32) iD8DBQFC4QTXlhWtxOxWNFcRApuQAJ9j0kSEisw0KSsPjg2aTqlPdvnx0QCeJhla 30QjPd7K58FCIUtwMBYzIJs= =4Joa -END PGP SIGNATURE- ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: code optimisation
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jim Campbell schrieb: Hi, One comment and some documentation has indicted that FDM doesnt consume much CPU. I ask myself why? The modelling of a generalised rigid body with six degrees of freedom in a rotating frame of reference should max out anyones and everyones CPU! Calculating the updating 6 DOF is a real simple task. It only takes a few operations. It can be far more challenging to calculate change in the 6 DOFs. This can be done cheaply on the basis of functions / lookup tables (like the FDMs we use). Or it can be done by solving navier stokes equations at each timestep. This would max out the CPUs for quite a while (especially when it comes to direct numerical simulation - there are even current supercomputers maxed out for simpler tasks than the flow around an air foil) Oh, btw, we are currently updating our 6 DOF much more often than the image gets redrawn... I notice that JSBSim uses a simple single step method for integration whereas LaRCSim uses a multi-step method. Spare CPU could be utilised in doing a multi-step predictor/corrector integration with variable step size especially for more esoteric aircraft types with high speeds and high altitudes and even near orbital capability in JSBSim. I doubt that changing the integration method will cause any performance problem. So you might try it. But making delta t smaller also helps, so that might give you more precision for the time spend tweaking the code. And as we've got an interactive application I guess that the absolute error in the integration doesn't bite us. Any turbulence in the real world will change the position more than precision errors will (assuming perfect FDM parameters) CU, Christian -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (MingW32) iD8DBQFCzC7xlhWtxOxWNFcRAstrAJ9F5IodbEMqjrRUQxvOjDAEJAXR/QCgnxCD yavFP/qrqy1BScpH8FFzOEE= =saYF -END PGP SIGNATURE- ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Custom scenery integration
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Norman Vine schrieb: Martin Spott writes: I'm currently uncertain if we really can store the _whole_ scenery in PostGIS. Our elevation data currently comes as raster data but maybe it makes sense to convert that into contour lines - which we finally can store in such a database as well. Does this make sense, Norman, or will this eliminate our ability to alter the data with 'common' tools ? Why not just store the Elevation data in a mixed record type of a Polygon with a BLOB field ? I wouldn't store contour lines as you'll allways loose precision by converting the data (DEM - contour lines - triangle mesh). Beeing able to change the elevation data can be important, especially when you are puting a finer grid over the data. I dunno what is possible with PostGIS but the most intuitive solution would be to store additional elevation data on arbitrary positions. Then the resulting mesh could be calculated by a weighted average (using the 2D distance) of the cutom elevation and the underlaying DEM. CU, Chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (MingW32) iD8DBQFCyYSZlhWtxOxWNFcRAvW6AKCL/lc6zq4xuDtHKnE5bRMkjh9amQCdG9Vy 9e8Ihp/XgLydtYH5yEvSTbg= =pR6o -END PGP SIGNATURE- ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Shadows
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Frederic Bouvier schrieb: Another nit picking : When an object ( say a building ) is culled because it is not in the view, its shadow is also culled even if it is in the view. 2 screen shots : In the first, an oracle building cast its shadow on another one http://frbouvi.free.fr/flightsim/fgfs-shadow-1.jpg If I go forward a bit, the shadow disappear : http://frbouvi.free.fr/flightsim/fgfs-shadow-2.jpg The FOV is exagerated because it is not easy to pause exactly when it happens, but you can clearly see the shadows poping in and out when you travel between buildings. Most likely the SSG has removed the building out of the scenegraph... CU, Chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (MingW32) iD8DBQFCwHLLlhWtxOxWNFcRAhzrAJ9fjl0DaxjNbwFQpfSnk1aO2zd9vACaAhnD GiO2/o8l3PU+2tZ0sX9phiY= =UN7y -END PGP SIGNATURE- ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] AI Ships
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dave Culp schrieb: If this is in regard to the AI ships driving onto land, the AI ships and AI carrier can accept a flight plan, but the ability to follow the flight plan has not yet been implemented. I won't be hard to do. Once that is done, the carrier will follow a pre-defined path, and stay off of land. There are then two options: 1) make a race-track pattern 2) go straight to the flightplan end, then vanish and reappear at the start (like in the movie :) Of course option 1 is more realistic, but the ship will be going in the wrong direction over half the time. Option two would give you more fun with your entertainment dollar/euro, but you don't want to be on the ship when it teleports to the start again. If you specify a path that ends where it starts, number 2 becomes the best and realistic choice. CU, Christian -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (MingW32) iD8DBQFCqGEIlhWtxOxWNFcRAn0qAJ9tMzweZKmKzG3t3KeL07UZ1mJZ9QCfcqzC PRf28OxFdc+ZD+iIz3bk9Kk= =qrNK -END PGP SIGNATURE- ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] batteries, alternators, volts, amps - electrical system
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Paul Surgeon schrieb: Just some general info that may or may not be useful. General aviation batteries : Typically lead acid Commercial and military : Typically Ni-Cad (nickel cadmium) [...] On the battery side of things the discharge and charge rates are not going to be easy to model. Maybe a simple approximation using a lookup table will do as an interim measure. I *guess* that the battery charging is slow enough that it can easily be modelled as an ideal power source plus resistor (the internal resistence; sp?). So you'll still get an set of linear and not differential equations by Kirchhoff's law. CU; Christian -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (MingW32) iD8DBQFCni4slhWtxOxWNFcRAvWiAJ9p5ZVBhNy3wXEAyyS22lHaaIhJywCgqip3 KAQpYW0Ls+544nSEcml5cGw= =/++3 -END PGP SIGNATURE- ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] batteries, alternators, volts, amps - electrical system
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Curtis L. Olson schrieb: I need to do some work beefing up our electrical system model a bit. I'd like to add a simple model for a battery where output varies with time and a simple alternator model where output varies with rpm. I'm a complete moron when it comes to electrical stuff so I'm not even sure I'm asking a sensable question. Does anyone know of a good online reference(s) or even just send me some reasonable info. In the end I'd like to be able to be able to output bus voltage (downstream of the battery + alternator) and also model an ammeter. I already have a way to back propogate the total current draw on the system, where the individual electrical system outputs can be marked with some current draw when they are on, however, I need to work on the input side of the equation. Again, I want to start pretty simple and not get drug down with too fancy of an implimentation. All you need is Kirchhoff's law (e.g.: http://en.wikipedia.org/wiki/Kirchhoff%27s_circuit_laws) If you can live with a stationary current (i.e. no dynamic effects) it boils down to solving simple linear equations (Ax = b). If you need dynamic behaviour (what I doubt) you'll get partial equations... CU, Christian -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (MingW32) iD8DBQFCnOqklhWtxOxWNFcRAv7fAJ9sHLh30zOaY151Vypo/wqBRqXCkgCfbCh2 +Faa6DFVVvP71jrablW2Syc= =3wiv -END PGP SIGNATURE- ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] game engines (ghours)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Erik Hofman schrieb: eagle monart wrote: eagle monart a écrit : hi everyone, is there an idea of switching to another open sourcegame engine. fg is real beatiful but is weak in visuals especially in terrain rendering.we cant edit terrain as whatever we want , we cant change textures and terrain is not complex. as a result cant feel realistic environment and relative speed. even combat simulator project have better graphics by using osg. Hello Is it Provocation ?? sure it is nota provac,! In fact we have been thinking about this multiple times in the past. There is one problem, the task is *huge*. Maybe some day it will happen, for now we have something that is working pretty well. And since this project is *not* a game we can live with what we have now. One of the greatest complexities the we tackle is a world wide coverage for the scenery. All games (including all combat simulators) model only parts and thus can apply extreme simplifications (e.g. assuming that the world is flat). If you want to improve the optical apperance - which would be really great - you should try to work with the existing mechanims and not trying to replace them (especially when you hardly know the source code...). CU, Christian -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (MingW32) iD8DBQFCd9YFlhWtxOxWNFcRAhoOAKCbcfWDXN1Fy5VqEeJTh9nX+XShzACeIspg MRgJqASVxj8vB/5CmOuebkM= =qjP2 -END PGP SIGNATURE- ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [Flightgear-users] Re: Okay ... who was it?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ampere K. Hardraade schrieb: Putting all the above into a fatigue-routine or a fatigue-class, we can make a call to it everytime the aircraft makes a contact with the ground. We can make a call to it every second, too. Afterall, aicrafts can disintegrate at any time. This reminds me of Flight Unlimited an old DOS based sim (it had the best graphics at its time). There you could heare the stress on the structure (some plaes had a G-force meter, too). And when it got too extreme the plane disintegrated in the air... CU, Christian -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (MingW32) iD8DBQFCF7jPlhWtxOxWNFcRArX7AKCawYU26hbggH4lukRGtHWM2A6ZeACfUwVI UCv0Zj0wwqS3yOVVoOdtJas= =PAV6 -END PGP SIGNATURE- ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: [Flightgear-users] Re: Okay ... who was it?
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Melchior FRANZ schrieb:
* Christian Mayer -- Friday 18 February 2005 17:22:
Melchior FRANZ schrieb:
http://members.aon.at/mfranz/exhibit_A.jpg
Ups, it happend again. Lasttime was the victim of my engines smaller
though (http://www.lfa.mw.tum.de/Lehre.html)
lol. The reason for my incident was this:
$ awk -vr=.1 '//{if(i){i--;print$1+rand()*r $2+rand()*r $3+rand()*r}else
print}/^numvert/{i=$2}'in.ac out.ac
This reminds me, that we don't have a nice crash simulation yet. (It
doesn't need to be realistic).
We probably could do this, when an crash occures:
1) switch to external view (that should be easy)
2) split up the scenegraph of the model and solve a simple motion
equation for the parts (so that they bounce on the ground - that needs
a heavy damping though)
3) put a fireball in the middle
The result isn't realistic but much nicer than the current approach
(it looks more like an arcade game though...)
Step 1 and 2 shouldn't be too hard to do with the current code.
CU,
Christian
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.0 (MingW32)
iD8DBQFCFimylhWtxOxWNFcRAq1NAKChMUVMJebDmVOBQCUCX8SWkgvn1QCgue7R
LEd6RG5QDJ8VIzULoExCsgw=
=DYcC
-END PGP SIGNATURE-
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Curiosity about antialiasing
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ampere K. Hardraade schrieb: At the moment, is antialiasing applied to textures themselves? If so, what will happen if antialiasing is applied to the final render/output instead? Technically the textures, as they are displayed, aren't antialiased (that doesn't make sense) but they are bilinear, or even trilinear filtered. The result are smooth textures (in such a way as you'd expect it from antialiasing). The content of the textures (i.e. the raw texture image) is as much antialiased as the texture designer did it during creation. (I think we are quite optimal there) Antialiasing itself can only be applied to the final output. There are 2 different ways: - - normal antialiasing: it's relatively fast and smoothes the lines/edges - - full screen antialiasing (FSAA): the the whole scene is basically renderd at a much higher resolution and finally scaled down for display. This technique is realtively slow as it needs huge data transfer rates on the graphics hardware. These antialiasing settings can usally be changed at the graphic card driver. (I dunno if FGFS offers to change that seting itself) CU, Christian -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (MingW32) iD8DBQFCCzkPlhWtxOxWNFcRAoShAJ9F+LfO6Iz/rmEYiGKHNN19fMI2BwCggrdt nWGZRShmpoO0GX0jq0hJTdk= =Ybqh -END PGP SIGNATURE- ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Qt 4 will be GPLed for all supported systems
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, I've just read at the Heise Newsticker, that Trolltech is planning to release the next version of Qt for all systems (including M$ Windows) under it's dual license. = We can start to use it!! :) The attached text (including the reasons their marketing people see for OSS to use it) was also posted there... CU, Christian Dear Qt User/Qt Customer: Trolltech is pleased to announce that we intend to make Qt 4 for Windows available under our successful dual licensing business model. This means that Open Source projects under the GNU GPL license will be able to target all major operating systems using Qt 4. We plan to release the Windows Open Source version of Qt at the same time as Qt 4. What dual licensing means = Qt's dual licensing model is based on the principle of fair exchange. If you are using Qt commercially - that is, for creating proprietary software for sale or use in a commercial setting - you must purchase a commercial license from Trolltech. Alternatively, if you wish to write Open Source software you can use the Open Source version of Qt, released under the GPL. If you use the Open Source version you must release your application and complete source code under the GPL as well. This model has proven successful for a number of leading companies such as MySQL and Sleepycat, and has been important to the success of Qt on the X11 and Mac OS X platforms. For more information on Trolltechs dual licensing business model, visit http://www.trolltech.com/company/model.html. What this means for Trolltech customers === The need for customers to hold commercial licenses for all commercial development will not change. However, the extension of the dual license model to Windows will mean that both the pool of available talent and the number of innovative Qt-based applications on Windows will increase. Also we expect that Open Source users will contribute valuable feedback and quality assurance for the Windows version of Qt, just like our X11 and Mac users have in the past. The commercial version of Qt will contain a number of product elements that only commercial license holders will have access to, including: - - Trolltech support - - The opportunity to purchase access to Qt Solutions - - Commercial compiler support - - Prebuilt Qt binaries (the GPL package is source only) - - Commercial database drivers Finally, we believe that Open Source users who have been exposed to Qt will choose the commercial version of Qt for their commercial work, thus boosting Trolltech's revenue and making more resources available for development and improvement of the product. What this means for the Open Source community = The Open Source movement has contributed huge amounts of innovative, highly useful software. Numerous well-known Open Source projects such as Apache, Mozilla/Firefox and KDE have helped redefine the landscape of computing and have propelled Open Source from a niche phenomenon into a mainstream movement. By making Qt available under the GPL license on Windows, Trolltech has given cross-platform Open Source projects the option of jump-starting their Windows development, using a mature, feature-rich framework that is consistent across platforms. Open Source developers can spend more time developing and refining functionality and less time on fixing and debugging underlying architecture. How Trolltech will enforce licensing We depend on revenue from the commercial version of Qt in order to develop and enhance new versions. It is therefore imperative that users of Qt understand our licensing and choose the correct license for each project. To determine which license you require, please visit http://www.trolltech.com/products/qt/licensing.html, or contact a Trolltech representative directly. We kindly request our customers and users to ensure that they are in possession of the appropriate number of commercial Qt licenses. It is possible to find out if an application has been created using Qt. Trolltech is prepared to take steps against misuse of the Open Source version for commercial development. Availability, timing and further information We plan to release the Windows Open Source version of Qt at the same time as the final release of Qt 4.0. For more information, please refer to the Windows Dual Licensing FAQ on http://www.trolltech.com/developer/faqs/duallicense.html Best regards, The Trolltech Team -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (MingW32) iD8DBQFCB7ielhWtxOxWNFcRArtvAJwJB6iNXlAhwqsHvHT3Pz0ioyqYZwCeL3PE 64pWwTcBQnGVw1j/o1EXIz4= =Idq2 -END PGP SIGNATURE- ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] STL help requested
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
David Luff schrieb:
Hi folks,
I've run into a tricky problem when using stl map, and am hoping someone
might be able to point me on the right direction.
I have a map of airports, indexed by string, which is the ICAO code:
mapstring, ARP* apt_map;
Now, I want to emulate the 'search ahead' function of GPS code entry, so
that, for instance, entering KC will cause KCAD to be displayed - the
first airport in the database starting with KC. To do this I use the
lower_bound function, for both KC and KD. If the returned iterators
don't match, then there is a valid match for KC.
mapstring, ARP*::iterator it1, it2;
it1 = apt_map.lower_bound(KC);
it2 = apt_map.lower_bound(KD);
return(it1 == it2 ? NULL : it1-second);
So far, so good. Now, the problem is that the KLN89 (and probably most/all
GPS units) regards A-Z as coming before 0-9, whereas the standard string
compare function regards 0-9 as coming before A-Z. So in this instance I
might get KC52 displayed instead of KCAD (there isn't really a KC52, but
there are many examples outside the US where this bites).
Now, I can get round this by using a comparison of lower_bound tests for
KC, KCA and KD, and it works. Unfortunately I then have to check for
non-alpha chars down to the end of the returned string, and re-test any with
'A' substituted in place. It's effective, but really ugly! I had to think
quite hard about code I only wrote a week ago to compose the last sentence,
and that's always a bad sign. What I'm sure I ought to be able to do is to
define a custom comparison operator that performs a string comparison where
numbers are considered to come after letters, and for good measure to do a
case-insensitive match on the letters. I want to be able to do something
like:
it1 = apt_map.lower_bound(KC, gps_less);
with all the ugly bits tucked away in gps_less which I can get working and
them forget about. Unfortunately, I can't find any good example in any of my
books to do this, nor on the internet, and everything I try is giving me
swathes of typical gruesome-to-mentally-parse stl error messages. If anyone
has an example of how to do this, or any pointers to one, I'd be most
grateful.
The C++ Programming language 3rd ed. tells me:
Basically you've got 2 options:
1 - create a class with the operator
class IACOcode
{
string the_code;
}
bool operator( const IACOcode a, const IACOcode b )
{
return your ordering;
}
mapIACOcode, ARP* apt_map;
2 - create a custom sort order
class IACOcode_compare
{
public:
bool operator()( const string x, const string y) const
{
return your ordering;
}
}
mapstring, ARP*, IACOcode_compare apt_map;
Then you'll automatically get the desired result with your described lookup.
CU,
Christian
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.0 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFCBAAwlhWtxOxWNFcRAvoUAKCQmu/HJmzAQ6OZCLwCPJXoNLalPQCfSKB3
TBEVeGwmDCjOwegYbvbj8AQ=
=mohP
-END PGP SIGNATURE-
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Runway lighting - What happened to the new terrain engine?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Manuel Massing schrieb: Hello, I do have a few questions though : Does the current code that you have handle texture paging? Yes, textures and geometry are paged and decompressed asynchronously in the background (seperate thread). The engine supports image compression to save IO (and possibly bus) bandwith, e.g. JPEG and S3TC compression. The first maybe quite taxing on the CPU, so we usually only use JPEG for the finest detail level textures, which account for most of the data, and S3TC for the lower detail levels. Do you know: http://www.sjbaker.org/steve/omniv/jpegs_are_evil_too.html CU, Christian -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFB+2tolhWtxOxWNFcRAhSsAJ9M+L4LFk/hCluZyd25wqn6NI1BywCfVZ2a g+aaUNBAv2s4EQtKHYHQ66I= =yPwY -END PGP SIGNATURE- ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Runway lighting - What happened to the new terrain engine?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Paul Surgeon schrieb: On Saturday, 29 January 2005 12:54, Christian Mayer wrote: Manuel Massing schrieb: Hello, I do have a few questions though : Does the current code that you have handle texture paging? Yes, textures and geometry are paged and decompressed asynchronously in the background (seperate thread). The engine supports image compression to save IO (and possibly bus) bandwith, e.g. JPEG and S3TC compression. The first maybe quite taxing on the CPU, so we usually only use JPEG for the finest detail level textures, which account for most of the data, and S3TC for the lower detail levels. Do you know: http://www.sjbaker.org/steve/omniv/jpegs_are_evil_too.html There's still no open source alternative to jpg when it comes to storage size and storage is the major issue when dealing with lots of satellite or aerial photos. I did a test with the 18 century crop texture : JPG : 1024x1024 @ 85% quality = 508.4 KB PNG : 512x512 @ level 9 compression = 630.4 KB Four times higher resolution with hardly any noticable loss in quality (even when zoomed in) and it still comes out with a smaller footprint than a PNG that is 4 times lower resolution. Sometimes size does count. What do you suggest as a replacement to JPG that will give a similiar footprint size? (I haven't read the Jpeg2000 stuff, so I don't know if it fixes the problem) The trouble with JPEG isn't that it's lossy (you need that for hight compression ratios) but that it uses an algorithm that is tuned to the human eye. For normal photographs that's great - for textures that get scaled, projected, sheared (sp?), lit, ... the uses assumptions dodn't hold anymore. An extreme example: when you use a very high compression rate you'll see the blocking artefacts. So you use a not so high compression and are hapy with the result. If you zoom into the picture you'll start to see the blocking again as the pixels got large enough. When you use that picture as an texture and fly low enough you are basically zooming into the picture. Same problem as above. So JPEG isn't usefull. So what's the solution? 1st: I don't know. 2nd: Use an compression that doesn't introduce visible artefacts (i.e. artefacts that can be shown by zooming, projections, lighting, etc.) One solution that might work could be wavelets. (This is where JEPG2000 gets interesting again). But the wavelets used would need to be choosen carefully. You could also try your own compression format (i.e. one that is simmilar to the wavelet approach). Roughly do: Convert your image/texture to HSV, convert the whole picture (not small blocks like JPEG) to frequency space (i.e. fourier transformation). Then discretisize that values. In our case the high frequency are very important (- high resolution) and the low frequencies hardly matter (- just a few bits). But doing this is an project of its own. Epecially when you need performance... CU, Christian -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFB+4tRlhWtxOxWNFcRAmbmAJkBh9SWIogEMkNpJoVo/9btWjvxnwCgl2Pq lbln/KQ9xim9VXVZ3eI0p2Y= =zpQm -END PGP SIGNATURE- ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Atlas release candidate
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Lee Elliott schrieb: Hello Dave, I'm using an ATI 9200 vid card with ATI's drivers and I'm getting: Seaching for extensions... GLX_SGIX_fbconfig: NO GLX_SGIX_pbuffer: NO One or more required extension(s) could not be found: GLX_SGIX_fbconfig GLX_SGIX_pbuffer Unable to continue in headless mode - revert to doublebuffer mode? [Y/n] I've just looked up the ATI documentation on OpenGL extensions: http://www.ati.com/developer/atiopengl.pdf There they state that they support WGL_ARB_pbuffer for all interesting Radeon versions (not under NT4 though). GLX_SGIX_pbuffer isn't mentioned. The doc also doesn't mention any extension with fbconfig. Is it possible that other extensions should be used? CU, Christian -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFB+6AWlhWtxOxWNFcRAnG7AKCmv1nrPwXZhtDtoNYopq/50jJQyACaA8Ea qRLGJvnJBX7lfCrEnklBqws= =mZ7N -END PGP SIGNATURE- ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Runway lighting - What happened to the new terrain engine?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Andy Ross schrieb: Christian Mayer wrote: Manual Massing wrote: Yes, textures and geometry are paged and decompressed asynchronously in the background (seperate thread). The engine supports image compression to save IO (and possibly bus) bandwith, e.g. JPEG and S3TC compression. The first maybe quite taxing on the CPU, so we usually only use JPEG for the finest detail level textures, which account for most of the data, and S3TC for the lower detail levels. Do you know: http://www.sjbaker.org/steve/omniv/jpegs_are_evil_too.html Honestly, Steve is just wrong on this one. Lossy compression works just fine in moderation. The S3TC format itself is a lossy algorithm that is inferior in quality to JPEG in basically every conceivable way, and it's supported navtively by the texture hardware for goodness sake. I'm not against lossy compression. But JPEG hasn't the best algorithm for our use. JPEG2000 might, but I don't know enough about it. Yes, using JPEG as an intermediate format during content creation is a dumb idea due to progressive data loss. Refusing to use it for final/shipping textures based on this advice is just dumb. Real-world 3D applications and games ship their images compressed with lossy algorithms. Usually is any lossy format for inbetween dumb. Has anyone actually looked at how much of the base package is taken up by SGI+ format image files? (Which have absolutely abysmal compression ratios, but that's a different argument.) I wrote a quick script at one point to recursively convert all these to default-quality JPEGs, and the savings was staggering. Something like a 75% reduction. This a point for lossy compression, not one for JPEG... One important point to remember is, that every lossy compression can compresse some data exact (the decompressed data...). So when we find a compression algorithm that creates decompressed data that is good enough for us, we can use it (even when the compressed data is in JPEG format). For our case that compressor must not rely on special optical tricks (because these get destroyed when they are used as an texture). If we find an JPEG compressor that fullfills this requirement, it's fine. If we don't, we need a different format. (If we find one, there's still a possible problem: people who don't know this special requirement are likely to submit wrongly generated files...) As only these special cautions allow one to use JPEGs, it's much saver to say: kids, don't try that at home! CU, Christian -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFB+9HDlhWtxOxWNFcRAp0QAJ9MHzxlU0dvXQjIoOtBWXT3jtoz+gCfbliO bUCWTF+HZdZs7as8h3NWwv8= =1us6 -END PGP SIGNATURE- ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Runway lighting - What happened to the new terrain engine?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dave Martin schrieb: On Saturday 29 Jan 2005 17:39, Frederic Bouvier wrote: Has anyone actually looked at how much of the base package is taken up by SGI+ format image files? (Which have absolutely abysmal compression ratios, but that's a different argument.) I wrote a quick script at one point to recursively convert all these to default-quality JPEGs, and the savings was staggering. Something like a 75% reduction. It is still true that JPEG have no alpha channel, so not all textures could be converted. -Fred So on the same merit, how about PNG? On average you get about 1/3 the size of the SGI file while still being loss-less and keeping the alpha channel. PNG are fine (and should be our first choice as they are perfect for most of our textures) - but they aren't lossy. So you'll never get as good results as JPEG / JPEG2000 / ... will give you. CU, Christian -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFB+9KelhWtxOxWNFcRAtgQAKCAT7HN4HeupuKrKdu0U9b6a++oMQCgj0kf HYSTy3j8bK6+nq849z0VEoI= =yHvY -END PGP SIGNATURE- ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] fgrun improvements
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Frederic Bouvier schrieb: Erik Hofman wrote : Frederic Bouvier wrote: This is in CVS now ( should show up in a few hours on SF ). In the meantime, a screenshot : http://frbouvi.free.fr/flightsim/fgrun-basic.jpg If you're going this path (and it certainly does look good) then you might want to consider removing the command-line textbox altogether. It might look a bit daunting for a new user. Is there another path ? At least people are able to see immediately the result of their actions as the text is refresh in realtime. The latest screen shots looked like a good solution. An alternative (which I thougt of, before seeing the current implementation) could be to add an button that opens a pop up with the command line. An also quite important point (dunno if it's already implemented) are descriptions for the options. I wouldn't know what Horizon effect would change in FGFS. Is it possible to have bubble-helps for that? Keep up the good work! CU, Christian -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFB9Mf0lhWtxOxWNFcRAmwIAJ9cAt1g3wOQ60mIO4McUMeHODdxnACePmP5 Fh6rU9fWC1Esz0Gesn8JnsI= =Kqe/ -END PGP SIGNATURE- ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Model animation
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dave Martin schrieb: Also, I was actually thinking about Wind Turbines earlier today; are you having them face into-wind and altering the rotation speed depending on windspeed? They don't vary that much in real-life (they are governed) but obviously they stop at a certain point. There are 3 possibilities - - wind is too slow: the turbine doesn't turn (I don't know the direction they are facing, probably directly to the wind) - - wind speed is right: the turbine faces the wind and turns - - wind speed is too high: the turbine doesn't turn and it's turned away from the wind (90 deg angle) When it turns the rotational speed is probably constant as the blades can be twisted IIRC. CU, Christian -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFB9MkHlhWtxOxWNFcRAmUZAJ9TWZEtQRnnEMez+B6SX/SVsMDvLwCfYuQd vIotR/+Tc8h41JfGpByCqwI= =G0eC -END PGP SIGNATURE- ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Model animation
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Martin Spott schrieb: Christian Mayer wrote: There are 3 possibilities This is a bit different from the wind turbines we have near EDLN (Cologne area). If the wind is too high they feather their blades but still are being turned to face the wind - I think this is being required by the layout of the hub structure. When the wind is 'right' they rotate at a speed that is depending on the wind speed. The conversion into alternating current of a fixed frequency is being done electronically already for a looong time. I think this applies to almost all German and Dutch wind turbines that _I_ have ever seen (and I'm already in the mid-thirties) - not that I claim to have seen all wind turbines in our country :-) Martin. Ok, I had a look at wikipedia. The german article is quite large and has a bit more information than the english one. The most interesting bits for a model would be: The highest efficiency is, when the tips of the blades run 8 times faster than the wind speed. Energy is produced in the range from 2 - 4 m/s to 25 - 35 m/s. Below it's not efficient enough and the generator is cut from the net. The rotor isn't braked though as it would produce too high forces (so it rotates very slowly) Above the speed it depends. Some turbines adjust the pitch (but still face the wind) and others are turned out of the wind and their rotor is fastened by a brake. Modern turbines have a extra storm regulation that allows them to work during a storm with reduced efficiency Basicly the article said that every regulation that we can think of was used somewhere... So we hardly can produce a modell that is totally off... CU, Christian -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFB9PHklhWtxOxWNFcRAmJgAKCbJTMLbZP5rSca97b629hsnmkRyACgnnWu PF5XfcS4bi9l0w94N1RdfFc= =reqJ -END PGP SIGNATURE- ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] FlightGear 0.9.8, Mac OS X build
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Erik Hofman schrieb: Christian Mayer wrote: As religions differ greatly around the globe (even in the countries themselfes) there'll people who helped with their work that have their belive at least not represented (and probably even are offended by the content) It almost makes me want to some citations from James Bond (as described by his godfather Ian Fleming) and the holy spirit (shaken not stirred) which undoubtedly will be the next religious trend due to the spectacular ways he hes been saving the world. LOL!!! CU, Christian -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFB8MtxlhWtxOxWNFcRArlDAJ9aAQjKvTp94uFff69iCYteC/zNdACfWLD+ WPGBEjB9oLtBs5yHuFfDkR4= =8PGn -END PGP SIGNATURE- ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] v1.0 musings (was: Aircraft included in basepackage)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Giles Robertson schrieb: 1) Fgrun/fgfs. For the average windows user, this is *highly* counterintuitive. In so far as Windows has an overarching user interface and tool design philosophy, it's integration. The concept of a GUI that launches the program doesn't make sense to them; they expect to be able to run flightgear, and for it to present a menu that reads something like New flight/Saved Flight/Options/Exit. I'm not saying this is the way we should go, but I'd like to note that many users, when presented with the current method, get *very* confused, especially by the absence of a flight planner. Many also find restarting FlightGear in order to change aircraft counterintuitive The first point is argueable. But that we need a restart just to change planes is a big show stopper! Your other points are valid. But none are thus counterintuitive than the need to restart FGFS. CU, Christian -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFB8NRUlhWtxOxWNFcRAphiAKCV0GNXaKkeU5qVRex8FDJtvntPNwCgsg5Q /oeR83fj089dFTSe1B2eIGQ= =bsh8 -END PGP SIGNATURE- ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] v1.0 musings
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Erik Hofman schrieb: Christian Mayer wrote: The first point is argueable. But that we need a restart just to change planes is a big show stopper! It depends on the goals for 1.0. If you want a version that is easy to use for the end user then you might be right. If v1.0 is aimed for a completely working standalone simulator program (maybe even certified) then it's not such a big deal. I guess the 1.0 release is aimed at the first though. To get it certified the version number itself doesn't matter. But an end user sees the version number as an indicator if the software is ready or not. And that's what will be used to measure us. A version 1.0 *must* have an ergonomic UI. CU, Christian -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFB8NlslhWtxOxWNFcRAu2RAJ0SEqv1eMvtnsDANJllLqBGGwJ/XgCeLC+O T5DjbmK+pBaTGfSgTCMvqmo= =TJNa -END PGP SIGNATURE- ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] FlightGear 0.9.8, Mac OS X build
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Christian Brunschen schrieb: Hi, The Mac OS X build of FlightGear 0.9.8, as available from http://prdownloads.sourceforge.net/macflightgear/FlightGear-0.9.8.dmg? download, contains a file called 'How to Get to Heaven.rtf', at the root level (beside the OpenAL installer package and the FlightGear application directory), with bible quotes and essentially religious proselytizing. Here's a screenshot of the Mac OS X Finder window for the FlightGear-09.8 disk image: If that's the case I'm *strictly* against it. Religion is an even much more problematic field than politics (which already creates bad flame wars). People easily get upset when they are presented by the truth, which isn't their truth they believe in. So, IMO, this is against the spirit (doesn't that word sound funny in this context?) of FGFS. Just two quotes from the Introduction page: - - It is being developed through the gracious contributions of source code and spare time by many talented people from around the globe. - - There are a wide range of people interested and participating in this project. This is truly a global effort with contributors from just about every continent. As religions differ greatly around the globe (even in the countries themselfes) there'll people who helped with their work that have their belive at least not represented (and probably even are offended by the content) CU, Christian -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFB7+cQlhWtxOxWNFcRAvkSAKCnwDx4oyxcTK6uBaecNmYipwE6ZwCeKrBH yIbz1BI27yzyw/ufNaIzbwM= =BbVC -END PGP SIGNATURE- ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] C++ question - solved
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Thanks for all the replies.
They brought me on the right track.
The solution I've got now is also known as the Barton and Nackman Trick.
It's a bit pervert - but totaly legal C++ code:
templatetypename leaftype
class A
{
leaftype asLeaf()
{ return static_castleaftype(*this); }
public:
bool foo( leaftype bar )
{ return asLeaf().foo( bar ); }
};
class B : public AB
{
public:
bool foo( B bar )
{ return /*...*/; }
}
The Barton and Nackman trick is important to avoid virtual function
where they are too slow (i.e. when the additional pointer lookup hurts
performance)
CU,
Christian
Paul Kahler schrieb:
It sounds to me like you should just drop the virtual function
declaration in the abstract A class (or make it non-virtual). It
serves no purpose other than trying to enforce your design on the
subclasses. Since you require the foo() function to take a parameter of
the subclass type, only a B can foo a B, and only a C can foo a C. Let
us not use complex language constructs (templates for example) just to
allow the compiler to check that you're following your own convention.
Put a comment in the base class that defines this requirement on
subclasses and call it a day. OTOH, if generic code is going to tell an
X to foo another X (somehow knowing they are the same type) this might
not work. H. I think another option is to declare A:foo(A p1) and
then have the B class explicitly cast the parameter p1 to a B inside
B:foo when using the B-specific functionality of the parameter. I don't
know how to do templates, so this is what I might do until it got too
ugly.
Hope that helps,
Paul
On Sat, 2005-01-15 at 15:12 +0100, Christian Mayer wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
can someone help me to solve thise problem:
Imagine I've got this class hierachy:
class A
{
virtual bool foo( A bar ) = 0;
}
class B : A
{
bool foo( B bar )
{
...
}
}
int main( void )
{
B foobar;
}
this won't compile as my class B is still abstract as I didn't provide a
bool foo( A bar ) member.
But I only want class A to be an interface that tells everybody what to
expect from it's derivated classes. And one of these things is, that
every child must have a member that is called foo and has one
parameter of the type of the child itself.
How do I achieve that?
The only workaround I can come up with is, that I have:
class B
{
friend bool foo( class B, class B );
}
bool foo( class B bar1, class B bar2 )
{
...
}
I this doesn't guarantee me, that every child of A must have a foo
function...
Thanks,
Christian
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.0 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFB7nR5lhWtxOxWNFcRArQdAJ9CFcrVXvlEeUszuzoRmbB/ACJU6wCfdsSA
RYAAKsDENV2fQj0Qn5d2KpE=
=pyGn
-END PGP SIGNATURE-
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] A380 - Virtual Screen inside Flightgear driven by SVG commands?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Oliver C. schrieb: Is it possible to implement a sort of virtual screen (like a texture but vector driven not bitmap driven) inside the Flightgear Window that can be put anywhere in the flightgear 3d world, for example inside of a cockpit as a instrument display. Flightgear should then offer this screen to outside applications and do the rendering but the commands what should be rendered is given by the outside application which are running outside of flightgear? In principle it is possible to set up the current OpenGL context to draw to an limited area and allow a plug in to render there. But - probably - the better solution is to have the plugin code to render to an off screen texture and use that dynamic texture as an instrument. I guess that that would be faster (no big changes in viewports, etc) and create higher quality graphics (z buffer fighting, etc.) The commands that are sent to flightgear should be simple 2d vector primitives, to make sure that this solution is flexible enough to display everything. FlightGear receives the 2d vectors primitives and put those on a virtual screen inside the FlightGear 3d world. For example a screen display in the cockpit. This is a totally different kind of problem. If the plugin is written in C/C++ it should use OpenGL (OpenGL is fine as a 2D library and there's no need to slow it down by wrapping it). If the plugin is writen in NASAL then NASAL would need an OpenGL like extension. That is - I guess - not hard to do. But - I guess - it'll be too slow when the graphics gets complex. I think the best would be, to add the OpenGL extension to NASAL (for flexibility) *and* write the more complex things in native C/C++ and add those to NASAL as well. Doing it this way would allow to do the complexity of such glass cockpits outside of flightgear. As long as the interface to FGFS is clear and easy it doesn't matter where the code lives. And if we change atlas from bitmap to vector graphics we could just sent from atlas the 2d primitives that flightgear could than render on a virtual screen inside flightgear. Atlas is basically vector graphics. It tries really hard to generate the bitmaps... As a 2d vector describing language we could use SVG. FlightGear then needs only a SVG parser that puts the visuals on a screen inside flightgear. Atlas can already create SVG. (Or it could when I added the SVG output a few years ago...) There are allready SVG libarys available that do render SVG primitives in OpenGL, maybe we could use such a library instead of writing an own SVG parser. I don't think that that sould be a good solution. It would be *much* better to use the geometry data that FGFS has already loaded to the graphics hardware as it needs it for scenery. CU, Christian -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFB7T/WlhWtxOxWNFcRAiQsAKCJqY6Q7E2gsS2Az03sUc53m1KolwCeN7SO lVMlMQ+XsB8E9b5VaWeOJ0M= =ojF9 -END PGP SIGNATURE- ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] A380
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Paul Surgeon schrieb: Running Nasal code in the rendering loop to do tons of work would not be a very good idea in my opinion. I've looked through an A320 FCOM manual and it would take many thousands of lines of C++ to accomplish a half functional aircraft. I don't think Nasal is the tool for the job. What I would need to create a aircraft with glass cockpits is : 1. A way to code self rendering OpenGL intruments. i.e. The renderer loops through the intruments and lets them do their own rendering. As I wrote in the other mail I think we need to explore how to render to an texture and use that texture in an instrument. Then it's no problem to write C/C++ code that renders (a part of) an instument to that texture. This could then be added to NASAL (plus some basic OpenGL commands) to create a full MFD out of these bulding blocks. 3. A generic communications bus that can be used to hook instruments/switches and the blackbox together. Using a handful of sockets is not a good way to do it and properties maybe be a bit messy and I would require hundreds of them. Why not use the property system for that? So far I found the property system very good for unidirectional communications (I'm responsible for system foo and tell everybody that it is in the state bar). But I couldn't solve a bidirectional point-to-point communication with it (I need from system foo the state of bar at position lat/lon somewhere on the world) - but it doesn't sound that you need such a capability. CU, Christian -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFB7UHQlhWtxOxWNFcRAgHDAJ0cazzJtFS+2SS04x2SyEUrpMEuOwCgsWQi AalCWiCgYBHCwUl6t94ZtcU= =7qmi -END PGP SIGNATURE- ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Aircraft downloads
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, the web page is comming along nicely! There's one thing that could be added: when you click on the thumbnail a normal sized picture should open. It also would be great if there'd be a thumbnail of the cockpit for that plane as well. CU, Christian -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFB7Xn9lhWtxOxWNFcRAsK7AKC9BXKP7D84/fDG7lGHV2z6S7wHrQCgvcS/ IatYStdya8WuDCb5aH7inWM= =vtLk -END PGP SIGNATURE- ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] A380
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 When do we have a flyable A380? It can't be that Airbus was faster than we are: http://slashdot.org/articles/05/01/17/0437202.shtml?tid=126 CU, Christian ;) -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFB7AlIlhWtxOxWNFcRAlQKAKCO+J7EqUc0eF3kBJhlvNdnP/xb8wCeNhG6 zdXCZkS5mcZDFCftXWtn5J0= =3F6S -END PGP SIGNATURE- ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] more google adds
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Curtis L. Olson schrieb: I did another round with google adds today and here's what I've come up with which seems (to me) like it could work out. 1. No adds at all on the main/front page of our site. Adds only on the subpages. Sounds fair 2. I've had mixed results filtering out MSFS stuff, but that's mostly because there is a lot of it. I think if I continue to add sites to the filter rules, I can get most of them. I've looked at the different pages. The ads are mostly the same - and of good quality (i.e. no advertising for other sims; the ads are for interesting stuff) The only ad I didn't like was www.ebay.de PC and video games can be found here cheaply reasons: - - if I want to visit ebay I'll do it directly, so the ad is taking away space - - at ebay you'll find MSFS and not flightgear... - - personally I don't line their aggressive marketing policy (they tolerate search engine spamming; probably they are supporting it even) CU, Christian -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFB6jU/lhWtxOxWNFcRAgYvAJwISfMkfTIlLigRo36Q+xb0VdVd9gCglEof B6XX61+j4wxqXD3QvYQYlDQ= =yZa7 -END PGP SIGNATURE- ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] C++ question
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
can someone help me to solve thise problem:
Imagine I've got this class hierachy:
class A
{
virtual bool foo( A bar ) = 0;
}
class B : A
{
bool foo( B bar )
{
...
}
}
int main( void )
{
B foobar;
}
this won't compile as my class B is still abstract as I didn't provide a
bool foo( A bar ) member.
But I only want class A to be an interface that tells everybody what to
expect from it's derivated classes. And one of these things is, that
every child must have a member that is called foo and has one
parameter of the type of the child itself.
How do I achieve that?
The only workaround I can come up with is, that I have:
class B
{
friend bool foo( class B, class B );
}
bool foo( class B bar1, class B bar2 )
{
...
}
I this doesn't guarantee me, that every child of A must have a foo
function...
Thanks,
Christian
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.0 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFB6STplhWtxOxWNFcRAk3mAJ0fkaueOVn9PF/pJmc3+vr8v5UXEACfZS10
c0NJMnATew8HrgigWxL+ayQ=
=VrIH
-END PGP SIGNATURE-
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Why should maps be power of 2?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Curtis L. Olson schrieb: Robicd wrote: I've been managing with some 3d objects to put into fgfs sceneries and I've found that faces' texture maps should be sized with power of 2. I'm using .3ds files (with .bmp maps) which don't have such limitation. Is there a reason for that? Is there a way to avoid that limitation? I find not very easy to force every map having that sizes. The reason is that this works well with opengl's mipmapping system (and it may be that opengl itself establishes this requirement?) It is an OpenGL requirement! At least till the newest OpenGL version, where they added an extension that allows non-power-of-2 textures. But not all drivers are supporting it. And if they are it still might be much slower as the hardware wasn't designed for it. CU, Christian -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFB6X05lhWtxOxWNFcRAlU3AJ409ElJHOoX+uEUYwDcyrLu6yAhtQCfR3u4 EFJtIDVC7QFRMlRrx+uHBSU= =rjE4 -END PGP SIGNATURE- ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Is this usefull for flightgear/jsbsim?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ampere K. Hardraade schrieb: On January 12, 2005 06:07 pm, Christian Mayer wrote: I see more problems with the correct shape of the wings. The models won't get it right and using just some NACA profiles won't work with the higly optimized profiles of modern aircrafts (like those from Airbus). I am pretty confident that my models can make it through the program, since wing geometry is the first thing I look for. I don't know about others though. The general wing geometry (i.e. the stuff you get from an 3-view) is one thing. The the real profile of the wing is crucial here - and it's AFAIK kept as an trade secret. On modern aircraft (like all Airbus modells and the newer Boeing ones) these are extremely optimized to be able to fly at high speeds efficently. Your models also won't have enough detail (= polygons) to reflect that geometry in the needed detail (or they would be bad models for visualisation...) CU, Christian -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFB5oVTlhWtxOxWNFcRArHTAKCqyCcfujqd3y0auAvd4SLaqi4DpQCgvP3H JtvJHKHwhJ2qLJh2rpq2GDk= =gzG2 -END PGP SIGNATURE- ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Is this usefull for flightgear/jsbsim?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Steven Beeckman schrieb: Are there any decent books about those Navier-Stokes equations and how to implement them in C or java? One description of Navier Stokes are at: http://en.wikipedia.org/wiki/Navier-Stokes_equations there are also many many other webpages out there that tell you the equations. To solve them you need a good understanding of solving partial differential equations (PDE). If you can solve them analytical you'll be awarded with a big amount of money and extreme amounts of fame... So you can only solve them (generally) by numeric methods. So just grab any book about solving PDEs numerically and you can solve the Navier Stokes (at least in theory...) CU, Christian -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFB5pbWlhWtxOxWNFcRAqE1AJ9vU38NF4wLNQOZyTdnXozft0kregCguY4m M+nyYQeJDusZjajHuTRiV2Y= =ugBg -END PGP SIGNATURE- ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] May I help with scenery?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jon Stockill schrieb: Ah, www.multimap.com helped me to figure out my first coordinate: There's a windmill at: Location:Germany X:1294800m Y:6110700m Lat:48:12:51N (48.2142) Lon:11:37:52E (11.631) But how do I add it online to the database? (http://www.stockill.org/fgfsdb/objects.php) www.terraserver.com helped even more. The detail is much worse (only down to 8 meters are for free), but as they've got air pictures it's easier to figure out the real position. You don't yet. Give me another week or so, and the scenery database should be at a stage where you can add your own objects to it. OK. I've got some more coordinates now. Of course nobody has made a windmill model yet, although I need to do a model of a wind turbine (I assume you're talking about an old stye windmill, not a modern electricity producing wind turbine? It's actually the modern variant (so it's called wind turbine then...) We don't have a soccer stadium yet, do we? CU, Christian -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFB5Vv1lhWtxOxWNFcRAr1eAKC2TVvS3njRLerq+40ipF0qwO1wigCfSlNC s8OaVG8ky19qLbLSZVzYcJE= =26/s -END PGP SIGNATURE- ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Is this usefull for flightgear/jsbsim?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Wolfram Kuss schrieb: Erik wrote: This still might be useful if you can get all the moments and coefficients from it. Then you would be able to create a JSBSim configuration file from the model geometry. The idea of using the gfx model you need to do anyone (or one of the thousands or ten thousands you find on the internet) and automatically get the config file. It would not matter if it takes over night or even if it takes a week. However, CFD programs need a watertight geometry. I would guess that far in excess of 90% of models are not. For example, each edge needs to have two neighbour faces. As you are only interested in the full shape of the plane (and not it's single parts) you could help yourself by automatically closing these holes. I see more problems with the correct shape of the wings. The models won't get it right and using just some NACA profiles won't work with the higly optimized profiles of modern aircrafts (like those from Airbus). CU, Christian -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFB5a3NlhWtxOxWNFcRAg9MAJ9Lo8XRiNpaNSGmdU9XHC0TUIWzsACcColJ ejqhd5nYnsk1zpPOO4EbLVU= =ixWC -END PGP SIGNATURE- ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] May I help with scenery?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jon Stockill schrieb: The positioning of landmarks which don't fall into either of those categories is best done with as accurate a map as you have available, either using FGSD with a scanned or digital map, or a service like www.multimap.com (for the UK I find www.streetmap.co.uk slightly more useful, because although it has a smaller selection of maps you can get the exact grid reference of the pointer on the map). The scenery database we're developing will hopefully be able to handle different national grid systems so that info can be submitted in whatever format is convenient, with convertion to lat/lon handled automatically (so far just OSGB is supported, but this can easily be extended as long as conversion functions are available). Ah, www.multimap.com helped me to figure out my first coordinate: There's a windmill at: Location:Germany X:1294800m Y:6110700m Lat:48:12:51N (48.2142) Lon:11:37:52E (11.631) But how do I add it online to the database? (http://www.stockill.org/fgfsdb/objects.php) CU, Christian -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFB5EvVlhWtxOxWNFcRAgrtAKCg749PoLXA0U4Oa6fmUHXOh/tzaACbBKJi CbU4y0d79X05K35ZkAb2yls= =QNnt -END PGP SIGNATURE- ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] alternative terrain engine integration
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Norman Vine schrieb: Manuel Massing writes: I want to start to integrate an alternative terrain engine with flightgear (http://baron.flightgear.org/pipermail/flightgear-devel/2004-September/030853.html) For this, I need to adapt flightgear to use an abstract terrain API, which will encapsulate the current and new terrain engine transparently. Apologies for my earlier empty msg I think an abstract Terrain API is a great idea however please keep in mind that FlightGear uses a round earth model and that this should be reflected in any FGFS Terrain API Probalby the easiest way would be to create an independant program first, that communicates with FGFS via the network api. This works currently for multi monitor (=machine) setups. And when the new rendering engine is capable enough to work in such a situation we can integrate it. The benefit is a very fast start on the rendering side - w/o much needed internal FGFS knowledge and w/o the need to synchonize development at the beginning. CU, Christian -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFB4ppglhWtxOxWNFcRAvA4AJ9TcDWEHcUCHRAvBGrSHQqyz91OsACgr2Vw PwkYmqngc8Qgy/4X9KOF32k= =7SGU -END PGP SIGNATURE- ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Scenery
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Christian Mayer schrieb: Jon Stockill schrieb: I can look up a few positions of objects. What format do you need? Lat/Lon? Just lat/lon, a heading (if appropriate) and the model you want inserted at that point (obviously if it's not a standard one form the Models directory then it'd be nice if you had the model too, so that everyone else gets to see it). I'll archive the Objects tree and my models, and let you know when they're available for download. Argh. The Bayernviewer page doesn't give me the coordinates anymore (the old, non-java version could do that). I write an eMail and hope that they'll add that functionality. I got an answer. They told me that the ministry decided that it'll be a security problem if people could the the coordinates of objects and places easily and quickly from the BayernViewer. So the alternative would be that I buy the map-data CD-ROM at ebay. They are not expensive (they are made for tramping and bike tours) - but too expensive for looking up just a few locations :( CU, Christian PS: Does anybody know an online map service where you can get the coordniates? -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFB4qyllhWtxOxWNFcRAp48AJ98gI8VphyCFeIFLDhFKAlqji6RlgCfWzLo Xva9iA5jbeUODksLKKX6jCU= =FLNU -END PGP SIGNATURE- ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] FGNetFDM-time
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Norman Vine schrieb: ..a _guess_: the 32bit unix calendar ticks over sometime in 2038, while the 32bit Wintendo calendar ticks over every 49? days, I saw this given somewhere on the web as the reason Microsoft used (they still do?) to recommend reboots about that often. This is true a naive Win32 clock running of of timeGetTime() rolls over every 49 days but there are ways to prevent this although I don't believe the FlightGear clock on Windows checks for this. That was a problem on Win95 (dunno if it was fixed till WinME). But on the WinNT series (incl. Win2000 and WinXP) it was never an issue. CU, Christian -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFB4Pv3lhWtxOxWNFcRAv4dAJ9bi/uzFRfOSs8F29pMuGmxbF7w3gCfXzc2 u7Txk+VAF4Mxh6jCRO8Tot8= =cZiW -END PGP SIGNATURE- ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] NASA Goes 'Down Under' for Shuttle Mapping Mission Finale
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jon Berndt schrieb: Culminating more than four years of processing data, NASA and the National Geospatial-Intelligence Agency have completed Earth's most extensive global topographic map. Great!!! To view a new fly-over animation of New Zealand on the Internet, visit http://www2.jpl.nasa.gov/srtm/ . The flyover is very disappointing. Our old DEM could easily create the same results. A bit more interesting is the high-res (4500x5800 pixel) shaded picture of New Zealand. But I wonder what the smoothed stuff around Milford Sound is. Probably it's due to shading/reflections of the radar beam. Milford Sound is a fjord, where you have drops from ~2000 Meters stright down to the sea! (Oh, and they have very tasty crayfish in there that I had the pleasure to catch while scubadiving...) When will be the secenery for New Zealand be created? So we can have a look at the data at Milford ourselfs. Ah, there's also an airport at Milfors Sound, that can be a great starting point: http://www.world-airport-codes.com/new-zealand/milford-sound-airport-4721.html (It must be a spectacular flight to and from Milford Sound) CU, Christian -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFB3l65lhWtxOxWNFcRAnkqAJ4xiS5Q1Si00zZF6biWDAjLBpCP0ACfT4h+ sC+O307qZrK0aI4jpR1Z7Xo= =6/u0 -END PGP SIGNATURE- ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] John: Church Fenton hangars need fixing?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jon Stockill schrieb: Arnt Karlsen wrote: Due to temporary boredom today I was playing with some visualisation code for the scenery database, and managed to draw this: http://flightgear.stockill.org.uk/testing/SceneryObjects.png It looks like rather a lot of objects when viewed like that! What are those yellow and red spots in the sea? CU, Christian -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFB3uqLlhWtxOxWNFcRApP2AKCRo6OaBE3g4Nh9+SCa0iqb6JumQACfWq2W rnpJk2BDEiZVmDNxCophsks= =UKhI -END PGP SIGNATURE- ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Scenery
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jon Stockill schrieb: While messing around with my scripts for inserting objects into the scenery (it's now all database driven, with numerous datasets imported) I decided I could do with a few landmarks. Here's a couple of views of the first, also showing off the object positioning: http://flightgear.stockill.org.uk/models/ This looks great. I whish someone would create such a scenery for Germany (or at least Bavaria)... CU, Christian PS: For Bavaria you can get the official 1:5 (or is it even 1:25000) maps and air pictures for free from the net. But they are only in pixel format (not vector format) and the UI isn't that great to do some harvesting -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFB3R4alhWtxOxWNFcRAvrzAKCFT6WzJPm4sbgnDioU9Z5jj4dxgACaAst+ iZO/MIQ77wzI7pGmBd4g2ZE= =ZOzR -END PGP SIGNATURE- ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Development Platform Help Needed
[EMAIL PROTECTED] schrieb: Thanks Christian and Chuck, I think Linux would be the most direct but my comfort level diminishes rapidly. Nowadays Linux is much more userfriendly than what people think. But I can understand that you'll only want to tackle one problem at once. I would appreciate an opportunity to review the MSVC++ path if I can get together with Chuck. You could try to write down the detailed steps you took to compile FGFS and thus produce an HOWTO that we can put on the homepage for others. So you should get a recent MSVC and all the source code first. I usually create one directory where I unpack all the libraries in subdirectories. E.g. C:\projects C:\projects\plib\... C:\projects\SimGear\... C:\projects\FlightGear\... Then I try to compile the libraries according to their dependencies (zlib, plib, simgear) And at last flightgear itself. So that was what should happen (and what worked back in 2000/2001 for me...) The real life might be a bit more complicated - but the general direction will be the same. CU, Christian PS: If anybody is wondering why I've got so much time to answer mails: when you are working on your master thesis you've got time for everything but the stuff you should actually do... ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Individual aircraft downloads
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Arnt Karlsen schrieb: Zip files are everywhere, we aren't going to get sued for using them, ..no? ;-) Never heard of The SCO Group and Microsoft? http://www.groklaw.net/article.php?story=20041228040645419 or http://www.groklaw.net/staticpages/index.php?page=2005010107100653 and http://www.groklaw.net/article.php?story=2005010406110017 If somebody want's to sue someone for using .ZIPs I wouldn't know any reason. But even if there's a hidden trap (- .GIF) then there'll be a huge media coverage (because .zips are everywhere) and we definitely won't the first one to be sued. So we would have enough time to remove those files. But all of that is highly unlikely. I don't see why we should run away from an unlikely event, when the alternative is, that the users run away, becuase they don't know what to do. CU, Christian -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFB3SJblhWtxOxWNFcRAmqxAJ9XlHsxSHl6Y8J96qwztE33Ic6sFwCgr7jg 5Kq69WTLEdLo+ZEvC8p/Cf0= =+I5Z -END PGP SIGNATURE- ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Scenery
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Thomas Frster schrieb: PS: For Bavaria you can get the official 1:5 (or is it even 1:25000) maps and air pictures for free from the net. But they are only in pixel format (not vector format) and the UI isn't that great to do some harvesting Really??? That's great. In Brandenburg they only provide it commercially with a tremendous price tag (1 per square kilometer - 3 for the whole state Brandenburg) If you want the detaild maps (1:500 or so) or air photographs with a very high resolution you have to pay. I don't know the license for using the free data as an data source at the moment. But using it just as an reference should be ok IMHO. What's the URL? http://www.geodaten.bayern.de/bayernviewer/index.html (Java required; page is in German, but not too hard to work with if you can't speak german...) CU, Christian -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFB3T/plhWtxOxWNFcRAoYAAJ9oedEwJAeqAebKdFobJi7GbdgYdACfUhQn xmNf4+pWAKXEcveJ4owGDwQ= =Dvs9 -END PGP SIGNATURE- ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Scenery
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jon Stockill schrieb: Martin Spott wrote: Jon Stockill wrote: Just let me know the areas you're interested in. Europe ? ;-)) Which scenery tarballs? I'll get them downloaded, and get on with processing the terrain elevation for the navaids straight away - more detail can be added as people find me info to import. My town lies in e010n40.tar.gz (as well an Munich and a big part of the Alps)... I can look up a few positions of objects. What format do you need? Lat/Lon? CU, Christian -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFB3UsrlhWtxOxWNFcRAhkOAJ42sVUaU6IAfiFNj0rG5VfejU7YxQCgrw7P zBbKKfkI9gMGlkAJRKxj/BU= =IWTU -END PGP SIGNATURE- ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Development Platform Help Needed
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Chuck Cole schrieb: I unfortunately do not have an FTP server or the like to make my version of the source code available to you. But since you have some time, I could simply e-mail you the source code that I have built along with some simple setup instructions. Collectively, the source code for all of the projects is rather large; however, I believe that they could be split up sufficiently enough to be e-mailed. We can take the details of setting up any arrangement off-list. My sparetime isn't that much, that I could build and test FGFS in it :( I was asking just for a documention how you set up MSVC++ so that it compiles FGFS. That would be a nice HOWTO for other developers (we get a request for that every few months) CU, Christian -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFB3Uv1lhWtxOxWNFcRAncxAKCJosii7nyzvifTJPaCjc1TZqCkygCfVkbY oayVpSjkLxm2I+285w782m4= =UAcg -END PGP SIGNATURE- ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Scenery
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jon Stockill schrieb: I can look up a few positions of objects. What format do you need? Lat/Lon? Just lat/lon, a heading (if appropriate) and the model you want inserted at that point (obviously if it's not a standard one form the Models directory then it'd be nice if you had the model too, so that everyone else gets to see it). I'll archive the Objects tree and my models, and let you know when they're available for download. Argh. The Bayernviewer page doesn't give me the coordinates anymore (the old, non-java version could do that). I write an eMail and hope that they'll add that functionality. CU, Christian -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFB3Vt/lhWtxOxWNFcRAuw2AKCcc2hN/zfuqJHl0nqVyr98mA9/lQCfUFcg eDdcYVUJw4SoTLBLKgzgmgU= =vuU/ -END PGP SIGNATURE- ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Individual aircraft downloads
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dave Martin schrieb: On Wednesday 05 Jan 2005 09:22, Vivian Meazza wrote: We should do both - that seems to be the solution adopted by most web sites which offer downloads. Why should we be different? We should not expect windows or UNIX users to download and install some additional software. I could make a really scathing comment about that using words like plib, OpenAL and SimGear... But those are for *developers* and not *users*. - From an developer I can expect to have more powerfull tools than an user. Oh, and these files should also be offered as .ZIPs anyway. Hardly any extra work and nice for the developer (who is already annoyed by dependancies) CU, Christian -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFB28UWlhWtxOxWNFcRAr+UAKCNngqHXjwVjNFVXayCRCDV0ugVwACfW4SW FvJRZm8jB548CPRkr/7/El4= =ZKvc -END PGP SIGNATURE- ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] OT: Aircraft/Pilot's manuals
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Adam Dershowitz schrieb: For GA aircraft (light aircraft) the POH is pretty much all there is, other than maintenance manuals. The POH does not contain complete system information. It contains enough for a pilot to understand the OPERATION of the systems, so there are often some simplifications and approximations. So this could lead to some issues for detailed modeling. The maintenance manuals contain more details about systems, but they tend to be harder to get, and then contain lots of other stuff that is not relevant, or that useful for modeling. To complicate things, I believe that airlines are often involved in the specific manuals that are used on their airplanes. In other words I think that if you got into the cockpit of a 737-800, the included manuals would depend on what AIRLINE owns the airplane. They would have worked with Boeing to generate them. I am getting into more guesswork, then knowledge, but I would not be surprised if the Operations Manual relates to people outside of the cockpit (maintenance, dispatch etc.) rather than the people inside the cockpit (Pilot's Handbook). Finally, I would say that your best starting point will generally be the POH, but modeling an airplane is complex, and much of the data is considered proprietary and is not available, even to owners and operators. It is generated during certification and then held close. Well, I've seen the manuals that come with an A310 - box of roughly 1m * 0.5m * folder-height (probably larger) full with overfilled folders. I just had a quick look into the papers. I could only find pages that didn't tell me anything :( If I'd know exactly what would be interesting of modellers I could try to look again. CU, Christian PS: Although the last operator of the plane was Armenian Airlines the documentation was - thankfully - in english -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFB3FPrlhWtxOxWNFcRAtHTAJwJgUM52mQf3MbFWBLPwvYYMuyDzwCfT+L3 D4yLiAsZOsadqIqNOYw6L30= =OzCn -END PGP SIGNATURE- ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] OT: Aircraft/Pilot's manuals
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Paul Surgeon schrieb: On Wednesday, 5 January 2005 22:54, Christian Mayer wrote: Well, I've seen the manuals that come with an A310 - box of roughly 1m * 0.5m * folder-height (probably larger) full with overfilled folders. No wonder they pay Airbus drivers such great salaries. Were those just pilot manuals or did it include maintenance and part manuals? I know maintenance and part manuals are normally HUGE even for small GA aircraft. A quick look didn't reveal anything. But I doubt they are the maintenance manuals as they are in a box that belongs to the cockpit. I'm rather curious as to how you landed up with access to those manuals. Do you have an A310 parked in your private hangar? :) Sadly not my hangar and sadly not a full A310-200. It's just the first 20 meters of it and it's parked infront of the Fraunhofer Intitute for Building Physics here. (A picture as it is unloaded from the Beluga: http://www.fraunhofer.de/fhg/bigimg/2004/pi49fog1jpg.jsp) My dad organized it to make a laboratory out of it to research the effects of (long distance) flights to humans. (I wrote about it earlier) CU, Christian -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFB3HTLlhWtxOxWNFcRAgz8AJ9Z++X9Ixe9EuAGwzST/vk71cI1CwCgpZB9 TCE3YgzoEqhVO+6IDiUprz4= =tnbw -END PGP SIGNATURE- ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Individual aircraft downloads
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Oliver C. schrieb: | | Could you change the file format from *.tgz to *.tar.gz? | | I ask because *.tgz is used by Slackware as a package format (it's a tar.gz | file with a install script in it) and this is leading to confusion | when you have Slackware *.tgz files and *.tgz files that are no Slackware | packages on your harddrive. | | So file endings called *.tar.gz would be much better than *.tgz. And what about *.zip? Linux can easily unzip those and Windows users have the unzipper already comming with their OS (when it is WinXP...) CU, Christian -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFB2nIHlhWtxOxWNFcRAqf3AJwJrDhrCaIN78Rs0J17glZCWLENUgCfQzPD W3Zg/opMBXj/T/SZfBEAklE= =lvo5 -END PGP SIGNATURE- ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Individual aircraft downloads
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Oliver C. schrieb: | On Tuesday 04 January 2005 11:37, Christian Mayer wrote: | |Oliver C. schrieb: || Could you change the file format from *.tgz to *.tar.gz? || || I ask because *.tgz is used by Slackware as a package format (it's a | |tar.gz | || file with a install script in it) and this is leading to confusion || when you have Slackware *.tgz files and *.tgz files that are no Slackware || packages on your harddrive. || || So file endings called *.tar.gz would be much better than *.tgz. | |And what about *.zip? | |Linux can easily unzip those and Windows users have the unzipper already |comming with their OS (when it is WinXP...) | | | Yes, but *.zip is not a free format. Really? I thought at the beginning it was proprietary (sp?), but there are enough free implementations now. | Using *.zip would be like using *.mp3 instead of *.ogg The problem with mp3 is that you have to pay royalties if you want to distribute an encoder. Is there anything similar with zip? | 7zip or bzip2 would be acceptable, both are free like tar.gz. The advantage of zip is that you don't need an extra program to unpack it (if you've got WinXP or, probably, newer). All other formats don't have that advantage. But if zip is no option .tar.gz or .tgz are fine, as all usual unpackers for Windows support these (compared to 7zip; bzip2 might be supported a bit more) CU, Christian PS: Does anybody know how to tell Enigmail to keep the quotations started with an and not to convert them to an |? -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFB2oQzlhWtxOxWNFcRAkJmAJ9a+k2/G3zUDaFJzmTdnl6J6bzDXgCfYeEF LUHIBjH/h84t8YG2EUzXbr0= =Gwcp -END PGP SIGNATURE- ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Individual aircraft downloads
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Martin Spott schrieb: Christian Mayer wrote: Linux can easily unzip those and Windows users have the unzipper already comming with their OS (when it is WinXP...) But only then - and who wants WinXP without being forced to !? ;-) On the other hand PowerArchiver for Windows easily handles .tar.gz or .tgz files, About any reasonable mainstream (de)compression tool for Windows can handle .tgz or .tar.gz as well as .zip Some can do .rar or .ace or ... But the point is that there's allways an extra program required. All versions before XP do allways need an extra program. So we can choose what we want. But with XP (which, by now, most of the Windows users use) you get an decompression tool included in the Windows explorer. And that tool can only handle .zip BTW: of all Windows versions you only want to use 2000 or XP (= 2000.1). The rest is either unstable (95, 98, ME) or doesn't run modern software (NT) CU, Christian -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFB2riKlhWtxOxWNFcRAg/eAJ9KUtVdM0jTRXLBxkmMra5xk6rWKQCgrhlr aBPFQfCwM8yHkjeNGVY70N8= =9ZnO -END PGP SIGNATURE- ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Individual aircraft downloads
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Martin Spott schrieb: Jon Stockill wrote: Martin Spott wrote: But only then - and who wants WinXP without being forced to !? ;-) On the other hand PowerArchiver for Windows easily handles .tar.gz or .tgz files, As does winzip AFAICR. but WinZip is commercial, isn't it !? Yes. As well as WinRAR and WinACE. Now we've got the most common ones. There are also a ton of others. Personally I don't know any free ones (ok, I didn't do any excessive research though). That's why I prefer .zip. Then at least the WinXP users have a native, free tool that works out of the box. Jon Stockill schrieb: Christian Mayer wrote: BTW: of all Windows versions you only want to use 2000 or XP (= 2000.1). The rest is either unstable (95, 98, ME) or doesn't run modern software (NT) This doesn't alter the fact that there are still a lot of perfectly capable systems out there running 98SE - they shouldn't be overlooked. And at work we've got still some Win95 computers running (for different reasons though) My basic message is: all Windows versions but XP must get a tool (and that'll handle not only .zip but also the rest). WinXP and its successors comes already with a tool - but that can only handle .zip. If the planes are in .tgz *all* Windows users *must* get a decompression tool. If the planes are in .zip a high percentage (but not all) of Windows users do not need an extra tool. (Being someone who knows about computers results in being asked to fix them by friends family) I think that is a very common problem. But I have an excuse so that I don't need to look to thoroughly: if you are using Windows it's your problem, ask me again when you are running Linux... :) CU, Christian -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFB2tD1lhWtxOxWNFcRAqr4AJsFLeCHmN971MpxV3T1SmDbxFwWJwCfTEuw sb9LO9N+Cf6N9jyZ/lx3RLA= =2MFp -END PGP SIGNATURE- ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Diamond TwinStar Panel
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Paul Surgeon schrieb: |The 3D part is easy -- there are relatively few moving parts to |animate. The challenge will be creating dynamic textures to show on |the displays, and that's going to require rolling up our sleeves and |doing a lot of C++ OpenGL coding. | | | I discussed this with Melchior a couple of weeks back. | We don't have to use OpenGL to generate the textures. | We could possibly use a powerful 2D rendering library like libagg to generate | the dynamic textures and just get OpenGL to render the textures. That way | panel designers don't need to learn the complexities of OpenGL. | It's a lot easier to use a feature filled 2D rendering library that is built | for rendering vector and text graphics than messing around with low level | OpenGL calls. The stuff that is displayed looks simple enough to be easily drawn with OpenGL. I see no benefit in adding an dependancy to a library that effectively can do the same as OpenGL - but only in software. If OpenGL is too complicated for some cases, we can encapsulate the necessary functions in C/C++ code and offer that function. An glass cockpit can be implemented by rendering the display content to an texture and using that dynamic texture in the 3D cockpit. CU, Christian -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFB2Bs2lhWtxOxWNFcRAnhDAKCRnzXppxPEZUx+5owds/kufeTWZgCgno80 JzrU5GQRitoQwwKzTS+CJJ8= =ZRY/ -END PGP SIGNATURE- ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Diamond TwinStar Panel
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 David Megginson schrieb: | On Sat, 1 Jan 2005 23:39:49 + (UTC), Martin Spott | [EMAIL PROTECTED] wrote: | | |They also have a version with two Lycoming IO-360 for the North |American market, | | | Is that out yet? I'd heard that they were working on one because | there's no repair network for the Thielert diesel engine in North | America; I'd also heard that they were working on setting up such a | network. The Thielert engine certainly accounts for a lot of the | savings -- I'd expect two IO-360's to burn at least 20 gallons per | hour, vs 10 gph for the Thielert engines, but they'd probably also | increase the useful load by a couple of hundred pounds and make the | plane fly faster, to offset that. | [...] | | The Thielert diesel engine has nothing to do with the | Rotax, of course, but Diamand will have to do a lot of work to win | back North American buyers' trust about non-standard engines. We fly | planes hard and far in North America, often with multiple 3-5 hour | legs through some pretty extreme climates (from about 45 degC in the | American southwest to -40 degC in northern Alaska and the Canadian | arctic), so engines that perform nicely for occasional recreational | use for local flights in a moderate Europe climate don't always cut it | over here after a few years of use. I'm hoping that the Thielert will | make it, because the fuel savings sound fantastic. It's time that Diesel engines get into the air. The Diesel engine market for cars had a drastic increase over the past 5 years (it started even earlier). Over 50% of new cars in Germany are Diesel engine powered and you have real trouble in selling your used, non-Diesel car... This is due to their high fuel efficiency (a principle advantage) and the very high torque they produce (much more drving fun...) I dunno how the engine copes with the drastic change in the climate you are describing - but the internet pages tell me that the whole engine gets replaced after 1000h with a new/serviced one. (They are designed for 2400h. But they'll increase the service intervall slowly over the time as they get the results of the wear of the currently used engines) CU, Christian -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFB2B2klhWtxOxWNFcRAmIzAJ9TTOqxZWqY7kKqrNCTErU7QVgVFACePxA9 dDGEU5KKI4QRWQ8hFYkThQE= =7MbN -END PGP SIGNATURE- ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Diamond TwinStar Panel
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dave Martin schrieb: | On Saturday 01 Jan 2005 22:36, Ampere K. Hardraade wrote: | |Interesting aircraft. | |On January 1, 2005 04:44 pm, Dave Martin wrote: | |The visual model is easy enough | |Provided that there are enough data to do an accurate model. Is there any |technical document available for references? If you look at the different press releases and articles that are linked from their page everywhere, you can get quite a few perfomance numbers. Esp. the american version of their homepage has quite a few numbers... | Even a good diagram of a DA40 would be useful as I believe they share the same | fusealage aft of the firewall. http://www.diamondair.com/PDFs/DA42UpdateAPR.pdf - this has at least a diagram. CU, Christian -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFB2CMTlhWtxOxWNFcRAl/wAKC7/ld1wiMt4StsguaVvDqbYaLA3wCfWaJu TwLsrv/lun+GufuRgNVgUTo= =270f -END PGP SIGNATURE- ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Diamond TwinStar Panel
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ampere K. Hardraade schrieb: | Here is an alternate idea: instead of writing our own animation class, may be | we can think about making the displays capable of rendering *small* external | OpenGL applications; such as the OpenGC Project. When we can convince the other application to render to a texture that should be easy. CU, Christian -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFB2FuClhWtxOxWNFcRAmKGAJ9/zkQcblHz9Opama2pTGFlOo4vKQCeN65s Ddbc9QH5KF3CJMMCFclX3Fc= =1cGP -END PGP SIGNATURE- ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Diamond TwinStar Panel
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Paul Surgeon schrieb: | On Sunday, 2 January 2005 18:03, Christian Mayer wrote: | |I see no benefit in adding an dependancy to a library that effectively |can do the same as OpenGL - but only in software. | | | The difference is a powerful text and vector library vs OpenGL primitives. | Have you ever tried rendering true type fonts in OpenGL? | It's a pain in the ass! No, but when I need renderd text I use PLIB's fnt library. Although it uses bitmaped and not true type glyphs it will be (more than) good enough. We only need one (or just very few) different font sizes. |If OpenGL is too complicated for some cases, we can encapsulate the |necessary functions in C/C++ code and offer that function. | | I think that would be a good option. | I think a panel designer should be given a canvas/texture that they can | paint on with easy to use text and vector functions. | The canvas and painting should be defined in 2D pixel co-ords. OpenGL knows the orthogaphic projection - so you have ordinary 2D coordinates. Rendered to an texture you've got everything you need. (Actually you've got the same technique that the next Windows version will have) CU, Christian -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFB2GodlhWtxOxWNFcRAo+zAJ9AoHNtbfUP0Xkfvg+Pp8Pi6XuPjACfYR/U Etogg0o+umEWyBrlF//h5Yc= =8QTW -END PGP SIGNATURE- ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] What was decided about the guy on -user who's bouncing everything back to sender?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Chris Metzler schrieb: | The [EMAIL PROTECTED] guy is still bouncing back to sender | everything posted to flightgear-users. Looking back through the | archive, I can't decided if anything got decided about what (if | anything) to do about him . . . And the abuse-contact at safe-mail.com isn't cooperative... CU, Christian -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFB2IiPlhWtxOxWNFcRAvb1AJ0c7Ak8s3iaCrwg1Q14jT3EA73vZgCfRIia EmIjBdCH6rOIrHkbyRWWAUQ= =dlFT -END PGP SIGNATURE- ---BeginMessage--- Dear Christian, the attached mail was sent from your domian. As I have no contract with you but repreatedly get these annoying mail I ask you to stop these mail *immediately*! This message is not spam. Like you, [EMAIL PROTECTED] is one of the members of the Flightgear-Users mailing list. To fight spam he/she configured his/her account to reject messages which were sent from addresses that do not appear at the address-book. In this case our system sends the reject message you just received. Attached is the message [EMAIL PROTECTED] received from you. There are many people subscribed to the Flightgear-Users mailinglist and *everybody* who sends a mail to this mailinglist will get this annoying mail! The message was sent to your email address only - Not to the mailing list. SAFe-mail is a secure communication system, and we believe that security and privacy are very important, for both SAFe-mail users and users like you. This means that in addition to our efforts to protect our users from Spam, we work hard to make sure that our own users aren't sending out spam. You can learn more about spam and check whether a user was deleted as spammer at https://www.safe-mail.net/spam Best Regards, SAFe-mail support Original Message From: Christian Mayer [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: [Fwd: Rejected: Re: [Flightgear-users] Problem with fgrun] Date: Tue, 28 Dec 2004 13:40:03 +0100 -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dear Sir od Madam, the attached mail was sent from your domian. As I have no contract with you but repreatedly get these annoying mail I ask you to stop these mail *immediately*! There are many people subscribed to the Flightgear-Users mailinglist and *everybody* who sends a mail to this mailinglist will get this annoying mail! If these SPAM mails don't stop I'll report you at the necessary places. Thanks, Christian Mayer -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFB0VQjlhWtxOxWNFcRAkESAJ99hO4+YRaTmlHY0zWYpK2UdM6FKgCfVDD7 pnm4/3Dq3rWOGJxYyd5jS0w= =kRXn -END PGP SIGNATURE- ---BeginMessage--- -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Innis Cunningham schrieb: | Hi Erik | | Hi Erik | Sorry for seeming so dumb but were might I find that on a | windows 98 system. | Thanks for your help. | | Found it. | For all those windows people out there it was in | WINDOWS\application data\flightgear.org. | Or at least that is were it was on my windows 98 | system. Be careful! These paths differ for the different language versions of Windows! I.e. I hate the stupid installers that want to install the programms in ~ C:\Program Files\... as my German Windows (and all reasonable installers) defaults to ~ C:\Programme\... A litte look at the commandline with set showed me these interesting environment settings: HOMEDRIVE=C: HOMEPATH=\Dokumente und Einstellungen\cm ProgramFiles=C:\Programme SystemDrive=C: SystemRoot=C:\WINDOWS TEMP=F:\tmp TMP=F:\tmp USERNAME=cm USERPROFILE=C:\Dokumente und Einstellungen\cm windir=C:\WINDOWS So you probably should look for %USERPROFILE%\flightgear.org CU, Christian -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFB0T2zlhWtxOxWNFcRAhWrAKCHxsKV/sYNEUFPYeg73Vo9RyXKWwCdHtOO lrV5drkTAQ4IR8hHYACH1Us= =duns -END PGP SIGNATURE- ___ Flightgear-users mailing list Flightgear-users@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-users 2f585eeea02e2c79d7b1d8c4963bae2d ---End Message--- ---End Message--- ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Rounding in nav/comm frequencies?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dave Martin schrieb: | Any clues as to why, when I try to display the output | of /instrumentation/comm/frequencies/selected-mhz etc on my Comm radio, The | output gets rounded down or reduced by 0.01 in some cases but not others. | | ie: set 120.5 displayed 120.49 | | set 120.8 displayed 120.8 | Floating point rounding error? (There are many simple numbers that we use, that floating point numbers can't represent. E.g. 0.01) If the floating point number gets cut off and not rounded you'll also might get that effect. Could you try to add 0.005 before rounding/cut off and see if that helps? CU, Christian -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFB1XfnlhWtxOxWNFcRAiNpAKCy8S8LY4ExvB5Ah3yXGkjwmYzf4ACeMuw7 HwBQsU+LdstXGCkSxqPi3co= =ZnKj -END PGP SIGNATURE- ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] [OT] Spectacular ground transport
Well, I can only respond with an air transport: http://www.flugzeugbilder.de/show.php?id=256867 (I haven't scanned my own pictures yet; if you search for Beluga and MUC you'll find lots of pictures on the net) There an A310 (history of this plane: http://www.planemad.net/Production_List/Airbus/A310/276.html) was cut and the front part was brought to the Fraunhofer Institute in Holzkirchen to serve as an laboratory for research of the effects of long distance flying on humans. The first part of the plane was carried by an Beluga to MUC (EDDM) and from there by a extra heavy road transport to its destination. As my dad is/was responsible for this laboratory (the last thing before retirement) I could be at the airport as the Beluga arrived and unloaded the plane. Currently I'm trying to convince them to use FlightGear for their visuals... CU, Christian Ampere K. Hardraade schrieb: More picutures can be found here: http://www.airliners.net/search/photo.search?regsearch=PH-BUKdistinct_entry=true Ampere On December 16, 2004 03:43 pm, Durk Talsma wrote: Tonight an old KLM-747 will be shipped through the canals of Amsterdam on it's way from Schiphol Airport (EHAM) to the new Aviodrome (http://www.aviodrome.nl) museum at Lelystad airport (EHLE). I found some pictures at: http://www.ruudleeuw.com/phbuk-15dec04.htm The transport will pass near where I live in a few hours, so I'm tying to see if I can catch a glimpse. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Things to do to improve Flightgear
Thomas Förster schrieb: Am Mittwoch 15 Dezember 2004 14:48 schrieb Oliver C.: On Wednesday 15 December 2004 07:35, Paul Surgeon wrote: I hope we either drop PUI (plib's UI) or at least do a major upgrade to it. We use PUI in the menus at the moment and in my opinion the widgets look absolutely GHASTLY. What could we use instead of PUI? What gui library uses OpenGL? Well, I don't think that replacing PUI has a high priority. I doesn't look that bad (but doesn't mirror the OS style). And it get's drawn by OpenGL with a low overhead. So we should improve the underlaying functionality first, bevore we consider exchanging PUI. For integration with existing desktops it's possibly best to use their native libs. QT for example provides an OpenGL widget, so all of the gui (menu, dialogs) could be native QT Widgets. Also if the sim runs in the context of a GUI it will be easy to switch between them at startup, i.e. 'fgfs --gui-gnome' runs a GTK based GUI, whereas 'fgfs --gui-qt' runs a qt based one. Don't know about possible performance issues, though. :-( This sounds like unlimited resources where you can afford the luxurity to code a GNOME, as Qt, a Windows, a MacOS, a [...] interface... A Qt only interface sounds good - but Qt isn't free for Windows (you'll only get an 30 day evaluation copy IIRC), so we can't use it :( CU, Christian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Things to do to improve Flightgear
Ironhell3 . schrieb: I believe that flightgear is a great game but in my opinion it is not very user friendly.In order to have more users trying our game and thus provide more feedback we have to make some steps: 1) Update the splash screens. We have the same ugly splash screens for the past 3 years Good point. Where are the splash screens you prefer? (Hint: That's a good place to start to contribute, even when you don't know how to program) 2) Use a menu to select starting aircraft and airports. We should init the game with very minimum code and then present to the user a nice menu with the logo of FG and two scrollbars, one for the aircrafts and one for the airports. This data could be updated dynamically based on which aircrafts we have in the installation directory I second that. But as I'm now contributing code for that I shouldn't talk too lound... :) 3)Work on the multiplayer part. It would be very fun if two or more players could connect to one of them running the server and fly together. I know there is initiall work on this but i don't thing it is very usable at the moment That's something *I* do not need. But again, those how programm decide... CU, Christian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] New nasal features coming
Andy Ross schrieb: Curtis L. Olson wrote: Finally, I get to realize my dream of re-implimenting all FG algorithms using recursion. Not to ruin the joke, but you could do that already. Nasal has always been a fully functional language, with recursion, lexical closures and anonymous lambda expressions. :) We should recode FGFS functional then. Then I can proofe that that I'll never crash a plane! :) CU, Christain ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Inner marker sound
Chris Metzler schrieb: On Sat, 4 Dec 2004 09:46:00 +0200 Paul Surgeon [EMAIL PROTECTED] wrote: Is there anyway of stopping the inner marker sound going off whenever starting at an airport on the runway? This is a bug I presume because I do not know of any inner markers located directly on the runway thresholds and it stops once the sim is loaded. I have to turn my sound down when starting FG, it's so loud. Just to follow up on this -- I can't confirm this; it doesn't happen for me. But it does happen for people other than Paul; there've been users coming into the #flightgear IRC channel asking about how to fix this. I can confirm it under Windows (haven't tried Linux though) It even played when I had the old sound card driver and FGFS didn't start (see older threads). CU, Christian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Traffic Management screenshots
Chris Metzler schrieb: I'm curious whether you have ideas on how to generate traffic data (flights and flightplans) for the aircraft that the TrafficManager and AIManager will handle. Are you thinking of doing real-world flights? If so, is there a good place to harvest that data? You can try the homepage of the StarAlliance (they consist of quite a few big carriers). AFAIK the offer their timetables in an electronic format to download. At least they have them packaged for PDAs and a very cool screen saver where you can see all flights at their current (predicted) position. (Sorry for Windows only IIRC) CU, Christian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: [Simgear-cvslogs] CVS: source/simgear/sound soundmgr_openal.cxx, 1.7, 1.8
Curtis L. Olson schrieb:
Log Message:
I don't understand why FreeBSD doesn't see isnan() after including math.h
but it doesn't. Trying the apple approach to fixing isnan results in an
infinite loop (making me wonder what happens on OSX?) This is an alternative
approach to checking isnan() on freebsd ...
[...]
+ #if defined (__FreeBSD__)
+ inline int isnan(double r) { return !(r 0 || r 0); }
+ #endif
This test will break if r == 0
CU,
Christian
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] nurbs headaches
Curtis L. Olson schrieb: I find that when I try to interpolate a nurbs surface through the grid points, the resulting surface misses many/most of the points, which is not what I expected. I also tried a least squares fit which actually I *really* like, however, I'm finding that the least squares fit blows up on some data sets for no apparent reason ... there's nothing ill defined about the data sets it is blowing up on. NURBS aren't good conditioned. That means that depending on the input data it can easily happen that your result will be rubbish. I don't know what least square fit you are doing, but it might as well be badly implemented (I don't know of the top of my head if they are badly conditioned as well) What you might try is putting a bezier patch through the points. The Bezier curve guarantees you that it won't leave the convex hull of your points. But it won't go through your controll points (what you actually want to achive to smooth your data...) And IIRC bezier curves are good conditioned. Does anyone have any experience with nurbs++ No, I have never used nurbs++ or any other nurbs library who could help me out here? I've heard quite a bit over nurbs in my numerics course at university though I'm *not* looking for people who can help me google. Well, googling for bezier 2d gave me: http://www.cs.wpi.edu/~matt/courses/cs563/talks/surface/bez_surf.html (not exactly what you are looking for, but it looked like an easy to read memory refresher) Oh, I forgot I shouldn't have helped you googling :( CU, Christian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] nurbs headaches
Curtis L. Olson schrieb: Christian Mayer wrote: What you might try is putting a bezier patch through the points. The Bezier curve guarantees you that it won't leave the convex hull of your points. But it won't go through your controll points (what you actually want to achive to smooth your data...) And IIRC bezier curves are good conditioned. How would I determine the control points? I'd take the noisy hight resolution DEM-data as the control points. The bezier surface will automatically smooth the data then. The bezier surface won't go through the control points - except the start and endpoint (in the 1D/2D case; in 3D the border points) I suggest you try an interactive demo of bezier lines (are the bezier surface demos as well?) in the internet. There are many Java-applet implementations arround. Well, googling for bezier 2d gave me: http://www.cs.wpi.edu/~matt/courses/cs563/talks/surface/bez_surf.html (not exactly what you are looking for, but it looked like an easy to read memory refresher) It would be great if I didn't have to write and debug my own bezier library, are you aware of any existing code that could help me out here? I don't know any implementations, but I'm sure Norman's sources are as good as they allways are. :) BTW: At least in the case of bezier lines the implementation is very easy. I've done it a few times already. It's so easy that I prefer writing it myself than reading foreign code ;) CU, Christian PS: (Nearly) every paint/graphics programm has bezier curves. PPS: The reason why NURBS are thought of the best splines is just their flexibility (you can model exact circles). But in reality more simple splines are usually better suited PPPS: You can fill whole lectures on the pro and cons of the different splines ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] St. Elmo's Fire
David Culp schrieb: I've been playing with modeling St. Elmo's Fire as an instrument: http://home.comcast.net/~davidculp2/stelmo-clear-sky.jpg http://home.comcast.net/~davidculp2/stelmo-in-clouds.jpg which is convenient, but has some problems. The main problem here is that it's barely visible inside of clouds, where one would expect to see it. If I change the time-of-day to something darker the panel code darkens and redens everything, which ruins the effect. Then of course there's the problem of setting up a boolean property that randomly, and rapidly, is true, in order to model flickering. To increase contrast, you could draw the lines in black for one frame, then white for a few frames and then balck again for one frame. This works at least for normal lightning (but it can be that it won't work here) CU, Christian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
