[Flightgear-devel] Custom SRTM-3 Scenery Problems
Hi Guys! Long time ago I created my scenery with hi resolution (100 m) I use 03.09.2003 flightgear simgear and terragear CVS version. All works fine but now I download from CVS flightgear and simgear and found that my scenery not loaded :)) but KSFO loaded fine. BTW my btg files has size approx 440 Kbytes. What I did wrong? When I loaded my scenery airports loaded surrounded by ocean. Thanx in advance Bye ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: [Flightgear-cvslogs] CVS: data/Aircraft/pa28-161
David Megginson <[EMAIL PROTECTED]> wrote: > Update of /var/cvs/FlightGear-0.9/data/Aircraft/pa28-161 > In directory baron:/tmp/cvs-serv12589 > Modified Files: > pa28-161-yasim-set.xml > Log Message: > Change camera position so that model doesn't rotate around the nose. I can't withstand the impression that changing the _camera_ position didn't lead to the intended success. Take a simple stick and rotate it around one of its ends. For an observer the phenomenon is still the same even when he changes his viewpoint. If you want to rotate the stick around its middle you really have to change the centre of rotation which means, that one end of the stick goes up and the other end goes down. At least in the _outside_ views the PA-28 still rotates around its nose after the recent changes, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] RAM disk / Unix
"Jon S Berndt" <[EMAIL PROTECTED]> wrote: > On Tue, 10 Feb 2004 15:06:41 -0800 > Andy Ross <[EMAIL PROTECTED]> wrote: >>> Jon S. Berndt wrote: >>> > It is thought that the use of a RAM disk might help. >>My interpretation was that their problem was latency, not I/O >>throughput. The program cooks along using 100% of the CPU, then it >>needs to load a giant data set off the disk, [...] > Yes, it seems to be a latency issue. There are still 'silicon disks' that attach to a SCSI channel - very expensive but really nice. You might want to prefetch your data from the hard disk to such a silicon disk before you really use it. If the hard disk read operations are predictabe, there is an alternative in employing a CacheFS on top of XFS and increase the read-ahead number in /var/sysgen/stune (see /var/sysgen/mtune/cachefs for explanation). On the other hand it might be easier to 'preload' the data into memory and prevent this memory area to being swapped out (there should be some operating system call), Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: [Flightgear-cvslogs] CVS:data/Aircraft/pa28-161
Martin wrote: > > David Megginson <[EMAIL PROTECTED]> wrote: > > Update of /var/cvs/FlightGear-0.9/data/Aircraft/pa28-161 > > In directory baron:/tmp/cvs-serv12589 > > > Modified Files: > > pa28-161-yasim-set.xml > > Log Message: > > Change camera position so that model doesn't rotate around the nose. > > I can't withstand the impression that changing the _camera_ > position didn't lead to the intended success. Take a simple > stick and rotate it around one of its ends. For an observer > the phenomenon is still the same even when he changes his > viewpoint. If you want to rotate the stick around its middle > you really have to change the centre of rotation which means, > that one end of the stick goes up and the other end goes down. > > At least in the _outside_ views the PA-28 still rotates > around its nose after the recent changes, > We've been here before haven't we? In developing the Hunter model I first put the model origin at the nose to conform to the YASIM origin, but the model then rotated about the nose - most disconcerting in outside views! I moved the model (not the YASIM) origin to the CofG - the model behaves nicely in all views. It's not strictly correct on the ground, because the model has differential braking, and should more or less rotate around the braked wheel, but you would have to have a very sharp eye to spot the deliberate :-) mistake. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: data/Aircraft/pa28-161
Martin Spott wrote: I can't withstand the impression that changing the _camera_ position didn't lead to the intended success. Take a simple stick and rotate it around one of its ends. For an observer the phenomenon is still the same even when he changes his viewpoint. If you want to rotate the stick around its middle you really have to change the centre of rotation which means, that one end of the stick goes up and the other end goes down. At least in the _outside_ views the PA-28 still rotates around its nose after the recent changes, That seemed funny to me as well, but when I looked from the outside view, it did seem to pivot around the wings after the change (in fact, as I moved the camera back and forth, so did the apparent pivot point). That was from a side view in flight -- what did you use where you saw it moving about the nose? I had assumed that the property was mislabelled, and actually moved the model original somehow. All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS:data/Aircraft/pa28-161
Vivian Meazza <[EMAIL PROTECTED]> said: > > > Martin wrote: > > > > David Megginson <[EMAIL PROTECTED]> wrote: > > > Update of /var/cvs/FlightGear-0.9/data/Aircraft/pa28-161 > > > In directory baron:/tmp/cvs-serv12589 > > > > > Modified Files: > > > pa28-161-yasim-set.xml > > > Log Message: > > > Change camera position so that model doesn't rotate around the nose. > > > > I can't withstand the impression that changing the _camera_ > > position didn't lead to the intended success. Take a simple > > stick and rotate it around one of its ends. For an observer > > the phenomenon is still the same even when he changes his > > viewpoint. If you want to rotate the stick around its middle > > you really have to change the centre of rotation which means, > > that one end of the stick goes up and the other end goes down. > > > > At least in the _outside_ views the PA-28 still rotates > > around its nose after the recent changes, > > > > We've been here before haven't we? In developing the Hunter model I first > put the model origin at the nose to conform to the YASIM origin, but the > model then rotated about the nose - most disconcerting in outside views! I > moved the model (not the YASIM) origin to the CofG - the model behaves > nicely in all views. It's not strictly correct on the ground, because the > model has differential braking, and should more or less rotate around the > braked wheel, but you would have to have a very sharp eye to spot the > deliberate :-) mistake. > If you put the model back to the nose and use the method that the p51d and the pa28-161 use (the target offset) you'll look better on the ground. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] LOD problems
Right, this example was supposed to make the stuff disappear at ranges greater than 2000, but it makes the stuff disappear alltogether. Here's the other LOD stuff right now, none of this stuff appears in any other animations except the ones that are selected out when retracted. All the animations here work except the one from 0 to 2000. I also just double checked that the object-names are spelled correctly. Thanks, Josh range 0 50 cabindetail range 50 2000 coarsenorden range 0 2000 lnavlt rnavlt topgunner leftgunner rightgunner astrodome range 2000 1 opaque-canopy opaque-lwindow opaque-rwindow opaque-tailwindow select ngearassy lgearassy rgearassy tailskid gear/gear[0]/position-norm 0 select bombassy systems/weapons/bomb-door-pos 0 Frederic Bouvier wrote: Josh Babcock wrote: This is the one I am having trouble with right now: range 0 2000 lnavlt rnavlt topgunner leftgunner rightgunner astrodome This stuff just doesn't appear when I put this in the modedl.xml file. The external view is set to 100m. -100.0 I can't figure out why this stuff isn't appearing at close range. There are other problems, but I'm trying to isolate stuff and deal with them one by one. There is also a point that must not be forgotten : when an object is specified in 2 different range animation, the result is an AND not a OR. I mean that is you have : 0 2000 something 2000 1 something you won't see 'something' from 0 to 1 because the first cull it for the range 2000-1 and the second cull it for the range 0-2000. I don't know if it is the case but your individual animation seems good. -Fred Frederic Bouvier wrote: Josh Babcock wrote: I'm having problems with the LOD animations in a model I'm working on. I am wondering if the value that is queried in the range type of animation is exposed anywhere. I have looked, but can't find it in the property tree. I am also unsure of where to find references to this in the code. Can anyone out there answer either of these questions? The value used to compute the range is the distance between the viewer and the center of the model ( its relative ( 0,0,0 ) position ). It is not exposed in the property tree because it is computed every frame by plib itself. But you can setup your animation to read the min and max values in properties. Look in the XML files of the buildings in the scenery folder. Almost everyone as such an animation. You can find the code in SimGear / simgear / scene / model / animation.[ch]xx If you can expose what are exacly your problems, perhaps we can help you more. -Fred ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: data/Aircraft/pa28-161
David Megginson <[EMAIL PROTECTED]> said: > Martin Spott wrote: > > > I can't withstand the impression that changing the _camera_ position > > didn't lead to the intended success. Take a simple stick and rotate it > > around one of its ends. For an observer the phenomenon is still the > > same even when he changes his viewpoint. > > If you want to rotate the stick around its middle you really have to > > change the centre of rotation which means, that one end of the stick > > goes up and the other end goes down. > > > > At least in the _outside_ views the PA-28 still rotates around its nose > > after the recent changes, > > That seemed funny to me as well, but when I looked from the outside view, it > did seem to pivot around the wings after the change (in fact, as I moved the > camera back and forth, so did the apparent pivot point). That was from a > side view in flight -- what did you use where you saw it moving about the nose? > > I had assumed that the property was mislabelled, and actually moved the > model original somehow. > In the real world the eye isn't really exactly under your control. At some level either mechanically or through interpretation the brain always tries make the world look "right". With 3D that the camera does _exactly_ what you tell it to. If you tell it to point to the nose of the aircraft, it will follow it doggedly. And since the camera is always focused on the exact same spot on the aircraft, it will always appear to be stationary in the view. Same spot on your screen. Another way to look at it is this: If the aircraft pitches, the nose moves up and down. If the camera is tracking the nose, then it moves up and down as well with the nose. This creates the _illusion_ that the rest of the aircraft (and of the scene for that matter) is moving, and the nose is remaining stationary when in fact it is moving up and down. So the aircraft is always rotating around the proper location. And that's the reason for that particular property name (maybe "Camera-Target-offset-z" would be more explanatory?). Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS:
"Jim Wilson" <[EMAIL PROTECTED]> wrote: > David Megginson <[EMAIL PROTECTED]> said: >> Martin Spott wrote: >> > At least in the _outside_ views the PA-28 still rotates around its nose >> > after the recent changes, >> >> That seemed funny to me as well, but when I looked from the outside view, it >> did seem to pivot around the wings after the change (in fact, as I moved the >> camera back and forth, so did the apparent pivot point). That was from a >> side view in flight -- what did you use where you saw it moving about the nose? Take whichever you want. The effect is most noticeable with the "Tower view" and the "Chase view wo yaw". ^ :-) > Another way to look at it is this: If the aircraft pitches, the nose moves up > and down. If the camera is tracking the nose, then it moves up and down as > well with the nose. This creates the _illusion_ that the rest of the > aircraft (and of the scene for that matter) is moving, and the nose is > remaining stationary when in fact it is moving up and down. You _might_ be right, but in the case we are talking abouth things are different. For example use the "Tower view" and zoom enough to get the details. Take off and stay 100 ft above the ground. Now push the elevator violently aband you'll notice that the nose keeps its distance from the ground but the aircraft body gains height. Compare this to the default aircraft. There's another sign that _might_ reveal something about the 'mistake'. Use the "Chase view wo yaw" and activate the HUD. On the default and several other aircraft (I didn't test the whole hangar) the center of the HUD points to somwhere near the CG, on the PA-28 it points to the aircraft nose. Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS:
Martin Spott wrote: > Jim Wilson wrote: > > If the camera is tracking the nose, then it moves up and down as > > well with the nose. This creates the _illusion_ that the rest of > > the aircraft (and of the scene for that matter) is moving, and the > > nose is remaining stationary when in fact it is moving up and down. > > You _might_ be right No, he is right. Really. This has been argued over before. I can *assure* you that both FDMs do the mechanics correctly. The whole idea of "rotates around the C.G." is an approximation anyway. The C.G. moves at runtime, and translational accelerations and rotation couple; they simply can't be modelled independently. Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] RAM disk / Unix
Martin Spott wrote: > On the other hand it might be easier to 'preload' the data into > memory and prevent this memory area to being swapped out (there > should be some operating system call), There certainly is. It's called "read()". :) Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] LOD problems
Josh Babcock wrote: > Right, this example was supposed to make the stuff disappear at ranges > greater than 2000, but it makes the stuff disappear alltogether. Here's > the other LOD stuff right now, none of this stuff appears in any other > animations except the ones that are selected out when retracted. All > the animations here work except the one from 0 to 2000. I also just > double checked that the object-names are spelled correctly. I think the problem can be with your model. I think of two more points to check : 1. if your objects are included in a branch that is culled, they will not appear. 2. if your objects are a single quad or triangle, plib doesn't name then and they cannot be selected. A single quad must be split in 2 triangles to have a named object. -Fred ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS:
Andy Ross <[EMAIL PROTECTED]> wrote: > Martin Spott wrote: >> Jim Wilson wrote: >> > If the camera is tracking the nose, then it moves up and down as >> > well with the nose. This creates the _illusion_ that the rest of >> > the aircraft (and of the scene for that matter) is moving, and the >> > nose is remaining stationary when in fact it is moving up and down. >> >> You _might_ be right > No, he is right. Really. This has been argued over before. I can > *assure* you that both FDMs do the mechanics correctly. I never told anyone that the FDM's would behave different! > The whole idea of "rotates around the C.G." is an approximation > anyway. The C.G. moves at runtime, and translational accelerations > and rotation couple; they simply can't be modelled independently. Arrrgh, did you read my posting ? Did you try the 'exercise' I am describing ? "For example use the "Tower view" and zoom enough to get the details. Take off and stay 100 ft above the ground. Now push the elevator violently aband you'll notice that the nose keeps its distance from the ground but the aircraft body gains height. Compare this to the default aircraft." No, you didn't, otherwise you would have noticed what I mean. Please differenciate: I'm not telling anyone _where_ to tune the system to get the phenomenon fixed, I'm simply telling that there is "room for improvement", because the aircraft definitely rotates around its nose when you look from outside. I _do_ have eyes that are suitable to verify this, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS:
Andy wrote > > > Martin Spott wrote: > > Jim Wilson wrote: > > > If the camera is tracking the nose, then it moves up and down as > > > well with the nose. This creates the _illusion_ that the rest of > > > the aircraft (and of the scene for that matter) is > moving, and the > > > nose is remaining stationary when in fact it is moving up > and down. > > > > You _might_ be right > > No, he is right. Really. This has been argued over before. I can > *assure* you that both FDMs do the mechanics correctly. > > The whole idea of "rotates around the C.G." is an > approximation anyway. The C.G. moves at runtime, and > translational accelerations and rotation couple; they simply > can't be modelled independently. > I was only using the CofG (and approximately at that) as a better visual reference than the nose. I was only concerned to make things look right. I'm sure that the FDMs are quite correct, or the models wouldn't fly very well, if at all. I take it the CofG moves as fuel is consumed. Or is there something else? With intellectual curiosity. Vivian Meazza ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] ATC voice howto
OK, here's some instructions on how to generate new ATC voices for FlightGear. Hopefully this will make some sense to somebody, ask if it's unclear. If you want to record the phrases in a local accent or even a different language go right ahead, I'll add code support for it. You'll need to supply a translation if its in a different language though! Have fun! Cheers - Dave --- Instructions for Generating FlightGear ATC and AI Voices, Feb/2004, DCL. First off, I'm most definately NOT any sort of audio expert - its just not one of my things. This is simply the scheme I devised to get the ATIS voices in. There's undoubtably a lot of scope for improvement, and if anyone has any ideas for improvement then shout and we'll see if we can accomodate them. Currently, FlightGear audio support is limited to 8kHz, 8bit mono, but at this setting voice recordings are noticably degraded, so I recommend keeping both the master recordings and the final edited version at a better quality (22kHz, 16bit, say) and export to 8,8 at the very end, in order that the better quality master is available in the future when hopefully FG audio support improves. Keep hold of the originals for the future - you'll need to add to them if the phraseology is extended. A final proviso is that FlightGear's ATC phraseology is not fully (or even close to!) mature yet - there will undoubtably be more phrases, or changes to phrases, required in the future. If you want your recordings to be used in the future you may need to record some additional phrases at some point. With all that in mind, it would still be great to have as many voices as possible now to get the ball rolling, so here goes. Two files are required for each voice - a wave file containing the actual sounds, and an index file that basically describes where in the wave file buffer to find each word or phrase. The current voices for the ATIS can be found in $FG_ROOT/data/ATC and are called default.wav and default.vce for the wave and index file respectively. Note that one important change will be made in default.vce - currently it is indexed by byte position into the sound buffer, but I've decided it would be better to index by time into the buffer, since that is more robust to changing the recording quality, and in the future possiby using encoding such as Ogg Vorbis. Also, the first line currently contains the number of subsequent lines, but I think that can be ditched! The basic idea is to record all the phraseology needed, which will also contain much that isn't needed, then cut and paste the required words or phrases into a new track, which is saved to something like tower1.wav. Then index the position of everything needed, and save it to something corresponding like tower1.vce. Then send it to me ([EMAIL PROTECTED]) so it can be put into FG. Phrases can be entered and indexed either as phrases, with the words joined by underscores, or as individual words. Is is quite permissible to index one part of the buffer more than once, eg. Cleared_for_takeoff t1 t4 Cleared t1 t2 for t2 t3 takeoff t3 t4 Cleared_for t1 t3 where t1 - t4 are times into the buffer. In general, I suspect that the longer the phrases run to, the more likely the dialogue is to sound natural, but the larger the wav file size will become. I guess this is something that will only become clear with experimentation and experience. A lot of the phraseology needed takes the form of lists - the phonetic alphabet, numbers, airport names etc. However, I find that they tend to come out more naturally if they are recorded as part of a proper phrase eg "Cessna six nine foxtrot cleared for takeoff runway one five winds two three zero at one five", and repeat a lot of different phrases until you have everything you want. The final recording for FlightGear will be much smaller since the words wanted should be crammed together as much as possible - listen to default.wav (the ATIS) to see what I mean. I'm sure that real-life pilots are likely to have some beef with the suggested phraseology - it's all open to change, and a lot of it isn't currently used. At the moment the voices most needed are the tower control and AI GA planes, particularly AI planes since on a given frequency there will be several of them per one controller so a variety of voices would sound better. The tower phraseology is posted below - I'll try and post the AI VFR phraseology as soon as possible. Note that the tower phraseology below is very VFR operation orientated - it will expand for IFR ops at some point in the future. Finally, as set up at the moment, you can't simply test your new voice in FlightGear. I'll hack at the code a bit and post some instructions on how to make it be heard. It would be nice to have a voice testing mode in FlightGear, to run with the sim paused and play a selection of phrases from files u
RE: [Flightgear-devel] Re: [Flightgear-cvslogs]CVS:data/Aircraft/pa28-161
Jim Wilson wrote > Vivian Meazza <[EMAIL PROTECTED]> said: > > > > > > > Martin wrote: > > > > > > David Megginson <[EMAIL PROTECTED]> wrote: > > > > Update of /var/cvs/FlightGear-0.9/data/Aircraft/pa28-161 > > > > In directory baron:/tmp/cvs-serv12589 > > > > > > > Modified Files: > > > > pa28-161-yasim-set.xml > > > > Log Message: > > > > Change camera position so that model doesn't rotate around the > > > > nose. > > > > > > I can't withstand the impression that changing the _camera_ > > > position didn't lead to the intended success. Take a simple > > > stick and rotate it around one of its ends. For an observer > > > the phenomenon is still the same even when he changes his > > > viewpoint. If you want to rotate the stick around its middle > > > you really have to change the centre of rotation which means, > > > that one end of the stick goes up and the other end goes down. > > > > > > At least in the _outside_ views the PA-28 still rotates > > > around its nose after the recent changes, > > > > > > > We've been here before haven't we? In developing the Hunter model I > > first put the model origin at the nose to conform to the > YASIM origin, > > but the model then rotated about the nose - most disconcerting in > > outside views! I moved the model (not the YASIM) origin to > the CofG - > > the model behaves nicely in all views. It's not strictly correct on > > the ground, because the model has differential braking, and should > > more or less rotate around the braked wheel, but you would have to > > have a very sharp eye to spot the deliberate :-) mistake. > > > > If you put the model back to the nose and use the method that > the p51d and the pa28-161 use (the target offset) you'll look > better on the ground. Tried that. Looks just the same to me. As I said some time ago: yer pays yer money and yer takes yer choice. Neither is right on the ground for differential braking: with one brake full on the aircraft more or less rotates around that wheel. The model doesn't! When the aircraft is moving the forward the CofG should rotate about some point outboard of the braked wheel. All to do with tyre slip angles, but I'm not sure if the FDM's know about those, and I would need to consult my race engineering handbooks. But, hey, we're building flight simulator, not a ground handling simulator. If it's good enough that'll do me. PS why in an external view does the Hunter appear to do an upward roll in the up leg of a loop. And a downward roll in the down leg? And why can't I loop the P51? PPS the B52 rolls very nicely. Of course the real wings might fall off. Not sure I'd like to go to war in an aircraft whose wings fall off. Curiously confused Vivian Meazza ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: [Flightgear-cvslogs]
"Jim Wilson" <[EMAIL PROTECTED]> wrote: > If you put the model back to the nose and use the method that the p51d and the > pa28-161 use (the target offset) you'll look better on the ground. BTW, it appears to me that the P-51 suffers from the same visual mishap as the PA-28 does (does this have to do with the "P" ? ;-)) Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Re: [Flightgear-cvslogs]
Martin Spott asked > Subject: Re: [Flightgear-devel] Re: [Flightgear-cvslogs] > > > "Jim Wilson" <[EMAIL PROTECTED]> wrote: > > > If you put the model back to the nose and use the method > that the p51d > > and the pa28-161 use (the target offset) you'll look better on the > > ground. > > BTW, it appears to me that the P-51 suffers from the same > visual mishap as the PA-28 does (does this have to do with > the "P" ? ;-)) > Is that a silent "P" as in swimming pool? (Native English speakers only :-)) Vivian Meazza ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Re: [Flightgear-cvslogs]CVS:data/Aircraft/pa28-161
Vivian Meazza <[EMAIL PROTECTED]> said: > Tried that. Looks just the same to me. As I said some time ago: yer pays yer > money and yer takes yer choice. Neither is right on the ground for > differential braking: with one brake full on the aircraft more or less > rotates around that wheel. The model doesn't! When the aircraft is moving > the forward the CofG should rotate about some point outboard of the braked > wheel. All to do with tyre slip angles, but I'm not sure if the FDM's know > about those, and I would need to consult my race engineering handbooks. > > But, hey, we're building flight simulator, not a ground handling simulator. > If it's good enough that'll do me. The ground handling is all part of it. I'm not sure what you are seeing...but if you moved the origin then the aircraft should have at least moved the same amount. It might "look" the same but look closer. Are the wheels in the same spot on startup? Basically with you need to make sure the gear is in the right spot, etc, etc. With YASim fdm configs you can configure gear animation so that when it compresses in yasim the gear compresses visually too. YASim will drop the altitude by an amount relevant to the modeled gear compression so the aircraft will drop, but the wheels will go "through the pavement" if you don't amimate the compression in the 3D model. > PS why in an external view does the Hunter appear to do an upward roll in > the up leg of a loop. And a downward roll in the down leg? And why can't I > loop the P51? I'm not sure what you mean. but there is no problem looping the p51d. I've done it many times. You might need to hit ctrl+b to get the manifold pressure up to second stage level. Am I understanding your question? > PPS the B52 rolls very nicely. Of course the real wings might fall off. Not > sure I'd like to go to war in an aircraft whose wings fall off. I'm not sure I'd like to go to war in an aircraft whose wings did not fall off either. No...wait...I'm sure. I wouldn't. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] LOD problems
Frederic BOUVIER wrote: Josh Babcock wrote: I think the problem can be with your model. I think of two more points to check : 1. if your objects are included in a branch that is culled, they will not appear. None of the 6 objects in the problem animation are members of any group. 2. if your objects are a single quad or triangle, plib doesn't name then and they cannot be selected. A single quad must be split in 2 triangles to have a named object. I already ran into this problem with some other animations, it does not affect these objects. These are all at least 4 poly's. -Fred And here's a really weird thing. If I take any one of the six objects and put it in this animation it works fine. I tried all six individually. Next I tried just two, and it got even worse: range 0 2000 leftgunner ^ This one works fine. Everything is visible close up, but the left gunner bubble isn't visible from over 2 klicks away. range 0 2000 rightgunner leftgunner ^ This one doesn't. The right gunner bubble appears and disappears just fine but now the left bubble is broken. Do it like this: range 0 2000 astrodome rightgunner leftgunner and only the astrodome works right, the two gunner positions disappear entirely. So it looks like in this particular animation, the first object is treated correctly, whatever it is, and the remaining objects are just thrown away somehow. I think I missed this at first because in the original animation I had a very small object first. These all have translucent materiels assigned to them in the .ac file, BTW. Now that I know what to look for, I can also see this very same problem in this animation: range 2000 1 opaque-tailwindow opaque-lwindow opaque-rwindow opaque-canopy So my question now is, is this a misfeature where I have to group everything I want to animate under a single object or create multiple animations, or is it a bug? Josh PS, if any more C savvy people out there want to look closer at this and can't duplicate it, I can send the whole set of .xml files and the .ac file to you. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS:
Martin Spott <[EMAIL PROTECTED]> said: > You _might_ be right, but in the case we are talking abouth things are > different. For example use the "Tower view" and zoom enough to get the > details. Take off and stay 100 ft above the ground. Now push the > elevator violently aband you'll notice that the nose keeps its distance > from the ground but the aircraft body gains height. Compare this to the > default aircraft. Trust me, I've been all over every line of the viewer code. You aren't really seeing what you think you are. It just looks that way. The only connection between the FDM and what you see on the screen are the properties in the /orientation and /position paths. If you suspect a problem, look at those. In the case you describe the altitude-ft reading (which is at the nose if the nose is the FDM origin) will not change when you pull hard on the stick. > There's another sign that _might_ reveal something about the 'mistake'. > Use the "Chase view wo yaw" and activate the HUD. On the default and > several other aircraft (I didn't test the whole hangar) the center of > the HUD points to somwhere near the CG, on the PA-28 it points to the > aircraft nose. > That's a problem with the HUD code which _is_ broken (IMHO tm). Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS:
Vivian Meazza <[EMAIL PROTECTED]> said: > I was only using the CofG (and approximately at that) as a better visual > reference than the nose. I was only concerned to make things look right. I'm > sure that the FDMs are quite correct, or the models wouldn't fly very well, > if at all. I take it the CofG moves as fuel is consumed. Or is there > something else? > > With intellectual curiosity. You actually want to be very exact about matching the model to the FDM origin. Otherwise you won't be able to model position on the ground very well. One problem might be the wheels sit a few inches above the pavement, or maybe the tail drops through the ground when you rotate on takeoff. That's why with most aircraft, the nose is good (easy to identify). Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Aerodynamic centre and 3D models
OK, everyone, here's the problem. I tested watching the PA28-161 from a fixed point on the ground, and it does, in fact pivot around its nose still. The problem is that the model code gets the roll/pitch/yaw from the FDM and then applies it to the 0,0,0 point in the 3D model, which happens to be the tip of the spinner for the Warrior (as it is in the weight-and-balance section of the POH). YASim isn't doing anything wrong; the model code just doesn't know where the aerodynamic centre of the model is, so it doesn't know what point to rotate the plane around. With Jim's suggested patch, the camera rotates with the plane in the chase views, so it *looks* like the plane is rotating in the right place, but it is not. So, given that the aerodynamic centre of an aircraft can shift based on loading and flight conditions, how can we report that from the FDM back to the 3D model code? Is this something people worked out in a previous thread? I'm assuming that the 3D model and the FDM config file are using the same reference datum for coordinates. All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS:
On Thu, 12 Feb 2004 19:50:48 - "Jim Wilson" <[EMAIL PROTECTED]> wrote: You actually want to be very exact about matching the model to the FDM origin. ... Jim (or someone ... *anyone*): Could you summarize the argument taking place here? I seem to only be getting parts of it - I guess I didn't get the original question/comment. Is there now a difference in the way that JSBSim and YASim match up the 3D model with the FDM? Have you had a chance to try out the new way that JSBSim provides position? Is there anything else we (JSBSim and/or FDM developers) need to do? I would like to get an alpha B747 FDM I have been working on to work using the 3D model, but haven't really had time to work on this much. When I did try it out initially, it looked like the origin was wrong between the 3D model and the FDM. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Aerodynamic centre and 3D models
On Thu, 12 Feb 2004 15:09:15 -0500 David Megginson <[EMAIL PROTECTED]> wrote: So, given that the aerodynamic centre of an aircraft can shift based on loading and flight conditions, how can we report that from the FDM back to the 3D model code? Is this something people worked out in a previous thread? I'm assuming that the 3D model and the FDM config file are using the same reference datum for coordinates. First, the aircraft - like any body - rotates about its CG (according to the EOM) - not usually the same as the AC. JSBSim made a change recently that is likely not yet in FlightGear CVS. The lat/lon/alt position now reported by JSBSim (CVS) is the position of the VRP (Visual Reference Point) - i.e. the tip of the prop hub (or similar nose tip location on non-prop aircraft). As long as the aircraft is placed in the scene so that the nose of the 3D model falls at the location reported by JSBSim - everything works out. This assumes that the aircraft model is defined using the correct English units - because all points that the FDM is concerned with are measured in the structural frame and in inches. Yes, we have gone over this ad nauseum in the past. :-) Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS:
"Jim Wilson" <[EMAIL PROTECTED]> wrote: > Trust me, I've been all over every line of the viewer code. You aren't really > seeing what you think you are. It just looks that way. Jim, do you want to tell me I'm blind ? I must admit that I probably never looked at the code but I can assure you that I'm clever enough to determine wether an aircraft rotates around its nose or around some sort of center (whichever you'd like to pick). How can you tell people to take care of the movement of the CG when you ignore _that_ obvious visual 'artefacts'. _Please_ do that experiment I already described _before_ calling me stupid. Another example: How would you explain that the main gear of the PA-28 sinks into the ground when the aircraft rotates on liftoff while the nose stays at the same distance over ground. Do you still want to tell me that this is only a visual illusion !? I've seen _enough_ aircraft rotating on takeoff to know that reality looks _much_ different (I am _not_ talking about marginal movement of the CG), Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: saving fgfs replay session
Jorge Van Hemelryck <[EMAIL PROTECTED]> writes: > Try xvidcap... I haven't managed to really make a movie file with it > yet, but that's what it's supposed to do. thanks. xvidcap worked great. i put the movie up at: http://caliban.lbl.gov/fgfs-carrier.mpeg the file is 33548 kB, and the movie is 800x600 in mpeg4 format. unfortunately the frame rate dropped to about 11fps (because of the recording). --alex-- -- | I believe the moment is at hand when, by a paranoiac and active | | advance of the mind, it will be possible (simultaneously with | | automatism and other passive states) to systematize confusion | | and thus to help to discredit completely the world of reality. | ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS:
"Jon S Berndt" <[EMAIL PROTECTED]> wrote: > Is there now a difference in the way that JSBSim and YASim match up > the 3D model with the FDM? No, the discussion is only about placement of the 3D model vs. some FDM reference point, I think (but I'm not absolutely shure if there _might_ be a hidden mistake elsewhere), Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Aerodynamic centre and 3D models
Jon S Berndt wrote: JSBSim made a change recently that is likely not yet in FlightGear CVS. The lat/lon/alt position now reported by JSBSim (CVS) is the position of the VRP (Visual Reference Point) - i.e. the tip of the prop hub (or similar nose tip location on non-prop aircraft). As long as the aircraft is placed in the scene so that the nose of the 3D model falls at the location reported by JSBSim - everything works out. I'm not sure I see how this helps -- the model code still doesn't know where the CG is, so it still doesn't know where the centre of rotation for the model should be. All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS:
This has all got me thinking a bit. This subject seems to come up quite a bit, and frankly I have found it a dificult problem too. In addition, there are some related things that can get hard as well like placing the wheels right on the ground, and getting the landing gear elements for wingtips and other parts that can experience a ground strike positioned correctly. Maybe what we need is the ability to place a visual cursor into the scene graph and slave it's position to a set of positional properties. These could come from the FDM or a view definition (think how useful it would be to go into helicopter mode and see exactly where you put the poilot's head, or some other viewpoint). The big win IMHO is the ability to see where the plane's cg is independant of the model. I know that there aren't coordinates for all these things just laying around in the property tree, but if the ability to see them is implemented, maybe the FDMs will start exporting these coordinates. The big one is the cg position, which is already there. Josh Jon S Berndt wrote: On Thu, 12 Feb 2004 19:50:48 - "Jim Wilson" <[EMAIL PROTECTED]> wrote: You actually want to be very exact about matching the model to the FDM origin. ... Jim (or someone ... *anyone*): Could you summarize the argument taking place here? I seem to only be getting parts of it - I guess I didn't get the original question/comment. Is there now a difference in the way that JSBSim and YASim match up the 3D model with the FDM? Have you had a chance to try out the new way that JSBSim provides position? Is there anything else we (JSBSim and/or FDM developers) need to do? I would like to get an alpha B747 FDM I have been working on to work using the 3D model, but haven't really had time to work on this much. When I did try it out initially, it looked like the origin was wrong between the 3D model and the FDM. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS:
On Thu, 12 Feb 2004 15:36:13 -0500 Josh Babcock <[EMAIL PROTECTED]> wrote: This has all got me thinking a bit. This subject seems to come up quite a bit, and frankly I have found it a dificult problem too. In addition, there are some related things that can get hard as well like placing the wheels right on the ground, and getting the landing gear elements for wingtips and other parts that can experience a ground strike positioned correctly. Maybe what we need is the ability to place a visual cursor into the scene graph and slave it's position to a set of positional properties. These could come from the FDM or a view definition (think how useful it would be to go into This is not a bad suggestion. However, I'd be happy if we could specify a set of axes to be displayed as desired. I'd like to see the XYZ axes reported by the FDM, for instance - both nose-cented and CG centered. It could be a valuable visual debugging aid. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Aerodynamic centre and 3D models
On Thu, 12 Feb 2004 15:35:59 -0500 David Megginson <[EMAIL PROTECTED]> wrote: Jon S Berndt wrote: I'm not sure I see how this helps -- the model code still doesn't know where the CG is, so it still doesn't know where the centre of rotation for the model should be. This is precisely *why* the nose is used as a reference point. If the scene graph (is that the right term/subsystem?) places the aircraft at the spot reported by JSBSim -- that is, where JSBSim says the nose of the aircraft is -- the perceived CG of the 3D aircraft as viewed in the scene will fall exactly in the spot that the FDM says it should be at. Look at it this way: the FDM tracks the motion of the CG, and the rotation of the aircraft about the CG. The FDM knows teh location of the CG at any point in time, as well as the euler angles of the aircraft at that point in time. If we were to report the location of this CG to FlightGear, and IF the origin of the 3D model was allowed to shift (by some magic) and always be coincident with the "virtual CG" in the 3D model, then we'd all always be happy and everything would match up fine. The problem is, the CG shifts and the 3D model coordinate system can't. Since the FDM knows (or can calculate) where the nose is at all times, we simply report the nose location to FlightGear, and by convention FlightGear places the 3D model's nose at the point reported by JSBSim - the CG falls into place as needed IFF the 3D model is defined (or scaled/rotated/translated in the scene graph) correctly as described previously. Takeoffs and landings would look fine, etc. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Aerodynamic centre and 3D models
Hello all, Just a few comments from a sideline observer following the discussion for many months. Jon seems to be providing a point representing a vector from the current (dynamic) CG to an agreed point in space where the plane nose is expected. If this vector is updated regularly both in magnitude ( fuel burn change of CG, etc) and direction (pitch and yaw in a real-world reference), the model nose is drawn at the VRP each frame, and the model orientation tracks the matching pitch and yaw, the center of the model should stay matched to the CG the FDM uses. Now how do you determine which step in the above assumptions is failing? -- Bill Earnest [EMAIL PROTECTED] Linux Powered Allentown, PA, USA Computers, like air conditioners, work poorly with Windows open. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Aerodynamic centre and 3D models
David Megginson <[EMAIL PROTECTED]> said: > OK, everyone, here's the problem. I tested watching the PA28-161 from a > fixed point on the ground, and it does, in fact pivot around its nose still. Maybe not. Your cvs log shows that you did not make the target offset correction for the tower views only the view n=1 chase view. See the p51d config. > The problem is that the model code gets the roll/pitch/yaw from the FDM and > then applies it to the 0,0,0 point in the 3D model, which happens to be the > tip of the spinner for the Warrior (as it is in the weight-and-balance > section of the POH). YASim isn't doing anything wrong; the model code just > doesn't know where the aerodynamic centre of the model is, so it doesn't > know what point to rotate the plane around. > > With Jim's suggested patch, the camera rotates with the plane in the chase > views, so it *looks* like the plane is rotating in the right place, but it > is not. Well the patch is necessary always. Unless the origins are defined at the aerodynamic center (an ambiguous location). > So, given that the aerodynamic centre of an aircraft can shift based on > loading and flight conditions, how can we report that from the FDM back to > the 3D model code? Is this something people worked out in a previous > thread? I'm assuming that the 3D model and the FDM config file are using > the same reference datum for coordinates. Ah ok. Sorry folks. This is _a_ problem: To make this work both the FDM origin (where lon/lat/alt are reported at) and the 0,0,0 origin of the 3D model should be the nose. If you do that, then all will be fine. In this case you've got the origin a half meter back in the FDM and the 3D model is 0,0,0 at tip of nose cone. Visually the error is probably "barely" noticable. Please keep this simple. It is exactly as it needs to be. FWIW I fought Andy on this issue (didn't believe him either) a while back. Then all of a sudden a light came on and I got it. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Re:[Flightgear-cvslogs]CVS:data/Aircraft/pa28-161
Jim Wilson added > Vivian Meazza <[EMAIL PROTECTED]> said: > > > Tried that. Looks just the same to me. As I said some time ago: yer > > pays yer money and yer takes yer choice. Neither is right on the > > ground for differential braking: with one brake full on the > aircraft > > more or less rotates around that wheel. The model doesn't! When the > > aircraft is moving the forward the CofG should rotate about > some point > > outboard of the braked wheel. All to do with tyre slip > angles, but I'm > > not sure if the FDM's know about those, and I would need to > consult my > > race engineering handbooks. > > > > But, hey, we're building flight simulator, not a ground handling > > simulator. If it's good enough that'll do me. > > The ground handling is all part of it. I'm not sure what you > are seeing...but if you moved the origin then the aircraft > should have at least moved the same amount. It might "look" > the same but look closer. Are the wheels in the same > spot on startup? Basically with you need to make sure the > gear is in the > right spot, etc, etc. I moved the origin, then applied an equal and opposite offset. When one differential brake is applied and the model is viewed in or helicopter view tower view it appears to be turning around its axis rather than around the braked wheel. That said, in chase view and in chase view wo (without) yaw it looks good. This is seems to be the case if the model origin is either the nose (and with offset) or with the CofG as the origin. Am I seeing some artefact of the view perhaps? Seem just fine in cockpit view however. > With YASim fdm configs you can > configure gear animation so that when it compresses in yasim > the gear compresses visually too. YASim will drop the > altitude by an amount relevant to the modeled gear > compression so the aircraft will drop, but the wheels will go > "through the pavement" if you don't amimate the compression > in the 3D model. Been there done that, no probs. > > > PS why in an external view does the Hunter appear to do an > upward roll > > in the up leg of a loop. And a downward roll in the down > leg? And why > > can't I loop the P51? > > I'm not sure what you mean. but there is no problem looping > the p51d. I've done it many times. You might need to hit > ctrl+b to get the manifold pressure up to second stage level. > Am I understanding your question? I enter the loop in a shallow dive, 2nd stage boost on, 350 kts, pull baaack the stick and the model rolls violently and does not enter the loop ... Works fine in other models so it's not the obvious - the joystick. But I expect I'm doing something wrong. > > > PPS the B52 rolls very nicely. Of course the real wings might fall > > off. Not sure I'd like to go to war in an aircraft whose wings fall > > off. > > I'm not sure I'd like to go to war in an aircraft whose wings > did not fall off either. No...wait...I'm sure. I wouldn't. > Hah! No sense of adventure. Spinning around Vivian Meazza ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Re:[Flightgear-cvslogs]CVS:data/Aircraft/pa28-161
Vivian Meazza <[EMAIL PROTECTED]> said: > I moved the origin, then applied an equal and opposite offset. When one > differential brake is applied and the model is viewed in or helicopter view > tower view it appears to be turning around its axis rather than around the > braked wheel. That said, in chase view and in chase view wo (without) yaw it > looks good. This is seems to be the case if the model origin is either the > nose (and with offset) or with the CofG as the origin. Am I seeing some > artefact of the view perhaps? Seem just fine in cockpit view however. Hmmm...I'm not sure about that. It sounds like it is a view problem. Can you post your latest files so I can take a look after I get home from work? Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Aerodynamic centre and 3D models
> Jon S Berndt tells us > On Thu, 12 Feb 2004 15:09:15 -0500 > David Megginson <[EMAIL PROTECTED]> wrote: > > >So, given that the aerodynamic centre of an aircraft can shift based > >on loading and flight conditions, how can we report that > from the FDM > >back to the 3D model code? Is this something people worked out in a > >previous thread? I'm assuming that the 3D model and the FDM config > >file are using the same reference datum for coordinates. > > First, the aircraft - like any body - rotates about its CG (according > to the EOM) - not usually the same as the AC. So put the (visual) model origin at or near the CofG - what's the problem? Seems to work OK in practice. Really confused now Vivian Meazza ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Aerodynamic centre and 3D models
David Megginson <[EMAIL PROTECTED]> said: > Jon S Berndt wrote: > > > JSBSim made a change recently that is likely not yet in FlightGear CVS. > > The lat/lon/alt position now reported by JSBSim (CVS) is the position of > > the VRP (Visual Reference Point) - i.e. the tip of the prop hub (or > > similar nose tip location on non-prop aircraft). As long as the > > aircraft is placed in the scene so that the nose of the 3D model falls > > at the location reported by JSBSim - everything works out. > > I'm not sure I see how this helps -- the model code still doesn't know where > the CG is, so it still doesn't know where the centre of rotation for the > model should be. The distance between any two vertices of a 3D model stays the same when you pitch the aircraft. For example: if you subtract the forward most vertext at the root of the left wing, from the vertext at the tip of the nose cone, you will always get the same X,Y,Z dimmension. No matter what the attitude of the aircraft is. That is why the model code does not need to know where the CG is. The 3D model designer does need to know the FDM "origin" or "reference point" or whatever you want to call the vertex in space at which the FDM reports the lon/lat/alt of the aircraft. So if she puts the origin of the model (0,0,0) in that place, the 3D model will rotate correctly. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] ATC voice howto
On Thursday 12 Feb 2004 5:31 pm, David Luff wrote: > OK, here's some instructions on how to generate new ATC voices for > FlightGear. Hopefully this will make some sense to somebody, ask if it's > unclear. > Two files are required for each voice - a wave file containing the actual > sounds, and an index file that basically describes where in the wave file > buffer to find each word or phrase. The current voices for the ATIS can be > found in $FG_ROOT/data/ATC and are called default.wav and default.vce for > the wave and index file respectively. Note that one important change will > be made in default.vce - currently it is indexed by byte position into the > sound buffer, but I've decided it would be better to index by time into the > buffer, since that is more robust to changing the recording quality, and in > the future possiby using encoding such as Ogg Vorbis. Also, the first line > currently contains the number of subsequent lines, but I think that can be > ditched! David In what units shall the time index be specified? The sampling rate sets a resolution limit on the timing, so for 8kHz we only need 1/8000 sec = 125 microseconds precision, but if we have an ambition for higher rates, we need more. [1] In reality, radio comms are not HiFi standard. Does anyone know what the typical bandwidth is? Or should we simulate by taking a beautiful 22kHz recording and filtering it to sound like the real thing? Perhaps as an option, so one can do radio practice with bell-like clarity at first, and graduate to crackly reception of foreign languages and accents later! Regards Jonathan [1] It occurs to me that for chunked formats like WAV, there is a mathematical relationship between the byte position and the time offset which could be used for conversion, no? ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re:[Flightgear-cvslogs]CVS:data/Aircraft/pa28-161
Vivian Meazza wrote: I enter the loop in a shallow dive, 2nd stage boost on, 350 kts, pull baaack the stick and the model rolls violently and does not enter the loop ... Works fine in other models so it's not the obvious - the joystick. But I expect I'm doing something wrong. Yup. Specifically, you are doing a snap roll. If you can keep the the AOA down, the plane won't stall and go into a snap roll. You could also try adding some flaps, but I'm not sure if that would bleed off too much energy. Best to just make the loop bigger. Remember, pull back a little, and the plane goes up. Pull back a lot, and the plane goes down ... fast. Josh ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Aerodynamic centre and 3D models
On Thu, 12 Feb 2004 21:19:25 - "Vivian Meazza" <[EMAIL PROTECTED]> wrote: Jon S Berndt tells us First, the aircraft - like any body - rotates about its CG (according to the EOM) - not usually the same as the AC. So put the (visual) model origin at or near the CofG - what's the problem? Seems to work OK in practice. Really confused now That is certainly one solution. Then define the VRP in the JSBSim config file (for JSBSim aircraft - I don't know how YASim does this), as coincident with the CG. Then, build your 3D model with the origina at the CG. HOWEVER: when the CG moves due to leanding gear deployment, or dropping loads, or fuel burnoff, the vehicle will rotate about the wrong point, eventually. It won't be real noticeable, but it will be there. That's why we provide the capability for both the 3D model designer and the FDM designer to agree on a common visual reference point, and things can be made much more accurate and allow for dynamic effects. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel]Re:[Flightgear-cvslogs]CVS:data/Aircraft/pa28-161
Jim Wilson asked > Vivian Meazza <[EMAIL PROTECTED]> said: > > > I moved the origin, then applied an equal and opposite offset. When > > one differential brake is applied and the model is viewed in or > > helicopter view tower view it appears to be turning around its axis > > rather than around the braked wheel. That said, in chase > view and in > > chase view wo (without) yaw it looks good. This is seems to be the > > case if the model origin is either the nose (and with > offset) or with > > the CofG as the origin. Am I seeing some artefact of the > view perhaps? > > Seem just fine in cockpit view however. > > Hmmm...I'm not sure about that. It sounds like it is a view > problem. Can you post your latest files so I can take a look > after I get home from work? > Delighted to that Jim, but how does that help, and how do I do it. Sorry to be dull. I'd really like to be able to show you a video ... Vivian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Aerodynamic centre and 3D models
Vivian Meazza wrote: So put the (visual) model origin at or near the CofG - what's the problem? Seems to work OK in practice. It depends on the aircraft. A light trainer like the Piper Cherokee or the Cessna 172 typically allows only about a foot of variation in the location of the CG along the longitudinal axis (though, unfortunately, pilots often exceed that). That's enough to show up visually, but only just barely -- the main place it would be noticable would be landing with the nosewheel low. A big airliner, on the other hand, can have a CG variation much larger, and that might be very noticeable. If we're going to solve this problem for the 747, we might as well solve it for the 172 the same way. All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Aerodynamic centre and 3D models
Jim Wilson wrote: That is why the model code does not need to know where the CG is. The 3D model designer does need to know the FDM "origin" or "reference point" or whatever you want to call the vertex in space at which the FDM reports the lon/lat/alt of the aircraft. So if she puts the origin of the model (0,0,0) in that place, the 3D model will rotate correctly. Thanks -- your explanation and Jon's has made it all clear, and the discussion has been useful. So, as far as I understand, JSBSim supports this in JSBSim CVS but not yet in FlightGear. Does YASim support setting the reference point yet? All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Aerodynamic centre and 3D models
David Megginson <[EMAIL PROTECTED]> said: > Jim Wilson wrote: > > > That is why the model code does not need to know where the CG is. The 3D > > model designer does need to know the FDM "origin" or "reference point" or > > whatever you want to call the vertex in space at which the FDM reports the > > lon/lat/alt of the aircraft. So if she puts the origin of the model (0,0,0) > > in that place, the 3D model will rotate correctly. > > Thanks -- your explanation and Jon's has made it all clear, and the > discussion has been useful. So, as far as I understand, JSBSim supports > this in JSBSim CVS but not yet in FlightGear. Does YASim support setting > the reference point yet? Yes. In YASim, the 0,0,0 of the fuselage property is the origin. So if ax=0, ay=0, az=0 is used then the nose is origin in YASim. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Aerodynamic centre and 3D models
On Donnerstag, 12. Februar 2004 22:37, David Megginson wrote: > Thanks -- your explanation and Jon's has made it all clear, and the > discussion has been useful. So, as far as I understand, JSBSim supports > this in JSBSim CVS but not yet in FlightGear. Does YASim support setting > the reference point yet? Even JSBSim CVS does not support this visual reference point yet. There is a patch pending in Jon's mailbox to report the visual reference point to flightgear and define a reference point in each JSBSim aircraft config. Also there is a bugfix which is required to make the VRP patch work correct. This one is in JSBSim cvs but I believe did not yet find the way into fightgear. Greetings Mathias -- Mathias Fröhlich, email: [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Aerodynamic centre and 3D models
On Thu, 12 Feb 2004 22:56:46 +0100 Mathias Fröhlich <[EMAIL PROTECTED]> wrote: Even JSBSim CVS does not support this visual reference point yet. There is a patch pending in Jon's mailbox to report the visual reference point to flightgear and define a reference point in each JSBSim aircraft config. ?? I thought I had already committed these. You might want to double check. In any case, I already committed to CVS the code that reports the VRP, as well as to make the corrections to the transforms (as you pointed out). These are committed. However, in JSBSim.cxx, the relevant code *may* still be commented out, waiting for the VRP specification in the aircraft models. It's a matter of timing, I think; we need to get everything together, then submit it. But, I think this will require work for the 3D model, too. ? Jon Also there is a bugfix which is required to make the VRP patch work correct. This one is in JSBSim cvs but I believe did not yet find the way into fightgear. Greetings Mathias -- Mathias Fröhlich, email: [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Aerodynamic centre and 3D models
On Donnerstag, 12. Februar 2004 23:11, Jon S Berndt wrote: > ?? I thought I had already committed these. You might want to double > check. In any case, I already committed to CVS the code that reports > the VRP, as well as to make the corrections to the transforms (as you > pointed out). These are committed. However, in JSBSim.cxx, the > relevant code *may* still be commented out, Yes, this is definitly missing. > waiting for the VRP > specification in the aircraft models. It's a matter of timing, I > think; we need to get everything together, then submit it. But, I > think this will require work for the 3D model, too. ? This stuff was also included in the patch. I put the visual reference point at dynamic center of gravity at initialization time. This choice fits well for the models we have in jsbsim cvs. Are there additional models in flightgear? Greetings Mathias -- Mathias Fröhlich, email: [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Aerodynamic centre and 3D models
Jim Wilson wrote: Yes. In YASim, the 0,0,0 of the fuselage property is the origin. So if ax=0, ay=0, az=0 is used then the nose is origin in YASim. It would be nice to be able to specify the point in YASim as well, so we don't have to physically alter the models. For the PA-28-161, though, I'll just have to move the model down a little bit. All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] ATC voice howto
Jonathan Richards writes: > In what units shall the time index be specified? The sampling rate sets a > resolution limit on the timing, so for 8kHz we only need 1/8000 sec = 125 > microseconds precision, but if we have an ambition for higher rates, we need > more. [1] > In reality, radio comms are not HiFi standard. Does anyone know what the > typical bandwidth is? Or should we simulate by taking a beautiful 22kHz > recording and filtering it to sound like the real thing? Perhaps as an > option, so one can do radio practice with bell-like clarity at first, and > graduate to crackly reception of foreign languages and accents later! > > Regards > Jonathan > > [1] It occurs to me that for chunked formats like WAV, there is a mathematical > relationship between the byte position and the time offset which could be > used for conversion, no? > Fantastic, a post not talking about rotating planes on their noses ;-)) Time index should be specified in seconds I think. Yes there'll be a lot of decimal points, but it's SI, and it's typically what wavefile editors natively display. In practice it probably doesn't matter if the time resolution spans a few bytes, especially at higher rates, since there's generally a slight gap between words, and if there isn't it's a good candidate for a run-together phrase. I guess comms aren't always that clear in real life, but at least if recordings are made at good quality to start with its optional whether to degrade them or not. At present the 8,8 limitation forces some degradation, and I'm not sure if the sort of 'muffled' quality that it imparts is what we're after. Yes, there is a relationship between byte position and time for wave files, which is how I'm going to convert the current default.vce. I think time is the best way forward though ever since someone mentioned Ogg Vorbis at one point. Plus I think Audacity only displays time, not byte position. As I say, I'm not an audio guy, so I'm open to being persuaded that another way is better... Another thing, some folk running Linux (David Megginson and at least one other) have reported only being able to hear the ATIS extremely faintly in the past. I'm not sure why, but it might be best *not* to copy the volume characteristics of default.wav, but to do what you think is best and see how it goes. Anyone got any wavefile editor recommendations BTW? I used CoolEdit (Windows) for the ATIS, but the trial period is now long gone, and when I went to buy it I found the guy had sold it to Adobe and the price had tripled. No thanks! I'm using Audacity now, but it's not entirely polished, and the sound is not in sync with cursor movement when playing a small selection in recent versions. Crucial factors are the ability to extend or contract a selection by either edge, and easy copy and pasting into a new buffer, plus display of time or byte position. There's loads for Linux, but I haven't found a really likeable one yet, Audacity being the nearest so far. Cheers - Dave ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Re:[Flightgear-cvslogs]CVS:data/Aircraft/pa28-161
> Josh Babcock > Vivian Meazza wrote: > > > > >I enter the loop in a shallow dive, 2nd stage boost on, 350 > kts, pull > >baaack the stick and the model rolls violently and does not > enter the > >loop ... Works fine in other models so it's not the obvious - the > >joystick. But I expect I'm doing something wrong. > > > > > > > Yup. Specifically, you are doing a snap roll. If you can > keep the the > AOA down, the plane won't stall and go into a snap roll. You > could also > try adding some flaps, but I'm not sure if that would bleed > off too much > energy. Best to just make the loop bigger. Remember, pull back a > little, and the plane goes up. Pull back a lot, and the > plane goes down > ... fast. Thanks for the advice. It's not easy without Pilot's Notes specifying some entry conditions. I was guessing 350 kts I was probably pulling back too hard, difficult to remember. Too slow, and the model falls off the top, of course. Back to the Hunter - it's much easier - but I designed it that way, and it flew that way too :-). ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] simgear CVS
There still seem to be problems with simgear/environment on the CVS server. I'm not getting any of the files in that dir when I do a cvs up. I had to dl them off the web server. Everything else seems to be updating well though. Josh ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] ATC voice howto
On Thu, 12 Feb 2004 21:05:25 +, David Luff <[EMAIL PROTECTED]> wrote: Anyone got any wavefile editor recommendations BTW? I like GoldWave. www.goldwave.com I used CoolEdit (Windows) for the ATIS, but the trial period is now long gone, and when I went to buy it I found the guy had sold it to Adobe and the price had tripled. No thanks! I'm using Audacity now, but it's not entirely polished, and the sound is not in sync with cursor movement when playing a small selection in recent versions. Crucial factors are the ability to extend or contract a selection by either edge, and easy copy and pasting into a new buffer, plus display of time or byte position. You can chose to display time or sample position, but the time display has only 3 decimal numbers. -- Roy Vegard Ovesen ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Aerodynamic centre and 3D models
On Thu, 2004-02-12 at 12:53, Jon S Berndt wrote: > On Thu, 12 Feb 2004 15:35:59 -0500 > David Megginson <[EMAIL PROTECTED]> wrote: > >Jon S Berndt wrote: > > >I'm not sure I see how this helps -- the model code still doesn't > >know where the CG is, so it still doesn't know where the centre of > >rotation for the model should be. > > This is precisely *why* the nose is used as a reference point. If the > scene graph (is that the right term/subsystem?) places the aircraft at > the spot reported by JSBSim -- that is, where JSBSim says the nose of > the aircraft is -- the perceived CG of the 3D aircraft as viewed in > the scene will fall exactly in the spot that the FDM says it should be > at. > > Look at it this way: the FDM tracks the motion of the CG, and the > rotation of the aircraft about the CG. The FDM knows teh location of > the CG at any point in time, as well as the euler angles of the > aircraft at that point in time. If we were to report the location of > this CG to FlightGear, and IF the origin of the 3D model was allowed > to shift (by some magic) and always be coincident with the "virtual > CG" in the 3D model, then we'd all always be happy and everything > would match up fine. The problem is, the CG shifts and the 3D model > coordinate system can't. > > Since the FDM knows (or can calculate) where the nose is at all times, > we simply report the nose location to FlightGear, and by convention > FlightGear places the 3D model's nose at the point reported by JSBSim > - the CG falls into place as needed IFF the 3D model is defined (or > scaled/rotated/translated in the scene graph) correctly as described > previously. And said nose location *includes* any translation the nose experiences due to the aircraft rotating about the cg. In other words, if you could move the aircraft such that only the pitch angle changes (not terribly real, but humor me) and that pitch angle change results in the nose rising 10 feet, then the FDM reports the nose location as the CG altitude + 10 feet. So now, if the 3D model code positions the nose of the aircraft at that location and pitches it to the corresponding angle, the CG will not have moved at all but the nose will. And that means that the model will appear to rotate around the CG, just like it should (in free air, at least. On the ground is a different thing) > > Takeoffs and landings would look fine, etc. > > Jon > > ___ > Flightgear-devel mailing list > [EMAIL PROTECTED] > http://mail.flightgear.org/mailman/listinfo/flightgear-devel -- Tony Peden <[EMAIL PROTECTED]> ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Aerodynamic centre and 3D models
David Megginson wrote: > Thanks -- your explanation and Jon's has made it all clear, and the > discussion has been useful. So, as far as I understand, JSBSim > supports this in JSBSim CVS but not yet in FlightGear. Does YASim > support setting the reference point yet? I'm not sure exactly what this is for. I can (and probably should) export the C.G. position for the view code to use appropriately. But the VRP stuff seems like a double-correction. It's basically identical to the view center offset stuff, isn't it? Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Aerodynamic centre and 3D models
David Megginson <[EMAIL PROTECTED]> said: > Jim Wilson wrote: > > > Yes. In YASim, the 0,0,0 of the fuselage property is the origin. So if ax=0, > > ay=0, az=0 is used then the nose is origin in YASim. > > It would be nice to be able to specify the point in YASim as well, so we > don't have to physically alter the models. For the PA-28-161, though, I'll > just have to move the model down a little bit. > Actually the 3D model is fine. This is from the YASim config file for the pa28-161. Note that the origin is always 0,0,0 in YASim. So in this case it is 0.5 along the X axis which is the longitudinal axis: Change it to this: What I have done is move the fuselage back half a meter. I am not sure what do do with the "midpoint" value but iirc it is a ration and not a dimension. In the rest of the config just subtract the 0.5 from each "x=" value and you will have the same exact flight model only the origin is at the nose (there is probably about a dozen of those to change). Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Re:[Flightgear-cvslogs]CVS:data/Aircraft/pa28-161
Vivian Meazza <[EMAIL PROTECTED]> said: > > Josh Babcock > > > Vivian Meazza wrote: > > > > > > > >I enter the loop in a shallow dive, 2nd stage boost on, 350 > > kts, pull > > >baaack the stick and the model rolls violently and does not > > enter the > > >loop ... Works fine in other models so it's not the obvious - the > > >joystick. But I expect I'm doing something wrong. > > > > > > > > > > > Yup. Specifically, you are doing a snap roll. If you can > > keep the the > > AOA down, the plane won't stall and go into a snap roll. You > > could also > > try adding some flaps, but I'm not sure if that would bleed > > off too much > > energy. Best to just make the loop bigger. Remember, pull back a > > little, and the plane goes up. Pull back a lot, and the > > plane goes down > > ... fast. > > Thanks for the advice. It's not easy without Pilot's Notes specifying some > entry conditions. I was guessing 350 kts I was probably pulling back too > hard, difficult to remember. Too slow, and the model falls off the top, of > course. Back to the Hunter - it's much easier - but I designed it that way, > and it flew that way too :-). It sure is fun doing those, I just tried it for the first time in a while on the p51. You want to get up in the air (4500-5000ft agl). Manfold pressure should be in the 50-55 range, and prop pitch at max rpm. Go into a nice dive and pull back in the low 2000ft range. Once you get it the aircraft going good you can actually pull back pretty hard...and you can do multiple loops if your pilot has the stomach. You'll stall it quicker if you do a large loop, it gives gravity too much time to bleed off your momentum. Flaps will increase drag and not really help much with those stalls. The FDM is probably a little off. Andy just made a prop gearing change to YASim a couple weeks ago that should be useful in making the P51-D more accurate with a little tinkering. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Aerodynamic centre and 3D models
Jon S Berndt <[EMAIL PROTECTED]> said: > On Thu, 12 Feb 2004 22:56:46 +0100 > Mathias Fröhlich <[EMAIL PROTECTED]> wrote: > > > > >Even JSBSim CVS does not support this visual reference point yet. > >There is a > >patch pending in Jon's mailbox to report the visual reference point > >to > >flightgear and define a reference point in each JSBSim aircraft > >config. > > ?? I thought I had already committed these. You might want to double > check. In any case, I already committed to CVS the code that reports > the VRP, as well as to make the corrections to the transforms (as you > pointed out). These are committed. However, in JSBSim.cxx, the > relevant code *may* still be commented out, waiting for the VRP > specification in the aircraft models. It's a matter of timing, I > think; we need to get everything together, then submit it. But, I > think this will require work for the 3D model, too. ? > Actually there is a way to offset the 3D model so that it's origin is actually shifted to a different location, without editing the 3D model, and AFAIK not redoing the animations. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Aerodynamic centre and 3D models
Andy Ross wrote: I'm not sure exactly what this is for. I can (and probably should) export the C.G. position for the view code to use appropriately. But the VRP stuff seems like a double-correction. It's basically identical to the view center offset stuff, isn't it? It's the location on the plane where the FDM reports the lon/lat/alt. It's kind-of a nifty idea, actually. All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Aerodynamic centre and 3D models
David Megginson <[EMAIL PROTECTED]> said: > Andy Ross wrote: > > > I'm not sure exactly what this is for. I can (and probably should) > > export the C.G. position for the view code to use appropriately. But > > the VRP stuff seems like a double-correction. It's basically > > identical to the view center offset stuff, isn't it? > > It's the location on the plane where the FDM reports the lon/lat/alt. It's > kind-of a nifty idea, actually. In relation to? It is always 0,0,0 in Yasim. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Aerodynamic centre and 3D models
> David Megginson <[EMAIL PROTECTED]> said: > > > It's the location on the plane where the FDM reports the > > lon/lat/alt. It's kind-of a nifty idea, actually. > > In relation to? It is always 0,0,0 in Yasim. > > Best, > > Jim JSBSim could also define the tip of the nose as (0,0,0). It really doesn't matter a whole lot. However, internally, the FDMs really don't care about exact locations - only relative distances. I think we all agree on that. So, instead of defining some arbitrary frame, _we_use_an_industry_standard_, which is the structural frame that the manufacturer defines, when available. It is always (in my experience) X positive aft, Y positive right, with the origin being seemingly arbitrary. For us, that solution works great and is very appropriate. When the frame is not known, we could just as easily decide that the origin could be at the nose tip. In any case, given the potential variances in structural coordinate frames - and especially considering that there are many FDMs, the 3D model placement code needs to be able to match up with the FDM. I think our VRP solution works well, and is versatile given our situation. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Aerodynamic centre and 3D models
David Megginson wrote: Andy Ross wrote: I'm not sure exactly what this is for. I can (and probably should) export the C.G. position for the view code to use appropriately. But the VRP stuff seems like a double-correction. It's basically identical to the view center offset stuff, isn't it? It's the location on the plane where the FDM reports the lon/lat/alt. It's kind-of a nifty idea, actually. True, but... This is a chunk of calculations running every frame. In the olden days, the cost would be too high. Our Aerodynamic modelers always seemed to know where the empty weight CG was every frame without additional calculations. That said, we made the graphic artists translate the visual model such that the 0,0,0 point for the model was the empty weight CG. This operation was done once. We were always able to put those spare calculations to good use adding fidelity elsewhere. Realize that I don't have a dog in this fight. I'm just conveying a bit of simulation history. It's up to you folks to decide what to do with the blessings of Moore's law... :-) -- Russ Conway's Law: "The structure of a system tends to mirror the structure of the group producing it." -- Mel Conway Datamation (1968) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: saving fgfs replay session
Alex Romosan <[EMAIL PROTECTED]> said: > Jorge Van Hemelryck <[EMAIL PROTECTED]> writes: > > > Try xvidcap... I haven't managed to really make a movie file with it > > yet, but that's what it's supposed to do. > > thanks. xvidcap worked great. i put the movie up at: > > http://caliban.lbl.gov/fgfs-carrier.mpeg > > the file is 33548 kB, and the movie is 800x600 in mpeg4 format. > unfortunately the frame rate dropped to about 11fps (because of the > recording). Very nice landing. Did you make any attempt to get audio? Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Aerodynamic centre and 3D models
> True, but... This is a chunk of calculations running every frame. In > the olden days, the cost would be too high. These days, it's not even a spec on a flea on the butt of an elephant in terms of the overall FDM calculations - which in turn are not much of a spec on a flea in the overall FlightGear calculations. > Our Aerodynamic modelers always seemed to know where the > empty weight CG was every frame without additional calculations. That's not the issue, though. We FDM guys know absolutely where everything is at all times within the FDMs. Jon -- Project Coordinator JSBSim Flight Dynamics Model http://www.jsbsim.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Aerodynamic centre and 3D models
On Freitag, 13. Februar 2004 02:59, Andy Ross wrote: > David Megginson wrote: > > Thanks -- your explanation and Jon's has made it all clear, and the > > discussion has been useful. So, as far as I understand, JSBSim > > supports this in JSBSim CVS but not yet in FlightGear. Does YASim > > support setting the reference point yet? > > I'm not sure exactly what this is for. I can (and probably should) > export the C.G. position for the view code to use appropriately. But > the VRP stuff seems like a double-correction. It's basically > identical to the view center offset stuff, isn't it? If you denote with C.G. a _FIXED_ point in your aircraft like the static center of gravity which does not move relative to the aircraft when you burn fuel, then more or less, yes. What you gain is that the coordinate values, you can read off from blueprints, can be used directly to position submodels in your 3D model, without first shifting that positions with the center of gravity. Also, if a modeller likes to have the visual reference point identical to the static center of gravity, he can simply place it there. Greetings Mathias -- Mathias Fröhlich, email: [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
