Re: [Flightgear-devel] status of aircraft carrier
On Mittwoch 20 Oktober 2004 18:11, Vivian Meazza wrote: > It would be easy to convert to X,Y,Z coordinates, if I knew the equations > (I have suitable equations for ft to degrees lat/long) or, better, I could > start in X,Y,Z. Start with X/Y/Z ... Greetings Mathias -- Mathias Fröhlich, email: [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] status of aircraft carrier
On Mittwoch 20 Oktober 2004 09:49, Vivian Meazza wrote: > We calculated the output in geodetic terms (lat/long/alt) for submodels so > that they could be displayed, and it's no problem to output in x,y,z > aircraft terms. It didn't seem to be expensive computationally. Further, > lat/long/alt was the easiest to get at for the aircraft location. I think > that I'll need some help here with the necessary conversion factors. I'll > look into it further. The problem is that those values are in geodetic lat/lon. The underlying transform to an elliptical coordinate space is done in sgCartToGeod in SimGear/simgear/math/sg_geodesy.cxx. There is also a paper about this stuff floating around. But it is sufficient to know that this transform is significantly more expensive than doing a scalar times vector. > Do we need ground reactions as an intrinsic part of this code? Although I > can see that it might represent an opportunity to improve the current > situation. I think so. I cannot see a way to model the earths surface with different properties like runnway/grass/water with load factor. Moving and rotating triangles for the ac carriers deck, and special elements like the wires/catapults. Ok, this can be put into the property tree as we have a structure broken out into scalar values. But I guess that this provides a huge overhead for that stuff. If you do serious computatiions with those values you will need to transform them back into structs/classes/whatever. > Good, let's go for it. Ok, yesterday evening I did that hierarchical boundingbox stuff. It looks very hackish at the moment and I first need to seperate out some stuff also in that experimental tree before I can send you what I have. I hope to get that done today evening ... I can taxi on slopes and get all surfaces/lines in an ball aroung the aircraft. So If you can think about, how we can inject our preliminary wire area into the scenegraph, we will be some step ahead. :) I thought about using normal ssgLeafs for such a thing with some special information that this is a wire area stored in the UserData field of ssgBase. Really, modelling individual wires with lines is also not a big deal. So If we could inject individual wires every 5 meters on the whole KSFO runway (I am not a good pilot for testing ... :) we can start with that. A word for testing if a wire is caught: The hook (think of it as a line) has a position before the integration step. Past integration, it has a new position. The rectangle spanned by those two lines is the area where the hook was during that integration step. If a wire line intersects this rectangle, we have cought that wire (when we assume for now and testing, that we catch every wire we touch). > I'll get on with seeing if I can provide hook position - we would be well > under way with that. I think this would be a worthwhile activity since we > seem to have most of the bits almost in place. Yep this hook position is also something we will need. As I told, best in (double valued) cartesian coordinates relative to the earth's center. greetings Mathias -- Mathias Fröhlich, email: [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] OpenRT (was: VBOs - performance test results)
But, hell - yes, it does look damn amazing: http://graphics.cs.uni-sb.de/Dynamic/Images/chess.jpg http://graphics.cs.uni-sb.de/Dynamic/Images/dance.jpg http://graphics.cs.uni-sb.de/Dynamic/Images/kitchen.jpg taking into account that all this was created without conventional 3D hardware - the videos are even more impressive. -- Boris ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] VBOs - performance test results
First of all, I'm not saying "let's switch to OpenRT now". I am saying that if FlightGear's scenegraph ever requires a large restructure, it will be a good time to look at the feasibility of using OpenRT. On October 20, 2004 11:50 pm, Boris Koenig wrote: > nope, it wasn't required - after all it is supposed to be > "software-raytracing" and not hardware, but I *assume* without > a corresponding hardware board your CPU would probably be abused > as a GPU - almost exclusively ... No doubt. > > > The reason I brought the OpenRT topic up again is that (as far as I > > understand) it can run on most people's desktop. > > yes, but I somehow doubt that there would remain much idle CPU time - > you'd probably at least need a dual-processor board - but again, I'm > *guessing*. > > Probably, they wouldn't start developing prototype hardware boards: > > http://www.saarcor.de/ > >> Now, if it can render a 350 million polygons model using a CPU that is slower >> than mine, then it should be able to handle FlightGear with ease. > > I am not so sure about that - in order to get representative data, one > would need to have at least some simple tests available or maybe even a > simple game that employs the software-based raytracing approach. > > On http://graphics.cs.uni-sb.de/RTGames/ there are various games > mentioned, even screenshots are shown - and even very promising > divx-videos - but there doesn't seem to be a simple demo for personal > evaluation !? > > This might be the case because all these videos seem to have been > created using clusters of a dozen or even more 1 GHZ machines ... Even if FlightGear were to utilize OpenRT, I highly doubt it will ever have to render more than several hundred thousands polygons at a time. Just look at Oasen at http://graphics.cs.uni-sb.de/~morfiel/oasen/features.html : Some numbers to frighten children: 500.000 polygons heightfields > 1000 objects, ~30.000 polygons each level complexity: 15 Mio polygons 138 dynamical lightsources, all of them casting dynamic shadows from all objects to all objects The numbers already give a hint that this "game" is made for stressing the graphic library to the limit, not for you and I to play. > Doesn't sound that feasible to me :-/ > > But that page is also where you can find the quote I mentioned: > > "We are very much interested in evaluating new ways for computer > games and therefore like to cooperate with the gaming industry. > Thus if you are in such a position, please send us an email! " > > Maybe they've got a mailing list ? Possibly they would provide you with > more details if you contact them... > > But I doubt that it is the ultimate solution - there are certainly > drawbacks, and it's not necessarily suited for any purpose, either. > > Otherwise it would probably already be a lot more popular !? Well, I guess the answer to that question will remain unknown until someone decides to look more deeply into it. Ampere ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] VBOs - performance test results
Ampere K. Hardraade wrote: I'm afraid, you cannot expect people to purchase new hardware for an open source game to work ;-) Is new hardware really necessary? nope, it wasn't required - after all it is supposed to be "software-raytracing" and not hardware, but I *assume* without a corresponding hardware board your CPU would probably be abused as a GPU - almost exclusively ... The reason I brought the OpenRT topic up again is that (as far as I understand) it can run on most people's desktop. yes, but I somehow doubt that there would remain much idle CPU time - you'd probably at least need a dual-processor board - but again, I'm *guessing*. Probably, they wouldn't start developing prototype hardware boards: http://www.saarcor.de/ ...if the gains were not significant ? Now, if it can render a 350 million polygons model using a CPU that is slower than mine, then it should be able to handle FlightGear with ease. I am not so sure about that - in order to get representative data, one would need to have at least some simple tests available or maybe even a simple game that employs the software-based raytracing approach. On http://graphics.cs.uni-sb.de/RTGames/ there are various games mentioned, even screenshots are shown - and even very promising divx-videos - but there doesn't seem to be a simple demo for personal evaluation !? This might be the case because all these videos seem to have been created using clusters of a dozen or even more 1 GHZ machines ... Doesn't sound that feasible to me :-/ But that page is also where you can find the quote I mentioned: "We are very much interested in evaluating new ways for computer games and therefore like to cooperate with the gaming industry. Thus if you are in such a position, please send us an email! " Maybe they've got a mailing list ? Possibly they would provide you with more details if you contact them... But I doubt that it is the ultimate solution - there are certainly drawbacks, and it's not necessarily suited for any purpose, either. Otherwise it would probably already be a lot more popular !? --- Boris ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] TaxiDraw-0.2.2 released
David Luff wrote: On 10/19/04 at 11:57 AM Chris Metzler wrote: > I think that your idea to put a taxiway designator in the 'xxx' (bet this message gets flagged as spam now!) part of the record is an excellent one. The downside of course is that it would require X-Plane itself to understand it before it could be applied to the master dataset. I am not sure whether there's much communication ongoing between the two projects, anyway: David, as you might remember I recently also had some talks with the X-Plane folks because of the IVAO/VATSIM thing, Ben (the developer of XSquawkBox) also functions as a contractor for general X-Plane development, I am not sure whether I forwarded that particular eMail to you where he explicitly mentioned how grateful the X-Plane community is about various opensource tools that can (and are) also be used for X-Plane. So, based on that and on the mail exchanges I've had with him so far I am inclined to bet that he would probably not mind forwarding your request/recommendation to Austin Meyers (the X-Plane author). My impression is that the odds are looking good for such an inquiry ;-) - Boris ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] VBOs - performance test results
> I'm afraid, you cannot expect people to purchase new hardware for an > open source game to work ;-) Is new hardware really necessary? The reason I brought the OpenRT topic up again is that (as far as I understand) it can run on most people's desktop. Checking the 777's page: http://graphics.cs.uni-sb.de/MassiveRT/boeing777.html It says: Currently, we use a *single AMD Opteron 1.8GHz CPU*. The machine is a dual-CPU. We currently get around 1-3 frames per second at 640x480 pixels on that setup, depending on the actual view. Some simple views run even faster, the 1-3 fps correspond to the images as shown above. Now, if it can render a 350 million polygons model using a CPU that is slower than mine, then it should be able to handle FlightGear with ease. Ampere ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] DeHavilland Beaver
On Tue, 19 Oct 2004 13:00:12 -0500 "Curtis L. Olson" <[EMAIL PROTECTED]> wrote: > > Syd Adams just submitted a DeHavilland DHC-2 Beaver for inclusion in > CVS. > > I've had a chance to take it for a spin and it is really nice. It is a ton of fun. Does the flight modelling seem right to you? I went online and found a page that gives stall speeds for the Beaver of 40-55 knots; but in FG, the Beaver seems to stall for me below 80mph no matter what flaps or power. -c -- Chris Metzler [EMAIL PROTECTED] (remove "snip-me." to email) "As a child I understood how to give; I have forgotten this grace since I have become civilized." - Chief Luther Standing Bear pgpQok3Vhxmjp.pgp Description: PGP signature ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] TaxiDraw-0.2.2 released
On October 20, 2004 06:12 am, David Luff wrote: > >I'm wondering whether we know what the X-Plane format really *is*. > >Since the beginning of September, Robin Peel has been saying that a > >new set of files are coming out "next weekend, September 18." But he > >also says that these files won't work at all with earlier versions > >of X-Plane. That may simply be because of the new information content > >in fields that were basically dummy (see below) choking reads that > >don't know how to handle them; but it made me wonder if there's a file > >format change coming up. At the very least, his comments about being > >able to declare aprons separate from taxiways suggest a new record type. > > Well, I guess we'll find out eventually. Converters are easy to write, if > somewhat tedious. The current X-Plane format contains a flag indicating > whether to include runway distance remaining signs or not, so the change to > it should be good for you in that respect. May be it is time FlightGear should have its own file format? Ampere ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] VBOs - performance test results
Ampere K. Hardraade wrote: If we have to go through that much trouble to improve so little, we may as well as look into something more powerful... like OpenRT. the last time we talked about that here it was not much more than a "proof of concept"-thing ... it was definitely interesting, but if I didn't understand anything wrong it is certainly not a feasible option right now. I'm afraid, you cannot expect people to purchase new hardware for an open source game to work ;-) As long as it doesn't replace existing 3D technologies or at least offers a viable alternative, it's probably a bit early to consider doing such a significant step. But if I remember correctly the project's webpage had some requests that gaming companies should contact them if they are interested, so since the project is run by a German university I would not mind introducing FlightGear to them, on the other hand I personally understand that very request as an attempt to gain financial support by cooperating with such companies, something that FG certainly cannot provide, rather FG itself would probably benefit significantly if there was some sound financial basis ... just my 20 cents ;-) - Boris ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] View for a down facing camera
Birger Brunswiek said: > I'm trying to create a new view which is supposed to be a camera > fixed under the Cesna at the body. So far it looks like this: > >Camera View >false > > true > 0 > 0.2f > 0 > -1 > 0 > > > > So far so good... now I'm trying to change the pitch and heading defaults > of that camera. I've tried and but none of those > seems to have any effect... > What am I doing wrong? > > Birger I'm not sure if this was answered or not...been out of the loop for while now. You needed to specify this as a "lookfrom" view type (similar to cockpit view). Then you sould be able to specify offsets (e.g. pitch-offset-deg, heading-offset-deg) which will affect the direction of the camera. As far as your question goes, my guess is you have misunderstood the purpose of the eye path settings. These just specify where in the property tree the value for position or atitude of the camera (or eye) is stored. In this case you don't need that. Just use from-model-idx number 0 as you have. This indicates the position and attitude data is retrieved from the same location as the primary FDM's 3D Model Location (e.g. /orientation /position). In other words, this camera "eye" location and atitude is the same as "fdm" location and atitude, because it is attached to the aircraft. You only need some small adjustments to "offset" the camera from the origin of the FDM (and 3D Model). The x/y/z-offset-m properties are for adjusting the location down to the desired location below the aircraft. Looks like you got that. The pitch/roll/heading-offset-deg are for making the camera point to a direction different than the aircraft is pointing. Straight down would be 90.0 (or maybe -90.0) pitch-offset-deg. Note, you will probably want to make that 89 degrees or some value not quite 90.0 because of the singularity issue that we run into with the matrix methods. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] VBOs - performance test results
If we have to go through that much trouble to improve so little, we may as well as look into something more powerful... like OpenRT. Just my two cents. Ampere On October 19, 2004 03:51 pm, Roman Grigoriev wrote: > Frederic! If we have own scenegraph fully optimized to use VBO I think that > it will be our future. If you want I can give you my shaders to test fgfs > with it. > But I think for people who use in fgfs ortophoto terrain it's the best > thing Thanx in advance > Bye > > > -Fred ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] [OT] Aviation weblog: Land and Hold Short
David Megginson wrote: I have had little luck finding aviation weblogs (they're all about rants about politics, ...how would you then call the following: http://www.megginson.com/blogs/lahso/medicals.html ? ;-) (just kidding) BTW: talking of healthy presidents: Pres. Bush Senior did even do a parachute jump on his birthday this year, he talked about that on Larry King Live, whereas Larry King himself wasn't allowed to jump because of his health condition... hype about technology, or complaints about teenagers' social lives), I am sure you could attract some readers here by talking about the time when _you_ were a teenager ;-) so a couple of weeks ago, I decided to start my own. So far, it's heavy on content on light on good looks, so it's probably a fair reflection of its author. lol, if you add some of that sort of humor to your weblog, you'll certainly be able to maintain a steadily increasing reader community ;-) It's just a couple of weeks ago that I stumbled across a weblog on xsquawkbox.net, because of the IVAO/VATSIM discussion here on the list, that particular blog is maintained by the author of the X-Plane application that interfaces with IVATO/VATSIM networks - while his blog was definitely political, too - it did make for some amusing reading :-) If anyone here is interesting in taking a look, there are two ways to get at it. The best way to read it (or any weblog) is to add the RSS syndication URL to your desktop or online blog reader: http://www.megginson.com/blogs/lahso.xml I've noticed that you've provided this kind of "tutorial" on your webpage, too - how about also recommending one or two decent RSS feed- readers ? :-) (Haven't yet used that functionality much myself) Anyway, some of this makes really for some good reading: http://www.megginson.com/blogs/lahso/thumb60.html So, if you intend to maintain that type of contents you could certainly attract some interested readers, I think. Probably not only for real pilots, but some of this would certainly also be interesting for the flying FG community. Also, you mentioned somewhere that you'd have collected some links with "rules of thumb", how about providing some of these links in one of your future blogs ? And if I were you, I really wouldn't worry all that much about the layout/design part: I didn't have any problems whatsoever reading (all) pages - so it cannot be that bad ;-) -- Boris ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] status of aircraft carrier
Norman Vine wrote: > Sent: 20 October 2004 21:36 > To: FlightGear developers discussions > Subject: RE: [Flightgear-devel] status of aircraft carrier > > Vivian Meazza writes: > > > > Norman Vine > > > > > > see SimGear / simgear / math / sg_geodesy > > > void sgGeodToCart(double lat, double lon, double alt, double* xyz); > > > > > > > Not brilliant though. In the > > property tree Lat/Lon is in degrees, and altitude in ft, so that's a 2 > step > > conversion. > > Well the Property Tree is designed for users whereas > the 'C' code is primarily for developers. > > But isn't this what NASAL is for :-) > I'm doing it in C++ because I can reuse chunks of code that I wrote for submodels (not keen on re-inventing wheels), but, yes I think Nasal would be just as good for this task. I used that for quite a bit of the animation of the Seafire/Spitfire. I don't know if one would be preferred over the other: I'm happy to write code in either. Regards Vivian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] segfault in AI code
Just downloaded a fresh CVS FlightGear and found that the AI code is causing segfaults now. I'll recompile and run it through gdb. In the mean time beware that some aircraft that set up AI scenarios by default, like the T-38 or the hunter-2tanks, are crashing the sim. Dave -- David Culp [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] status of aircraft carrier
Vivian Meazza writes: > > Norman Vine > > > > see SimGear / simgear / math / sg_geodesy > > void sgGeodToCart(double lat, double lon, double alt, double* xyz); > > > > Not brilliant though. In the > property tree Lat/Lon is in degrees, and altitude in ft, so that's a 2 step > conversion. Well the Property Tree is designed for users whereas the 'C' code is primarily for developers. But isn't this what NASAL is for :-) Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] status of aircraft carrier
> -Original Message- > From: [EMAIL PROTECTED] [mailto:flightgear-devel- > [EMAIL PROTECTED] On Behalf Of Norman Vine > Sent: 20 October 2004 09:32 > To: FlightGear developers discussions > Subject: RE: [Flightgear-devel] status of aircraft carrier > > > > > I would like to have those positions of the arrester wires not in > lat/lon/alt > > but rather than in earth centered coordinates (cartesian coordinates: x > > towards lat/lon=0, z towards northpole). Just because we already have > all > > scenery values stored in this format. We have a scenery reference point > and > > relative to that, we have rotated vertices. > > < soapbox > > Arrestor wires and all other Model 'features' should be an XYZ offset from > the center point of the parent Model's Frame of reference > > FWIW using LLZ for anything except using user input / output is a step > back to the 'dark ages' of the pre satelite era and the advances in > Geodysey of the post Sputnik world. > > IMHO the FDMs should report in XYZ too, interestingly they all use it > instead of LLZ internally, and this XYZ is what all FGFS location code > should be based on :-) > > The list has heard me harp on this issue before and has rejected this > revolutionary idea but this archaic way of representing position > internally > in FGFS is IMO a *major* PITA in an otherwise reasonably modern > 'Round Earth' simulator. > < /soapbox > > > > With those values we can cheap compute (double valued) positions of > these > > vertices. And then transform them, just by translation and rotation, to > some > > coordinate frame required for modelling the hook, gear ... > > This holds true for any othe properly 'located' object. > That reminds me of the 2 men in a hot air balloon. Flying early one morning they got lost in the dawn mist, so the pilot turned down the burner and descended until he could see a chap on the ground. "Where are we?" he asked. "You're in a balloon", the chap replied. On hearing this, the pilot turned up the burner and ascended, saying: "good, that's sorted: we're just passing the Royal Military College of Science". The second man in the balloon was very impressed but asked: "how do you know that?" "Easy" said the pilot "it's the only place in the area where the information you get is totally accurate and totally bloody useless". Unless that is, someone can tell me how to access the X,Y,Z co-ordinates of a model, otherwise I'm going to have to do it in lat/long/alt. Regards, Vivian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] status of aircraft carrier
Norman Vine > Sent: 20 October 2004 18:08 > To: FlightGear developers discussions > Subject: RE: [Flightgear-devel] status of aircraft carrier > > Vivian Meazza writes: > > > > It would be easy to convert to X,Y,Z coordinates, if I knew the > equations > > see SimGear / simgear / math / sg_geodesy > > /** > * Convert a geodetic lat/lon/altitude to a cartesian point. > * > * @param lat (in) Latitude, in radians > * @param lon (in) Longitude, in radians > * @param alt (in) Altitude, in meters above the WGS84 ellipsoid > * @param xyz (out) Pointer to cartesian point. > */ > void sgGeodToCart(double lat, double lon, double alt, double* xyz); > Ta ever so, that's saved me hours of research. Not brilliant though. In the property tree Lat/Lon is in degrees, and altitude in ft, so that's a 2 step conversion. > > or, better, I could start in X,Y,Z. I think this is a step too far right now. Conversion will do at this stage of development. Thanks again Vivian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: DeHavilland Beaver
Ohh, and don't start it from 28R! $ fgfs --aircraft=dhc2F --lon=-122.43695 --lat=37.60588 --heading=155 m. :-) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: DeHavilland Beaver
* Melchior FRANZ -- Tuesday 19 October 2004 21:51: > * Curtis L. Olson -- Tuesday 19 October 2004 20:00: > > - It has a full animated 3d cockpit. > > Unfortunately, the ac3d/crease patch does only leave black holes where the > instruments should be. Looks very nice without that patch, though. ;-) Here's a version that works with the crease patch. It's not thought to be put into cvs, because the author probably has his own fix. http://members.aon.at/mfranz/dhc2f.ac.gz (58kB) compressed http://members.aon.at/mfranz/dhc2f.ac(375kB) uncompressed m. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] [OT] Aviation weblog: Land and Hold Short
I have had little luck finding aviation weblogs (they're all about rants about politics, hype about technology, or complaints about teenagers' social lives), so a couple of weeks ago, I decided to start my own. So far, it's heavy on content on light on good looks, so it's probably a fair reflection of its author. If anyone here is interesting in taking a look, there are two ways to get at it. The best way to read it (or any weblog) is to add the RSS syndication URL to your desktop or online blog reader: http://www.megginson.com/blogs/lahso.xml That way, whenever there's a new posting, the headline and summary will appear automatically. If you don't have a blog reader or you prefer the old bookmark-and-click approach, you can find a listing of the weblog entries here: http://www.megginson.com/blogs/lahso/ The title, "Land and Hold Short", refers to a common operation at busy airports where planes are using intersecting runways: a plane that's landing (usually a small one) has to agree to come to a complete stop before the intersection so that the other (often a big one) can land or takeoff at the same time. The title also represents the ideal of blog writing -- land a good idea, and keep it short. Unfortunately, I'm not really accomplishing that yet (especially the short part), but I'm practicing. I plan on posting an entry about FlightGear once I'm getting enough hits to make the publicity worthwhile. All the best, David -- http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] how to interface with flightgear
On Thu, 21 Oct 2004 01:26:54 +0800 "" <[EMAIL PROTECTED]> wrote: I am working on a autopilot project and we need a flight simulator to prove our control method before use it on a real aircraft. Is there any interface to get the attitude of aircraft from and send control data to flightgear. I mean get the altitude, rate, accelerate and so on from it and send rudder, elevator, aileron and throttle data to flightgear to control a aircraft. Thanks Out of curiousity, have you seen the facilities that JSBSim has to offer in the way of control systems (including autopilot)? Are you using Matlab? Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] how to interface with flightgear
In the network area (http://cvs.flightgear.org/cgi-bin/viewcvs/viewcvs.cgi/source/src/Network/?cvsroot=FlightGear-0.9) there is a data structure defined in net_ctrls.hxx that contains the data you want, but I don't think that it is being filled in by any of the FDMs. Jonathan Polley On Wednesday, October 20, 2004, at 12:34PM, <[EMAIL PROTECTED]> wrote: >I am working on a autopilot project and we need a flight simulator to prove >our control method before use it on a real aircraft. Is there any interface to >get the attitude of aircraft from and send control data to flightgear. I mean get >the altitude, rate, accelerate and so on from it and send rudder, elevator, >aileron and throttle data to flightgear to control a aircraft. Thanks > > > >___ >Flightgear-devel mailing list >[EMAIL PROTECTED] >http://mail.flightgear.org/mailman/listinfo/flightgear-devel >2f585eeea02e2c79d7b1d8c4963bae2d > > Of COURSE they can do that. They're engineers! ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] how to interface with flightgear
[EMAIL PROTECTED] wrote: I am working on a autopilot project and we need a flight simulator to prove our control method before use it on a real aircraft. Is there any interface to get the attitude of aircraft from and send control data to flightgear. I mean get the altitude, rate, accelerate and so on from it and send rudder, elevator, aileron and throttle data to flightgear to control a aircraft. Thanks Hi, you can use the properties tree. If you look in the source code there are examples of how to access the telnet server of FlightGear using several programming languages like C, java, perl, python, ...(in utils/ I think). Some properties are (you can find them in the File->Browse Internal Properties menu): /orientation/alpha-deg[0] /orientation/heading-deg[0] /orientation/pitch-deg[0] /orientation/roll-deg[0] /position/altitude-agl-ft[0] /position/altitude-ft[0] /position/latitude-deg[0] /position/longitude-deg[0] /velocities/airspeed-kt[0] /velocities/speed-down-fps[0] /velocities/speed-east-fps[0] /velocities/north-fps[0] /velocities/vertical-speed-fps[0] /controls/flight/aileron[0] /controls/flight/elevator[0] /controls/flight/rudder[0] /controls/engines/engine/throttle[0] The previous properties were all in double format and can be read or set (through a .get() or .set() method/function, see in the source code). The following are floats: /surface-positions/elevator-pos-norm[0] /surface-positions/left-aileron-pos-norm[0] /surface-positions/right-aileron-pos-norm[0] /surface-positions/rudder-pos-norm[0] There are dozens more, you can find them all if you click File->Browse Internal Properties while running FlightGear. A list of all properties does not exist at the moment, that is, not with all the properties: these are the ones I intend to use to test my own autopilot code (feel free to contact me). Greets, Steven ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] how to interface with flightgear
I am working on a autopilot project and we need a flight simulator to prove our control method before use it on a real aircraft. Is there any interface to get the attitude of aircraft from and send control data to flightgear. I mean get the altitude, rate, accelerate and so on from it and send rudder, elevator, aileron and throttle data to flightgear to control a aircraft. Thanks ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] status of aircraft carrier
Vivian Meazza writes: > > It would be easy to convert to X,Y,Z coordinates, if I knew the equations see SimGear / simgear / math / sg_geodesy /** * Convert a geodetic lat/lon/altitude to a cartesian point. * * @param lat (in) Latitude, in radians * @param lon (in) Longitude, in radians * @param alt (in) Altitude, in meters above the WGS84 ellipsoid * @param xyz (out) Pointer to cartesian point. */ void sgGeodToCart(double lat, double lon, double alt, double* xyz); > or, better, I could start in X,Y,Z. Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] status of aircraft carrier
Norman Vine wrote: > Sent: 20 October 2004 16:41 > To: FlightGear developers discussions > Subject: RE: [Flightgear-devel] status of aircraft carrier > > Vivian Meazza writes: > > > > Norman Vine wrote: > > > > > > > > < soapbox > > > > > > > FWIW using LLZ for anything except using user input / output is a step > > > back to the 'dark ages' of the pre satelite era and the advances in > > > Geodysey of the post Sputnik world. > > > > > > < /soapbox > > > > > Unless that is, someone can tell me how to access the X,Y,Z co-ordinates > of > > a model, otherwise I'm going to have to do it in lat/long/alt. > > You are talking about user input / output right ? > Which can all go thru a translation unit. At the moment it goes like this, (and it's working). I take the LLZ coordinates of the aircraft, (because that's all I can get right now), and the offset (feet) of the hook bill in its lowered position. I take the roll, pitch, and azimuth of the aircraft and use them to transform the offsets. I convert the output to degrees lat and long which, together with altitude is added to the original LLZ data to find the current position of the hook in LLZ terms. It would be easy to convert to X,Y,Z coordinates, if I knew the equations (I have suitable equations for ft to degrees lat/long) or, better, I could start in X,Y,Z. > I realize that Columbus came centuries after Hipparchus and > that Sputnik was only several decades ago :-) > Hmm ... Colombus ... well us Royal Navy chaps are a mite conservative. If it was good enough for Nelson ... no point in hurrying things :-) Regards, Vivian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] status of aircraft carrier
Vivian Meazza writes: > > Norman Vine wrote: > > > > > < soapbox > > > > > FWIW using LLZ for anything except using user input / output is a step > > back to the 'dark ages' of the pre satelite era and the advances in > > Geodysey of the post Sputnik world. > > > > < /soapbox > > > Unless that is, someone can tell me how to access the X,Y,Z co-ordinates of > a model, otherwise I'm going to have to do it in lat/long/alt. You are talking about user input / output right ? Which can all go thru a translation unit. I realize that Columbus came centuries after Hipparchus and that Sputnik was only several decades ago :-) Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] status of aircraft carrier
Norman Vine wrote: > Sent: 20 October 2004 09:32 > To: FlightGear developers discussions > Subject: RE: [Flightgear-devel] status of aircraft carrier > > > > > I would like to have those positions of the arrester wires not in > lat/lon/alt > > but rather than in earth centered coordinates (cartesian coordinates: x > > towards lat/lon=0, z towards northpole). Just because we already have > all > > scenery values stored in this format. We have a scenery reference point > and > > relative to that, we have rotated vertices. > > < soapbox > > Arrestor wires and all other Model 'features' should be an XYZ offset from > the center point of the parent Model's Frame of reference > > FWIW using LLZ for anything except using user input / output is a step > back to the 'dark ages' of the pre satelite era and the advances in > Geodysey of the post Sputnik world. > > IMHO the FDMs should report in XYZ too, interestingly they all use it > instead of LLZ internally, and this XYZ is what all FGFS location code > should be based on :-) > > The list has heard me harp on this issue before and has rejected this > revolutionary idea but this archaic way of representing position > internally > in FGFS is IMO a *major* PITA in an otherwise reasonably modern > 'Round Earth' simulator. > < /soapbox > > > > With those values we can cheap compute (double valued) positions of > these > > vertices. And then transform them, just by translation and rotation, to > some > > coordinate frame required for modelling the hook, gear ... > > This holds true for any othe properly 'located' object. That reminds me of the 2 men in a hot air balloon. Flying early one morning they got lost in the dawn mist, so the pilot turned down the burner and descended until he could see a chap on the ground. "Where are we?" he asked. "You're in a balloon", the chap replied. On hearing this, the pilot turned up the burner and ascended, saying: "good, that's sorted: we're just passing the Royal Military College of Science". The second man in the balloon was very impressed but asked: "how do you know that?" "Easy" said the pilot "it's the only place in the area where the information you get is totally accurate and totally bloody useless". Unless that is, someone can tell me how to access the X,Y,Z co-ordinates of a model, otherwise I'm going to have to do it in lat/long/alt. Regards, Vivian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Re: Submodels
Melchior FRANZ wrote: > Sent: 20 October 2004 14:39 > To: [EMAIL PROTECTED] > Subject: [Flightgear-devel] Re: Submodels > > [cvs, sticky attributes] > > * Melchior FRANZ -- Wednesday 20 October 2004 15:21: > > You can bring all files back to HEAD with the -A option. If you use the > -C > > option as well, then even your locally changed filea are saved away > > (.#foo.cxx.1.123) and overwritten by the HEAD files. > >$ cvs up -A >$ cvs up -AC > > Of course, you can easily check if you have anything sticky around. List > all > files with sticky attributes: > >$ for i in `find -name Entries`; do egrep -v "/$" $i|egrep -v "^D$"; > done > > and find all directories with sticky attibutes (tags): > >$ find|grep CVS/Tag > > Happy hunting! :-) > Nice if it were that easy! I use -A often as I go back and forth in cvs. Thanks for all the suggestions and help. I'm still trying! V. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Submodels
On Wednesday 20 October 2004 15:09, Vivian Meazza wrote: > > Try to run Flightgear with --log-level=info and look for these lines: > > > > Reading instruments from > > data/Aircraft/Generic/generic-instrumentation.xml Adding subsystem > > instrumentation > > Reading systems from data/Aircraft/Generic/generic-systems.xml > > Adding subsystem systems > > > > This is what you should get. If you get something like: "No > > instrumentation > > model specified for this model!" or "Failed to load instrumentation > > model: ", > > then something is wrong, obviously. > > What is likely to be wrong? If you get "No instrumentation ..." then FG is not parsing the instrument configuration file at all. If you get "Failed to load ..." then parsing has failed. I think that one of these two might be the reason for your problems. Either the config files never get parsed, or parsing of them fails. I would try to use a debugger to step through the code to see exactly what is happening. -- Roy Vegard Ovesen ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: Submodels
[cvs, sticky attributes] * Melchior FRANZ -- Wednesday 20 October 2004 15:21: > You can bring all files back to HEAD with the -A option. If you use the -C > option as well, then even your locally changed filea are saved away > (.#foo.cxx.1.123) and overwritten by the HEAD files. $ cvs up -A $ cvs up -AC Of course, you can easily check if you have anything sticky around. List all files with sticky attributes: $ for i in `find -name Entries`; do egrep -v "/$" $i|egrep -v "^D$"; done and find all directories with sticky attibutes (tags): $ find|grep CVS/Tag Happy hunting! :-) m. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: Submodels
* Roy Vegard Ovesen -- Wednesday 20 October 2004 14:31:
> I also updated from CVS this morning and all instruments still work, here. I
> guess that if all instruments and all systems in every aircraft were broken
> then a whole lot of other people would have noticed too.
Indeed! I'm running the very last version from cvs (HEAD), too, and I didn't
notice broken instruments, neither in the Hunter nor anywhere else.
I assume that you updated to HEAD already. People new to cvs are easily fooled
by "sticky" attributes. If you have once updated to a certain branch/tag, date,
or revision date, then cvs keeps this information and doesn't update the
concerned files any more -- without noticing you!
Examples:
$ cvs up -rRELEASE_0_9_6
$ cvs up -D'2 days ago'
$ cvs up -r1.123 foo.cxx
You can bring all files back to HEAD with the -A option. If you use the -C
option as well, then even your locally changed filea are saved away
(.#foo.cxx.1.123) and overwritten by the HEAD files. If unsure, make a copy
of the whole directory first ("cp -a FlightGear FlightGear~").
Or maybe it's something completely different ...
m.
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Submodels
Roy Vegard Ovesen: > Sent: 20 October 2004 13:31 > To: FlightGear developers discussions > Subject: Re: [Flightgear-devel] Submodels > > On Wednesday 20 October 2004 12:03, Vivian Meazza wrote: > > > > I have checked the path - I'm was the downloaded cvs data from 1522 > Monday. > > I have re-downloaded cvs data and source this morning and recompiled. > > > > I've changed the hunter to use the generic files - it already has custom > > electrics and instrumentation - still the altimeter, ASI, climb-rate and > > turn and slip don't work. Hsi and directional gyro work, but they take > > their input from the 'wrong' place. In the property browser all the > > instrument values are undefined. > > > > The P51d instruments also don't work, in fact all the instruments I have > > tested don't work. I suspect the instruments generically don't work. > > > > Can you reconfirm that all the hunter/seahawk/P51 instruments work for > you? > > And did you change anything in the hunter files? > > I also updated from CVS this morning and all instruments still work, here. > I > guess that if all instruments and all systems in every aircraft were > broken > then a whole lot of other people would have noticed too. That's the info I need: it's still got to be a local problem. Path looks the likely candidate. Everything looks like it's in the right place. > > I have not changed anything in the hunter or any other aircraft. > > Try to run Flightgear with --log-level=info and look for these lines: > > Reading instruments from data/Aircraft/Generic/generic-instrumentation.xml > Adding subsystem instrumentation > Reading systems from data/Aircraft/Generic/generic-systems.xml > Adding subsystem systems > > This is what you should get. If you get something like: "No > instrumentation > model specified for this model!" or "Failed to load instrumentation model: > ", > then something is wrong, obviously. What is likely to be wrong? > When Flightgear is running try to browse to this property: > /sim/instrumentation/path > It should contain "data/Aircraft/Generic/generic-instrumentation.xml" if > you > are using the generic configuration, or if you are using a custom made > configuration it should of course contain the path to that file. > > > > > I've gone back to cvs update as of 15 Oct: all the aircraft work > correctly. > > I conclude that this problem is caused by your new code. Unless you can > > confirm that the instruments work in all models in your location, or > tell > > me exactly what I have to do to correct the situation, I strongly > suggest > > that whatever has been done, be undone. > > I understand that you are frustrated, but IMHO the ability to configure > instrumentation and systems is an improvement. I also think that going > back > to them being hardcoded is a step in the wrong direction. I agree, it's definitely the right way forward, I'll keep on trying. It's only frustrating because I have been looking at the problem at the individual aircraft level, and I don't think that the problem lies there. It must be a more general problem. And it's going to be a "duh!!" when I get there. Regards, Vivian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Submodels
On Wednesday 20 October 2004 12:03, Vivian Meazza wrote: > > I have checked the path - I'm was the downloaded cvs data from 1522 Monday. > I have re-downloaded cvs data and source this morning and recompiled. > > I've changed the hunter to use the generic files - it already has custom > electrics and instrumentation - still the altimeter, ASI, climb-rate and > turn and slip don't work. Hsi and directional gyro work, but they take > their input from the 'wrong' place. In the property browser all the > instrument values are undefined. > > The P51d instruments also don't work, in fact all the instruments I have > tested don't work. I suspect the instruments generically don't work. > > Can you reconfirm that all the hunter/seahawk/P51 instruments work for you? > And did you change anything in the hunter files? I also updated from CVS this morning and all instruments still work, here. I guess that if all instruments and all systems in every aircraft were broken then a whole lot of other people would have noticed too. I have not changed anything in the hunter or any other aircraft. Try to run Flightgear with --log-level=info and look for these lines: Reading instruments from data/Aircraft/Generic/generic-instrumentation.xml Adding subsystem instrumentation Reading systems from data/Aircraft/Generic/generic-systems.xml Adding subsystem systems This is what you should get. If you get something like: "No instrumentation model specified for this model!" or "Failed to load instrumentation model: ", then something is wrong, obviously. When Flightgear is running try to browse to this property: /sim/instrumentation/path It should contain "data/Aircraft/Generic/generic-instrumentation.xml" if you are using the generic configuration, or if you are using a custom made configuration it should of course contain the path to that file. > > I've gone back to cvs update as of 15 Oct: all the aircraft work correctly. > I conclude that this problem is caused by your new code. Unless you can > confirm that the instruments work in all models in your location, or tell > me exactly what I have to do to correct the situation, I strongly suggest > that whatever has been done, be undone. I understand that you are frustrated, but IMHO the ability to configure instrumentation and systems is an improvement. I also think that going back to them being hardcoded is a step in the wrong direction. -- Roy Vegard Ovesen ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] RE: Flightgear-devel Digest, Vol 18, Issue 53
[EMAIL PROTECTED] wrote: > When I run fgfs to replay a data file which I saved, I got the following error: Could you provide all the command line options used to save the flight and which where used to replay the flight. Also, did you make sure --fdm=null was specified? Erik > > Running Main Loop > === > Updating time > Current Unix calendar time = 1098302223 warp = 28320 > Current GMT = 10/20/2004 19:57:3 > Current Unix calendar time = 1098302223 warp = 28320 > Current GMT = 10/20/2004 19:57:3 > Current Julian Date = 2.4533e+06 > COURSE: GMT = 9/20/104 19:57:03 > March 21 noon (GMT) = 1079870400 > Time since 3/21/104 GMT = 213.331 > days = 213 hours = 19.9508 lon = 0 lst = 22.1508 > COURSE: GMT = 9/20/104 19:57:03 > March 21 noon (GMT) = 1079870400 > Time since 3/21/104 GMT = 213.331 > days = 213 hours = 19.9508 lon = 122.357 lst = 13.9937 > Current lon=0.00 Sidereal Time = 21.9033 > gst => 141.925 > Current LOCAL Sidereal Time = 13.7461 (13.7679) (diff = -0.247568) > Elapsed time interval is = 4226000, previous remainder is = 6073 > --> Frame rate is = 3 > Model iterations needed = 507, new remainder = 7073 > interpolate(): lookup error, x to small = -5.16431 > interpolate(): lookup error, x to small = -2.16431 > Updating adjusted fog parameters. > Segmentation fault (core dumped) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Linker problems solved
I've downloaded the patched files in CVS. They are updated late in the morning (for me) but I've downloaded the files about two hours before. However now the things works right. Thanks, Luca Libero ADSL: navighi gratis a 1.2 Mega, senza canone e costi di attivazione. Abbonati subito su http://www.libero.it ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] RE: Flightgear-devel Digest, Vol 18, Issue 53
When I run fgfs to replay a data file which I saved, I got the following error: Running Main Loop === Updating time Current Unix calendar time = 1098302223 warp = 28320 Current GMT = 10/20/2004 19:57:3 Current Unix calendar time = 1098302223 warp = 28320 Current GMT = 10/20/2004 19:57:3 Current Julian Date = 2.4533e+06 COURSE: GMT = 9/20/104 19:57:03 March 21 noon (GMT) = 1079870400 Time since 3/21/104 GMT = 213.331 days = 213 hours = 19.9508 lon = 0 lst = 22.1508 COURSE: GMT = 9/20/104 19:57:03 March 21 noon (GMT) = 1079870400 Time since 3/21/104 GMT = 213.331 days = 213 hours = 19.9508 lon = 122.357 lst = 13.9937 Current lon=0.00 Sidereal Time = 21.9033 gst => 141.925 Current LOCAL Sidereal Time = 13.7461 (13.7679) (diff = -0.247568) Elapsed time interval is = 4226000, previous remainder is = 6073 --> Frame rate is = 3 Model iterations needed = 507, new remainder = 7073 interpolate(): lookup error, x to small = -5.16431 interpolate(): lookup error, x to small = -2.16431 Updating adjusted fog parameters. Segmentation fault (core dumped) Does any one know why this happened and how to debug it? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of [EMAIL PROTECTED] Sent: Wednesday, October 20, 2004 6:55 PM To: [EMAIL PROTECTED] Subject: Flightgear-devel Digest, Vol 18, Issue 53 Send Flightgear-devel mailing list submissions to [EMAIL PROTECTED] To subscribe or unsubscribe via the World Wide Web, visit http://mail.flightgear.org/mailman/listinfo/flightgear-devel or, via email, send a message with subject or body 'help' to [EMAIL PROTECTED] You can reach the person managing the list at [EMAIL PROTECTED] When replying, please edit your Subject line so it is more specific than "Re: Contents of Flightgear-devel digest..." Today's Topics: 1. Re: TaxiDraw-0.2.2 released (David Luff) 2. Linker problems with CVS version (Luca Masera) 3. RE: Submodels (Vivian Meazza) 4. kr_87 linker problems solved: was an error in "instrument_mgr.cxx" (Luca Masera) 5. Re: TaxiDraw-0.2.2 released (David Luff) 6. Re: kr_87 linker problems solved: was an error in "instrument_mgr.cxx" (Frederic Bouvier) -- Message: 1 Date: Wed, 20 Oct 2004 10:43:57 +0100 From: "David Luff" <[EMAIL PROTECTED]> Subject: Re: [Flightgear-devel] TaxiDraw-0.2.2 released To: "FlightGear developers discussions" <[EMAIL PROTECTED]> Message-ID: <[EMAIL PROTECTED]> Content-Type: text/plain; charset="us-ascii" On 10/19/04 at 11:57 AM Chris Metzler wrote: >Finally, I'm wondering how you're going to handle conflicts between future >X-Plane data releases, and changes that people have sent to you. For >example, suppose an FG user sends some changes to an airport to you; and >suppose some X-Plane user sends some changes to the same airport to Robin >Peel (or the DAFIF changes for that airport). The next X-Plane dataset >contains the changes that Robin Peel received, which are different from >the ones you have. How would that get resolved? Go with theirs? Go with >ours? Contact the person who sent you changes to review the situation and >update? > Well, in a way this is no different from before, in that several folk could have separately sent Robin submissions for the same airport during the same data cycle. There's really no way round this - at least the airport in question should end up with some taxiways at the end of the day. I shall endeavour to get them sent on to him as soon as possible once he's back in communication in order to minimise the chance of this. FWIW, don't bother doing KOXR, KGYY, KDPA or KCPU or you'll be duplicating my work. At the end of the day, I figured that maintaining some sort of diff to the master database was the only way that TaxiDraw users would get to see their stuff in FlightGear in the near future, especially given that regenerating the scenery oneself is somewhat non-trivial, and requires some extremely large downloads. I guess we'll see how it works out in time. Cheers - Dave This message has been scanned but we cannot guarantee that it and any attachments are free from viruses or other damaging content: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. -- Message: 2 Date: Wed, 20 Oct 2004 11:59:23 +0200 From: "Luca Masera" <[EMAIL PROTECTED]> Subject: [Flightgear-devel] Linker problems with CVS version To: "flightgear-devel" <[EMAIL PROTECTED]> Message-ID: <[EMAIL PROTECTED]> Content-Type: text/plain; charset=iso-8859-1 Hi everyone, I've downloaded the CVS patches to update my version of FlightGear. They compile but I've a lot of problems from the linker. They are: kr_87.obj : error LNK2005: "public: __thiscall FGKR_87::FGKR_87(class SGProperty
Re: [Flightgear-devel] kr_87 linker problems solved: was an error in "instrument_mgr.cxx"
Selon Luca Masera <[EMAIL PROTECTED]>: > I've solved the linker error in the kr_87 object. It's an error in the file > instrument_mgr.cxx into the > include list, caused by the include of a the file kr_87.cxx instead of > kr_87.hxx. > The other problems still remain. It's already fixed in CVS. -Fred ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] kr_87 linker problems solved: was an error in "instrument_mgr.cxx"
I've solved the linker error in the kr_87 object. It's an error in the file instrument_mgr.cxx into the include list, caused by the include of a the file kr_87.cxx instead of kr_87.hxx. The other problems still remain. Bye, Luce Libero ADSL: navighi gratis a 1.2 Mega, senza canone e costi di attivazione. Abbonati subito su http://www.libero.it ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] TaxiDraw-0.2.2 released
On 10/19/04 at 11:57 AM Chris Metzler wrote: > >I'm wondering whether we know what the X-Plane format really *is*. >Since the beginning of September, Robin Peel has been saying that a >new set of files are coming out "next weekend, September 18." But he >also says that these files won't work at all with earlier versions >of X-Plane. That may simply be because of the new information content >in fields that were basically dummy (see below) choking reads that >don't know how to handle them; but it made me wonder if there's a file >format change coming up. At the very least, his comments about being >able to declare aprons separate from taxiways suggest a new record type. > Well, I guess we'll find out eventually. Converters are easy to write, if somewhat tedious. The current X-Plane format contains a flag indicating whether to include runway distance remaining signs or not, so the change to it should be good for you in that respect. >On a related note, since the X-Plane files are apparently going to support >this soon, is there any possibility of being able to "label" taxiways with >identifiers (e.g. "taxiway A")? I know that right now, we don't do >anything with that information; but we might in the future, with sign >placement or ground control instructions or whatever, and if people have >that information and the opportunity to add it to the database, we might >as well, rather than having to go back and add it later. Something >along these lines (re: taxiways and aprons): > >http://baron.flightgear.org/pipermail/flightgear-devel/2004-July/029106.htm l > I think that your idea to put a taxiway designator in the 'xxx' (bet this message gets flagged as spam now!) part of the record is an excellent one. The downside of course is that it would require X-Plane itself to understand it before it could be applied to the master dataset. On the other hand, genapts could be made to understand it as an extension to the default format. And if as you say the X-Plane format is likely to contain it soon then that's excellent. What I suggest is that the TaxiDraw project file be allowed to keep extra information such as this, perhaps in xml format. Then, when exporting one can simply export the information relevant at the time for the format exported to. One could possible generate the airport signage directly from the TaxiDraw project files, or maybe by exporting the extra data into the X-Plane data as an extension that genapts understands. Once X-Plane format officially includes it, it can be exported from the TaxiDraw project files into whatever format it uses to understand it. Some of the other issues you bring up in the archived post you mention are similar to those that Paul Surgeon brings up in this thread - I'll think about it and reply again. Cheers - Dave This message has been scanned but we cannot guarantee that it and any attachments are free from viruses or other damaging content: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Submodels
Roy Vegard Ovesen > Sent: 20 October 2004 00:32 > To: FlightGear developers discussions > Subject: Re: [Flightgear-devel] Submodels > > On Tuesday 19 October 2004 19:42, Vivian Meazza wrote: > > It's not obviously a path problem. My preferences.xml file was updated > at > > 15:22 yesterday, and has the right paths to the new generic files. > However, > > the properties relating to instruments are empty - hence broken > instruments > > > > :-). But if they work for you, the problem must be local, so I'll keep > > > > looking. Since it's all the instruments the common factor is the > electrical > > supply, so I'll start there. > > I would suggest that you try to create custom systems and instrumentation > configuration files for your aircraft. Use the generic ones as a start. I > think that you should remove the GPS instrument ;-) and maybe the nav > radios. > I have checked the path - I'm was the downloaded cvs data from 1522 Monday. I have re-downloaded cvs data and source this morning and recompiled. I've changed the hunter to use the generic files - it already has custom electrics and instrumentation - still the altimeter, ASI, climb-rate and turn and slip don't work. Hsi and directional gyro work, but they take their input from the 'wrong' place. In the property browser all the instrument values are undefined. The P51d instruments also don't work, in fact all the instruments I have tested don't work. I suspect the instruments generically don't work. Can you reconfirm that all the hunter/seahawk/P51 instruments work for you? And did you change anything in the hunter files? I've gone back to cvs update as of 15 Oct: all the aircraft work correctly. I conclude that this problem is caused by your new code. Unless you can confirm that the instruments work in all models in your location, or tell me exactly what I have to do to correct the situation, I strongly suggest that whatever has been done, be undone. Regards, Vivian P.S. I have wasted a day's work on this issue, and my teddy bear has now been thrown out of the pram. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Linker problems with CVS version
Hi everyone, I've downloaded the CVS patches to update my version of FlightGear. They compile but I've a lot of problems from the linker. They are: kr_87.obj : error LNK2005: "public: __thiscall FGKR_87::FGKR_87(class SGPropertyNode *)" (??0FGKR_87@@[EMAIL PROTECTED]@@@Z) already defined in instrument_mgr.obj kr_87.obj : error LNK2005: "public: virtual __thiscall FGKR_87::~FGKR_87(void)" (??1FGKR_87@@[EMAIL PROTECTED]) already defined in instrument_mgr.obj kr_87.obj : error LNK2005: "public: virtual void __thiscall FGKR_87::init(void)" ([EMAIL PROTECTED]@@UAEXXZ) already defined in instrument_mgr.obj kr_87.obj : error LNK2005: "public: virtual void __thiscall FGKR_87::unbind(void)" ([EMAIL PROTECTED]@@UAEXXZ) already defined in instrument_mgr.obj kr_87.obj : error LNK2005: "public: int __thiscall FGKR_87::get_stby_freq(void)const " ([EMAIL PROTECTED]@@QBEHXZ) already defined in instrument_mgr.obj kr_87.obj : error LNK2005: "public: void __thiscall FGKR_87::search(void)" ([EMAIL PROTECTED]@@QAEXXZ) already defined in instrument_mgr.obj kr_87.obj : error LNK2005: "public: virtual void __thiscall FGKR_87::bind(void)" ([EMAIL PROTECTED]@@UAEXXZ) already defined in instrument_mgr.obj kr_87.obj : error LNK2005: "public: virtual void __thiscall FGKR_87::update(double)" ([EMAIL PROTECTED]@@[EMAIL PROTECTED]) already defined in instrument_mgr.obj kr_87.obj : warning LNK4006: "public: __thiscall FGKR_87::FGKR_87(class SGPropertyNode *)" (??0FGKR_87@@[EMAIL PROTECTED]@@@Z) already defined in instrument_mgr.obj; second definition ignored kr_87.obj : warning LNK4006: "public: virtual __thiscall FGKR_87::~FGKR_87(void)" (??1FGKR_87@@[EMAIL PROTECTED]) already defined in instrument_mgr.obj; second definition ignored kr_87.obj : warning LNK4006: "public: virtual void __thiscall FGKR_87::init(void)" ([EMAIL PROTECTED]@@UAEXXZ) already defined in instrument_mgr.obj; second definition ignored kr_87.obj : warning LNK4006: "public: virtual void __thiscall FGKR_87::unbind(void)" ([EMAIL PROTECTED]@@UAEXXZ) already defined in instrument_mgr.obj; second definition ignored kr_87.obj : warning LNK4006: "public: int __thiscall FGKR_87::get_stby_freq(void)const " ([EMAIL PROTECTED]@@QBEHXZ) already defined in instrument_mgr.obj; second definition ignored kr_87.obj : warning LNK4006: "public: void __thiscall FGKR_87::search(void)" ([EMAIL PROTECTED]@@QAEXXZ) already defined in instrument_mgr.obj; second definition ignored kr_87.obj : warning LNK4006: "public: virtual void __thiscall FGKR_87::bind(void)" ([EMAIL PROTECTED]@@UAEXXZ) already defined in instrument_mgr.obj; second definition ignored kr_87.obj : warning LNK4006: "public: virtual void __thiscall FGKR_87::update(double)" ([EMAIL PROTECTED]@@[EMAIL PROTECTED]) already defined in instrument_mgr.obj; second definition ignored Creating library .\Release/FlightGear.lib and object .\Release/FlightGear.exp hud.obj : error LNK2019: unresolved external symbol "float __cdecl get_anzg(void)" (?get_anzg@@YAMXZ) referenced in function "class instr_item * __cdecl readCard(class SGPropertyNode const *)" (?readCard@@YAPAVinstr_item@@PBVSGPropertyNode@@@Z) hud.obj : error LNK2019: unresolved external symbol "float __cdecl get_Ax(void)" (?get_Ax@@YAMXZ) referenced in function "class instr_item * __cdecl readLabel(class SGPropertyNode const *)" (?readLabel@@YAPAVinstr_item@@PBVSGPropertyNode@@@Z) hud_ladr.obj : error LNK2001: unresolved external symbol "float __cdecl get_Ax(void)" (?get_Ax@@YAMXZ) hud.obj : error LNK2019: unresolved external symbol "float __cdecl get_aux18(void)" (?get_aux18@@YAMXZ) referenced in function "class instr_item * __cdecl readLabel(class SGPropertyNode const *)" (?readLabel@@YAPAVinstr_item@@PBVSGPropertyNode@@@Z) hud.obj : error LNK2019: unresolved external symbol "float __cdecl get_aux17(void)" (?get_aux17@@YAMXZ) referenced in function "class instr_item * __cdecl readLabel(class SGPropertyNode const *)" (?readLabel@@YAPAVinstr_item@@PBVSGPropertyNode@@@Z) hud.obj : error LNK2019: unresolved external symbol "float __cdecl get_aux16(void)" (?get_aux16@@YAMXZ) referenced in function "class instr_item * __cdecl readLabel(class SGPropertyNode const *)" (?readLabel@@YAPAVinstr_item@@PBVSGPropertyNode@@@Z) hud.obj : error LNK2019: unresolved external symbol "float __cdecl get_aux15(void)" (?get_aux15@@YAMXZ) referenced in function "class instr_item * __cdecl readLabel(class SGPropertyNode const *)" (?readLabel@@YAPAVinstr_item@@PBVSGPropertyNode@@@Z) hud.obj : error LNK2019: unresolved external symbol "float __cdecl get_aux14(void)" (?get_aux14@@YAMXZ) referenced in function "class instr_item * __cdecl readLabel(class SGPropertyNode const *)" (?readLabel@@YAPAVinstr_item@@PBVSGPropertyNode@@@Z) hud.obj : error LNK2019: unresolved external symbol "float __cdecl get_aux13(void)" (?get_aux13@@YAMXZ) referenced in function "class instr_item * __cdecl readLabel(class SGPropertyNode const *)" (?readLabel@@YAPAVinstr_item@@PBVSGPrope
Re: [Flightgear-devel] TaxiDraw-0.2.2 released
On 10/19/04 at 11:57 AM Chris Metzler wrote: >Finally, I'm wondering how you're going to handle conflicts between future >X-Plane data releases, and changes that people have sent to you. For >example, suppose an FG user sends some changes to an airport to you; and >suppose some X-Plane user sends some changes to the same airport to Robin >Peel (or the DAFIF changes for that airport). The next X-Plane dataset >contains the changes that Robin Peel received, which are different from >the ones you have. How would that get resolved? Go with theirs? Go with >ours? Contact the person who sent you changes to review the situation and >update? > Well, in a way this is no different from before, in that several folk could have separately sent Robin submissions for the same airport during the same data cycle. There's really no way round this - at least the airport in question should end up with some taxiways at the end of the day. I shall endeavour to get them sent on to him as soon as possible once he's back in communication in order to minimise the chance of this. FWIW, don't bother doing KOXR, KGYY, KDPA or KCPU or you'll be duplicating my work. At the end of the day, I figured that maintaining some sort of diff to the master database was the only way that TaxiDraw users would get to see their stuff in FlightGear in the near future, especially given that regenerating the scenery oneself is somewhat non-trivial, and requires some extremely large downloads. I guess we'll see how it works out in time. Cheers - Dave This message has been scanned but we cannot guarantee that it and any attachments are free from viruses or other damaging content: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] TaxiDraw-0.2.2 released
On 10/19/04 at 8:41 PM Paul Surgeon wrote: >I suggest that changes made override the "official" data until someone has >a >chance to review the problem airport. We can't have people spending hours >building nice taxiways and then having the runways dancing around the >place >every time there is an update. >I know I would be a little upset if I've spent 100 hours building taxiways >and >10% of them no longer line up with the runways 6 months down the line. > I don't think that this should be a big problem anymore. I believe that most of the runway shifting occured when he (Robin) moved over to the DAFIF as the base data, and a lot of incorrectly user-positioned runways got moved. Of course, some correctly user positioned runways got moved to incorrect DAFIF positions (like at Nottingham!). However, if a shift of all runways at a given airport does now occur, it's very easy to simply drag or rotate the taxiways en-masse to the new position in TaxiDraw. Simply draw a selection box round them all and do it. If some of the runways shift with respect to others then it implies that they weren't layed out correctly to begin with, and that sort of thing really needs sorting before starting on a Taxiway layout. If using the USGS photos as a backdrop then keep in mind that a number of runways have been built or extended since the photos were taken. Cheers - Dave This message has been scanned but we cannot guarantee that it and any attachments are free from viruses or other damaging content: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] status of aircraft carrier
> > I would like to have those positions of the arrester wires not in lat/lon/alt > but rather than in earth centered coordinates (cartesian coordinates: x > towards lat/lon=0, z towards northpole). Just because we already have all > scenery values stored in this format. We have a scenery reference point and > relative to that, we have rotated vertices. < soapbox > Arrestor wires and all other Model 'features' should be an XYZ offset from the center point of the parent Model's Frame of reference FWIW using LLZ for anything except using user input / output is a step back to the 'dark ages' of the pre satelite era and the advances in Geodysey of the post Sputnik world. IMHO the FDMs should report in XYZ too, interestingly they all use it instead of LLZ internally, and this XYZ is what all FGFS location code should be based on :-) The list has heard me harp on this issue before and has rejected this revolutionary idea but this archaic way of representing position internally in FGFS is IMO a *major* PITA in an otherwise reasonably modern 'Round Earth' simulator. < /soapbox > > With those values we can cheap compute (double valued) positions of these > vertices. And then transform them, just by translation and rotation, to some > coordinate frame required for modelling the hook, gear ... This holds true for any othe properly 'located' object. Norman "Give me a place to stand and I can draw the World" ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] status of aircraft carrier
Mathias Fröhlich wrote: > Sent: 20 October 2004 07:41 > To: FlightGear developers discussions > Subject: Re: [Flightgear-devel] status of aircraft carrier > > On Dienstag 19 Oktober 2004 21:23, Vivian Meazza wrote: > > > Hmm, > > > I am not satisfied with anything which is only working on a per frame > > > basis. > > > Just because, if so, we will have different bevour of our physical > models > > > dependent of the frammerate. > > > > I think I put this bit badly. The geodetic output would be dependent on > the > > speed of an iteration loop. If we are only modeling an arrester wire > > _surface_ it should suffice. I can generate some proof-of-principle code > > for this quite readily, I think. I'll see what I can do. > Ok, let's start now :) > I would like to have those positions of the arrester wires not in > lat/lon/alt > but rather than in earth centered coordinates (cartesian coordinates: x > towards lat/lon=0, z towards northpole). Just because we already have all > scenery values stored in this format. We have a scenery reference point > and > relative to that, we have rotated vertices. > With those values we can cheap compute (double valued) positions of these > vertices. And then transform them, just by translation and rotation, to > some > coordinate frame required for modelling the hook, gear ... We calculated the output in geodetic terms (lat/long/alt) for submodels so that they could be displayed, and it's no problem to output in x,y,z aircraft terms. It didn't seem to be expensive computationally. Further, lat/long/alt was the easiest to get at for the aircraft location. I think that I'll need some help here with the necessary conversion factors. I'll look into it further. > > If you use geodetic lat/lon, you need to transform the values to geodetic > lat/lon/alt values which is expensive as such since this requires the use > of > an iteration method. And then transform those values back to that same > flat > coordinate space suitable for comuting ground reactions. > For that backtransform, I can't think of anything not using those earth > centered corrdinates. Do we need ground reactions as an intrinsic part of this code? Although I can see that it might represent an opportunity to improve the current situation. > So all together: if lat/lon/alt is omitted in those computations, we can > get > the same effect with less computations. Yes, agreed. > What I have here in my private tree, is code to have a small, per FDM > instance, cache of ground tiles around the aircraft. With this one it is > easy > to taxi on slopes. Also if such arrester wires are stored there, it would > be > easy to compute the interactions with them. > Intersections with those few triangles can then be done often per > timestep, > since there are only few triangles in that cache. The cache itself is at > the > moment filled on demand, whenever the FDM cannot find a triangle below the > contact point, the scenegraph is queried for a new triangle. > That works for our scenery, but for that simple plane modelling the > arrester > wires, this does not work, since we find a triangle from the scenery, we > do > never query the triangles modelling the wires. > > What I plan to do here, is to build up a cache of all triangles in the > area of > an aircraft. This is easy to do with the hierarchical boundingbox > intersection routines from ssg*. > Having that cache, then implement wires as geometry nodes in the scene > graph, > which will then show up in the cache if we are near them. Intersection > with > geometry nodes in that cache can be implemented using ssg routines. > Coupling the results into a FDM is straight forward. Good > This approach with that cache would also allow to implement this stuff > together with FDM's in child processes or even different machines, like > Curt > was talking about some time ago. > > > My main conceptual difficulty is the compass alignment of the arrester > wire > > surface. If we test the hook position in geodetic terms, i.e. lat a < > hook > > pos < lat b etc. how do we account for the odd triangles at the corners? > See above ... > Use cartesian coordinates for that and then use ssg* for that. > My head includes the solutions here :) > Seriously, I have much of a concept here. So if we can work together, we > might > be faster :) Good, let's go for it. > > Good point. The probability of catching a wire given that the hook > > intersects the wire surface is ... ? Some function of hook design, > number > > of wires, aircraft velocities, ship velocities ... some pure chance ... > ? > Yep, this kind of stuff. But not relevant at this stage of development... Just teasing :-) - some arbitrary number related to number of wires in the surface and aircraft type will do in due course: Buccaneers almost always caught a wire, Gannets suffered from hook skip and often had to do a bolter. > With that cache it would also be easy to model individual wires. If we > have > them determi
Re: [Flightgear-devel] status of aircraft carrier
On Dienstag 19 Oktober 2004 21:23, Vivian Meazza wrote: > > Hmm, > > I am not satisfied with anything which is only working on a per frame > > basis. > > Just because, if so, we will have different bevour of our physical models > > dependent of the frammerate. > > I think I put this bit badly. The geodetic output would be dependent on the > speed of an iteration loop. If we are only modeling an arrester wire > _surface_ it should suffice. I can generate some proof-of-principle code > for this quite readily, I think. I'll see what I can do. Ok, let's start now :) I would like to have those positions of the arrester wires not in lat/lon/alt but rather than in earth centered coordinates (cartesian coordinates: x towards lat/lon=0, z towards northpole). Just because we already have all scenery values stored in this format. We have a scenery reference point and relative to that, we have rotated vertices. With those values we can cheap compute (double valued) positions of these vertices. And then transform them, just by translation and rotation, to some coordinate frame required for modelling the hook, gear ... If you use geodetic lat/lon, you need to transform the values to geodetic lat/lon/alt values which is expensive as such since this requires the use of an iteration method. And then transform those values back to that same flat coordinate space suitable for comuting ground reactions. For that backtransform, I can't think of anything not using those earth centered corrdinates. So all together: if lat/lon/alt is omitted in those computations, we can get the same effect with less computations. What I have here in my private tree, is code to have a small, per FDM instance, cache of ground tiles around the aircraft. With this one it is easy to taxi on slopes. Also if such arrester wires are stored there, it would be easy to compute the interactions with them. Intersections with those few triangles can then be done often per timestep, since there are only few triangles in that cache. The cache itself is at the moment filled on demand, whenever the FDM cannot find a triangle below the contact point, the scenegraph is queried for a new triangle. That works for our scenery, but for that simple plane modelling the arrester wires, this does not work, since we find a triangle from the scenery, we do never query the triangles modelling the wires. What I plan to do here, is to build up a cache of all triangles in the area of an aircraft. This is easy to do with the hierarchical boundingbox intersection routines from ssg*. Having that cache, then implement wires as geometry nodes in the scene graph, which will then show up in the cache if we are near them. Intersection with geometry nodes in that cache can be implemented using ssg routines. Coupling the results into a FDM is straight forward. This approach with that cache would also allow to implement this stuff together with FDM's in child processes or even different machines, like Curt was talking about some time ago. > My main conceptual difficulty is the compass alignment of the arrester wire > surface. If we test the hook position in geodetic terms, i.e. lat a < hook > pos < lat b etc. how do we account for the odd triangles at the corners? See above ... Use cartesian coordinates for that and then use ssg* for that. My head includes the solutions here :) Seriously, I have much of a concept here. So if we can work together, we might be faster :) > Good point. The probability of catching a wire given that the hook > intersects the wire surface is ... ? Some function of hook design, number > of wires, aircraft velocities, ship velocities ... some pure chance ... ? Yep, this kind of stuff. But not relevant at this stage of development... With that cache it would also be easy to model individual wires. If we have them deterministically modelled, multiply with some catch propability. Greetings Mathias -- Mathias Fröhlich, email: [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
