Re: [Flightgear-devel] 3D model origin proposal
Jim Wilson wrote: Besides in my flight modeling methodology deficient mind, it kind of makes sense that position data is tied to a fixed location on the aircraft. Working relative to a fixed location (whcihc could be inside the airframe, but doesn't need to be) works quite will I must say. But then again, how about the aero refference point? This is single the location in the aircraft that can be used to describe the aircrafts flightpath because all other locations will rotate around it in flight. This point has to be known by 3D modellers already because the aircraft will rotate around that point (which basically makes it the origin for the model). Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] 3D model origin proposal
Erik Hofman writes: But then again, how about the aero refference point? This is single the location in the aircraft that can be used to describe the aircrafts flightpath because all other locations will rotate around it in flight. This point has to be known by 3D modellers already because the aircraft will rotate around that point (which basically makes it the origin for the model). As others have mentioned, though, that point moves around during flight depending on how the plane is loaded, how much fuel you've burned, whether you're subsonic or supersonic, whether the flaps are extended, whether you've just dropped skydivers or a bomb, etc. etc. In a Cessna 150, the change is going to be very small; in a supersonic bomber, the change might be very, very large (I'm just guessing, though). That's why we need to establish a fixed reference point for each aero model (it doesn't matter where, though I prefer the published FAA weight and balance datum) and then report the offset from the C.G. to that reference point every frame. The A/C 3D code simply has to apply that offset so that the centre of rotation (and the plane) is always in the right spot. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] 3D model origin proposal
David Megginson wrote: Erik Hofman writes: But then again, how about the aero refference point? This is single the location in the aircraft that can be used to describe the aircrafts flightpath because all other locations will rotate around it in flight. This point has to be known by 3D modellers already because the aircraft will rotate around that point (which basically makes it the origin for the model). As others have mentioned, though, that point moves around during flight depending on how the plane is loaded, how much fuel you've burned, whether you're subsonic or supersonic, whether the flaps are extended, whether you've just dropped skydivers or a bomb, etc. etc. In a Cessna 150, the change is going to be very small; in a supersonic bomber, the change might be very, very large (I'm just guessing, though). To the best of my knowledge (whatever that might be ;-) ) the CG moves around, but the aero refference point is steady? Jon, Tony? Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Ground elevation at an arbitrary point
Some time ago (Sept/Oct) there was a long discussion about getting the ground elevation at an arbitrary point which left me very confused after reading it and didn't seem to come to any definate conclusion. What is the situation at the moment? Is there a function like double GetGroundElev(Point3D lat_and_lon_of_somewhere) anywhere which will return the ground elev if the appropriate tile is already loaded and a distinctive value (-?) if the tile is not loaded? Cheers - Dave ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] 3D model origin proposal
On Mon, 2002-12-16 at 04:07, Erik Hofman wrote: David Megginson wrote: Erik Hofman writes: But then again, how about the aero refference point? This is single the location in the aircraft that can be used to describe the aircrafts flightpath because all other locations will rotate around it in flight. This point has to be known by 3D modellers already because the aircraft will rotate around that point (which basically makes it the origin for the model). As others have mentioned, though, that point moves around during flight depending on how the plane is loaded, how much fuel you've burned, whether you're subsonic or supersonic, whether the flaps are extended, whether you've just dropped skydivers or a bomb, etc. etc. In a Cessna 150, the change is going to be very small; in a supersonic bomber, the change might be very, very large (I'm just guessing, though). To the best of my knowledge (whatever that might be ;-) ) the CG moves around, but the aero refference point is steady? Jon, Tony? No, it doesn't, but you can't exactly walk up to the aircraft and point at it either. Erik ___ 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] 3D model origin proposal
Tony Peden wrote: To the best of my knowledge (whatever that might be ;-) ) the CG moves around, but the aero refference point is steady? Jon, Tony? No, it doesn't, but you can't exactly walk up to the aircraft and point at it either. Hmm, maybe I've been busy with JSBSim too much lately. Do you think 25% chord would be close enough? Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] 3D model origin proposal
To the best of my knowledge (whatever that might be ;-) ) the CG moves around, but the aero reference point is steady? Jon, Tony? yawn ... wow lots of email this morning ... I just woke up and already it looks like I am going to have to *think* Erik is right. The aero reference point is the point about which the aero coefficients are referenced to. Tony can elaborate. smime.p7s Description: application/pkcs7-signature
Re: [Flightgear-devel] 3D model origin proposal
On Mon, 2002-12-16 at 04:29, Erik Hofman wrote: Tony Peden wrote: To the best of my knowledge (whatever that might be ;-) ) the CG moves around, but the aero refference point is steady? Jon, Tony? No, it doesn't, but you can't exactly walk up to the aircraft and point at it either. Hmm, maybe I've been busy with JSBSim too much lately. Do you think 25% chord would be close enough? Since we seem to be leaning towards picking a fixed point on the aircraft, we really should pick one which requires a minimum of explanation and/or instruction. The aero reference point isn't terribly complicated, but its certainly more so than the nose. Erik ___ 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] 3D model origin proposal
David wrote: As others have mentioned, though, that point moves around during flight depending on how the plane is loaded, how much fuel you've burned, whether you're subsonic or supersonic, whether the flaps are extended, whether you've just dropped skydivers or a bomb, etc. etc. In a Cessna 150, the change is going to be very small; in a supersonic bomber, the change might be very, very large (I'm just guessing, though). The CG moves around with this, but not the aerodynamic reference point. And, yes, this is why the CG isn't really a good reference point. That's why we need to establish a fixed reference point for each aero model (it doesn't matter where, though I prefer the published FAA weight and balance datum) and then report the offset from the C.G. to that reference point every frame. The A/C 3D code simply has to apply that offset so that the centre of rotation (and the plane) is always in the right spot. Here's an example of the concern I have. Let's say you are doing your takeoff run in a 747 and you have begun rotating. You have rotated to 10 degrees pitch but have not yet left the ground. JSBSim reports the location of the CG - this is the way generalized rigid body equations of motion work (the movement of the center of gravity is calculated). So, the rendering code has a pitch angle and the location of the center of gravity. Now, since the CG of an aircraft is generally slightly ahead of the wheels, when the 747 rotated it lifted the CG slightly. If the aircraft model origin is at the nose of the 3D model in its coordinate system, then merely pitching it up at 10 degrees and raising the origin by the amount that the CG has raised will actually place the wheels and part of the fuselage under the runway. The problem is that the nose is very far ahead of the CG, and the 10 degree rotation at liftoff has lift the nose very much higher than the CG. We all know that we can rotate the 3D model correctly, but the issue is the translation. JSBSim reports the location of the CG, which is NOT the translation for any point on the aircraft, but ONLY the CG. So, the solution is that JSBSim (and other FDMs) could report the location of the 3D model origin at every frame for rendering purposes. OR, FlightGear could derive it - given it may have more intimate knowledge of the 3D model AND the CG. True? Problem is, the FDM guys don't KNOW what point will be chosen for the 3D model origin. The FDM could report the position of any point in our own coordinate system. If we gave the location of the nose as a commonly known reference point, then I believe the rendering code could have that location to use as its pivot point. I hope I understand the problem correctly, and that this isn't muddying the water. The above is a possible solution to one problem, though maybe not this one? I just woke up! Jon smime.p7s Description: application/pkcs7-signature
Re: [Flightgear-devel] 3D model origin proposal
Jon Berndt writes: We all know that we can rotate the 3D model correctly, but the issue is the translation. JSBSim reports the location of the CG, which is NOT the translation for any point on the aircraft, but ONLY the CG. So, the solution is that JSBSim (and other FDMs) could report the location of the 3D model origin at every frame for rendering purposes. OR, FlightGear could derive it - given it may have more intimate knowledge of the 3D model AND the CG. True? Problem is, the FDM guys don't KNOW what point will be chosen for the 3D model origin. The FDM could report the position of any point in our own coordinate system. If we gave the location of the nose as a commonly known reference point, then I believe the rendering code could have that location to use as its pivot point. I hope I understand the problem correctly, and that this isn't muddying the water. I think that when we add colision detection into the mix the most sensible reference point is the center of the bounding volume collision includes wheel-runway contact points ect we used the static center as a 'close enough kludge' historically but if we are going to change the location IMHO we should do so in a way that increases accuracy. ie the nose is further away from the geometric center then the published static center So to summarize the needed locations discussed so far 1:center of gravity used by FDM 2) aerodynamic center used by FDM 3) eye location used to render the scene 4) geometric center used by SSG and collision detection Of these the one that corresponds to 'everday speak' and common engineering usage is (4) Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Ground elevation at an arbitrary point
On 12/16/02 at 12:07 PM David Luff wrote:
Some time ago (Sept/Oct) there was a long discussion about getting the
ground elevation at an arbitrary point which left me very confused after
reading it and didn't seem to come to any definate conclusion. What is
the
situation at the moment? Is there a function like
double GetGroundElev(Point3D lat_and_lon_of_somewhere)
anywhere which will return the ground elev if the appropriate tile is
already loaded and a distinctive value (-?) if the tile is not loaded?
Well, the fgCurrentElev(...) functions in hitlist.[ch]xx look promising,
but I might need a bit of help figuring out how to use them:
// Associated functions, assuming a wgs84 world with 0,0,0 at the
// center, find the current terrain intersection elevation for the
// point specified.
bool fgCurrentElev( sgdVec3 abs_view_pos,
sgdVec3 scenery_center,
ssgTransform *terra_transform,
FGHitList *hit_list,
double *terrain_elev,
double *radius,
double *normal );
bool fgCurrentElev( sgdVec3 abs_view_pos,
sgdVec3 scenery_center,
FGHitList *hit_list,
double *terrain_elev,
double *radius,
double *normal );
What does the scenery_center refer to? Is this the exact location at which
I receive the terrain_elev, or the center of the tile? What is the
abs_view_pos? Is this perhaps the point at which we get the elev, or is
this the direction vector in which we are looking? What is the hit_list
and can I ignore it - ie. just use a local one and discard it, eg:
{
FGHitList tempHitList;
bool haveIntersection = fgCurrentElev( ..., ..., tempHitList, ...,
..., ...);
}
or do I need to pay more attention to it? Lastly, what do the radius and
normal refer to - bounding sphere and normal of the specific intersected
polygon perhaps?
Sorry for all the questions at once - this is all a bit daunting to me and
I haven't poked my head into the 3D bits of Flightgear for a while.
Cheers - Dave
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] 3D model origin proposal
On Mon, 16 Dec 2002 13:29:18 +0100, Erik Hofman [EMAIL PROTECTED] wrote in message [EMAIL PROTECTED]: Tony Peden wrote: To the best of my knowledge (whatever that might be ;-) ) the CG moves around, but the aero refference point is steady? Jon, Tony? No, it doesn't, but you can't exactly walk up to the aircraft and point at it either. Hmm, maybe I've been busy with JSBSim too much lately. Do you think 25% chord would be close enough? ..heh, I'd _love_ to see you balance a 747 on your index fingers. ;-) ..I like David M's proposal on FAA type datum points, those are available for all FAA-certified planes, and as we learn more, likely a good starting point for a datum FAQ for aero and 3D modellers of the not-yet/no-way!/non-FAA aircraft. -- ..med vennlig hilsen = with Kind Regards from Arnt... ;-) ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] 3D model origin proposal
Right. In other words if the nose is the 3D model origin, it's altitude is made that of the CG (as reported by JSBSim). The aircraft is angled up for takeoff and the nose is way down near where the wheels should be and the rest of the model is below the surface. To throw another wrench into the mix, can you tell me if and/or how the camera works when the viewpoint is from inside the cabin (pilot eyepoint) - does that seem to work OK, now? ANd when viewing from a spotter plane, is this where the problem initially was discovered? That's right. But if the choose the nose (which I now agree is the way to go) and report the lon/lat/alt at that nose, then we'll be way ahead at least as far as getting JSBsim and YASim in sync. You are right about the options. We could perhaps do the conversion on fg side in the fginterface. Yes, I really think the nose/hub tip is the way to go, because it is very easily seen and requires few or no calculations. Norman proposes an alternative which I respectfully ask to disagree with, but I suppose the question should be asked of those who design the 3D models and the coders on the FGFS side who place the airplane in the scene. From our side, we can provide the CG and euler angles, as we already do, and also another fixed point in the structural frame - preferably one that is commonly known, unambiguous, and readily visible on a 3-view. When determining a common structural reference point, keep in mind many different types of aircraft we simulate now, and may want to in the future. P-51, B-52, DC-3, A-4, F-5, A-6, F-117, P-38, Wright Flyer, Incom X-Wing (Interstellar fighter), a rocket of any kind ... Also, Andy: which point does YASim provide to FGFS? Is it the CG, or some other point? Jon smime.p7s Description: application/pkcs7-signature
Re: [Flightgear-devel] 3D model origin proposal
On Mon, 16 Dec 2002 07:14:59 -0600, Jon Berndt [EMAIL PROTECTED] wrote in message [EMAIL PROTECTED]: David wrote: As others have mentioned, though, that point moves around during flight depending on how the plane is loaded, how much fuel you've burned, whether you're subsonic or supersonic, whether the flaps are extended, whether you've just dropped skydivers or a bomb, etc. etc. In a Cessna 150, the change is going to be very small; in a supersonic bomber, the change might be very, very large (I'm just guessing, though). The CG moves around with this, but not the aerodynamic reference point. And, yes, this is why the CG isn't really a good reference point. That's why we need to establish a fixed reference point for each aero model (it doesn't matter where, though I prefer the published FAA weight and balance datum) and then report the offset from the C.G. to that reference point every frame. The A/C 3D code simply has to apply that offset so that the centre of rotation (and the plane) is always in the right spot. Here's an example of the concern I have. Let's say you are doing your takeoff run in a 747 and you have begun rotating. You have rotated to 10 degrees pitch but have not yet left the ground. JSBSim reports the location of the CG - this is the way generalized rigid body equations of motion work (the movement of the center of gravity is calculated). So, the rendering code has a pitch angle and the location of the center of gravity. Now, since the CG of an aircraft is generally slightly ahead of the wheels, when the 747 rotated it lifted the CG slightly. If the aircraft model origin is at the nose of the 3D model in its coordinate system, then merely pitching it up at 10 degrees and raising the origin by the amount that the CG has raised will actually place the wheels and part of the fuselage under the runway. The problem is that the nose is very far ahead of the CG, and the 10 degree rotation at liftoff has lift the nose very much higher than the CG. We all know that we can rotate the 3D model correctly, but the issue is the translation. JSBSim reports the location of the CG, which is NOT the translation for any point on the aircraft, but ONLY the CG. So, the solution is that JSBSim (and other FDMs) could report the location of the 3D model origin at every frame for rendering purposes. OR, FlightGear could derive it - given it may have more intimate knowledge of the 3D model AND the CG. True? Problem is, the FDM guys don't KNOW what point will be chosen for the 3D model origin. The FDM could report the position of any point in our own coordinate system. If we gave the location of the nose as a commonly known reference point, then I believe the rendering code could have that location to use as its pivot point. I hope I understand the problem correctly, and that this isn't muddying the water. The above is a possible solution to one problem, though maybe not this one? I just woke up! ..and then we have the (also!) moving center of pressure... ;-) ..we're looking for a calculable moving pivot point near these 2. ..I will much rather see those of you guys who knows how to do this black magic, write sexy fdm code, than paint (also needed) sexy 3D models. 3D art gurus too understands a FAA-_declared_ datum point, even with George W. hiring the FAA chief. -- ..med vennlig hilsen = with Kind Regards from Arnt... ;-) ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] 3D model origin proposal
--- Norman Vine [EMAIL PROTECTED] wrote: Jon Berndt writes: We all know that we can rotate the 3D model correctly, but the issue is the translation. JSBSim reports the location of the CG, which is NOT the translation for any point on the aircraft, but ONLY the CG. So, the solution is that JSBSim (and other FDMs) could report the location of the 3D model origin at every frame for rendering purposes. OR, FlightGear could derive it - given it may have more intimate knowledge of the 3D model AND the CG. True? Problem is, the FDM guys don't KNOW what point will be chosen for the 3D model origin. The FDM could report the position of any point in our own coordinate system. If we gave the location of the nose as a commonly known reference point, then I believe the rendering code could have that location to use as its pivot point. I hope I understand the problem correctly, and that this isn't muddying the water. I think that when we add colision detection into the mix the most sensible reference point is the center of the bounding volume collision includes wheel-runway contact points ect we used the static center as a 'close enough kludge' historically but if we are going to change the location IMHO we should do so in a way that increases accuracy. ie the nose is further away from the geometric center then the published static center The point we pick need not have any particular signifigance (we can calculate a lat/lon/alt for anyplace relative to the aircraft), so why should we pick a point which requires explanation and/or instruction on our part and more work on the part of the 3D modeler. The nose is something that everyone can instantly understand and locate. That is not true for the aero ref point, center of gravity, center of geometry, etc. FWIW, I still think the location should be configurable by the 3D modeler in the FG xml files. FG would pass that info to the FDM and it would return the appropriate position or FG would do the calcs itself. The wind doesn't seem to be blowing that way, however ... So to summarize the needed locations discussed so far 1:center of gravity used by FDM 2) aerodynamic center used by FDM 3) eye location used to render the scene 4) geometric center used by SSG and collision detection Of these the one that corresponds to 'everday speak' and common engineering usage is (4) Well, now, that depends on what kind of engineering you do. Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel __ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Ground elevation at an arbitrary point
David Luff [EMAIL PROTECTED] said: What does the scenery_center refer to? Is this the exact location at which I receive the terrain_elev, or the center of the tile? Neither actually, but it is a tile center. It is usually the center of the tile that the aircraft is currently located over. You're query location needs to be reasonably close to the scenery_center to get a good elevation. Depending on what you are doing (e.g. placing buildings) the the current FDM scenery_center is probably good enough. Take a look at the code under Tile Manager Updates to approx line 1200 in main.cxx, to see how the query works. Note that prep_ssg_nodes needs to be run to reallign the scenery vertices if you change the scenery center, before doing a query. What is the abs_view_pos? This is where you are. If I recall this is in geocentric coordinates. Same units as the scenery_center. or do I need to pay more attention to it? Lastly, what do the radius and normal refer to - bounding sphere and normal of the specific intersected polygon perhaps? IIRC the normal would be the straight down vector to the intersecting ground polygon. It seems to me that Norman recently made some changes that simplified what you are trying to do. Not sure if they are in CVS or not. There's a good chance you can use the same technique I used (see that main.cxx reference) depending on what you want to do. Just heed the comment around line 1227...the view location update/query needs to be done last before the rendering. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] 3D model origin proposal
FWIW, I still think the location should be configurable by the 3D modeler in the FG xml files. FG would pass that info to the FDM and it would return the appropriate position or FG would do the calcs itself. The wind doesn't seem to be blowing that way, however ... Actually, I thought of that too and it seems like a good idea. That is, that the 3D model asks for the lat/lon/alt of a specific point on the aircraft. This is probably the most configurable and versatile way to go. However ... which point does the FGFS side ask for the position of? I would assume they would ask for the point of origin of the 3D model (perhaps the nose, perhaps the firewall, perhaps the center of bounding box). When the FGFS side asks us (FDM) for a position, how do we know where that position lies in our frame of reference? When I think about this for long enough, I keep coming back to this: that if the nose is taken to be a common reference point between the FDM and the 3D model, then we (FDM) can simply provide the location of the Nose Reference Point (NRP) and the FGFS side can use that to properly place the vehicle. Now, the nose may not be the origin of the 3D model, but the NRP will be known relative to the 3D model origin. So, the FGFS side will be able to bias or offset the point we return and still place the model correctly in the scene. My $0.03. Jon smime.p7s Description: application/pkcs7-signature
Re: [Flightgear-devel] 3D model origin proposal
Tony Peden wrote: The point we pick need not have any particular signifigance (we can calculate a lat/lon/alt for anyplace relative to the aircraft), so why should we pick a point which requires explanation and/or instruction on our part and more work on the part of the 3D modeler. The nose is something that everyone can instantly understand and locate. coughUFO, helicopter, balloon, parachutecough That is not true for the aero ref point, center of gravity, center of geometry, etc. Well, to rotate the aircraft realistically the refference point should be known by the 3D modellers, but that aside. FWIW, I still think the location should be configurable by the 3D modeler in the FG xml files. FG would pass that info to the FDM and it would return the appropriate position or FG would do the calcs itself. The wind doesn't seem to be blowing that way, however ... Maybe the pilot's eye point would be a good start, then the 3D modellers can define thair offset to the models origin in the XML file. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] 3D model origin proposal
Jon Berndt [EMAIL PROTECTED] said: Right. In other words if the nose is the 3D model origin, it's altitude is made that of the CG (as reported by JSBSim). The aircraft is angled up for takeoff and the nose is way down near where the wheels should be and the rest of the model is below the surface. To throw another wrench into the mix, can you tell me if and/or how the camera works when the viewpoint is from inside the cabin (pilot eyepoint) - does that seem to work OK, now? ANd when viewing from a spotter plane, is this where the problem initially was discovered? The camera is locked in relation to the reported lon/lat/alt. So it is actually in the same position inside the model all the time (the camera of course can be moved but it is always in reference to the reported lon/lat/alt position). Well yes the problem really is that the FDMs are reporting the position data differently. The origins are different and it makes it impossible to share 3D Model configurations between different FDMs. The other problem that David brought up which I didn't understand at first is the CG is variable and therefore the FDM origin is variable, and we aren't taking that into account in the modeling. My opinion is that problem would be sufficiently resolved if the lon/lat/alt was reported from a fixed point on the aircraft. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] 3D model origin proposal
Well, to rotate the aircraft realistically the refference point should be known by the 3D modellers, but that aside. The rigid body rotates about the CG, not the aero ref. pt. smime.p7s Description: application/pkcs7-signature
RE: [Flightgear-devel] 3D model origin proposal
Jon Berndt [EMAIL PROTECTED] said: When I think about this for long enough, I keep coming back to this: that if the nose is taken to be a common reference point between the FDM and the 3D model, then we (FDM) can simply provide the location of the Nose Reference Point (NRP) and the FGFS side can use that to properly place the vehicle. Now, the nose may not be the origin of the 3D model, but the NRP will be known relative to the 3D model origin. So, the FGFS side will be able to bias or offset the point we return and still place the model correctly in the scene. Yes and we already have that capability. What we don't have yet is a way to offset what the chase view is looking at, but that won't be a problem. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] 3D model origin proposal
Jon Berndt wrote: Well, to rotate the aircraft realistically the refference point should be known by the 3D modellers, but that aside. The rigid body rotates about the CG, not the aero ref. pt. Even when in motion? It seems to me there would otherwise be no need for a refference point. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] 3D model origin proposal
On 12/16/02 at 9:36 AM Jon Berndt wrote: Well, to rotate the aircraft realistically the refference point should be known by the 3D modellers, but that aside. The rigid body rotates about the CG, not the aero ref. pt. What about rotation (the taking-off one)? Surely in that case it rotates about the axles? Cheers - Dave ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] 3D model origin proposal
--- Erik Hofman [EMAIL PROTECTED] wrote: Jon Berndt wrote: Well, to rotate the aircraft realistically the refference point should be known by the 3D modellers, but that aside. The rigid body rotates about the CG, not the aero ref. pt. Even when in motion? In the FDM's (all of them, AFAIK), yes. Always. In reality, the aircraft will rotate about the cg in air and some other point if any of the gear are touching the ground. During takeoff rotation and landing de-rotation, for example, the aircraft will rotate about the main gear. It seems to me there would otherwise be no need for a refference point. It's still needed. In order to calculate the moment coefficients from measured moments, one needs to set a point on the aircraft to take the moment arms from. This has traditionally been chosen as the point 25% of the way aft along the mean aerodynamic chord. The reasoning for this is that for low speed aircraft, it is a reasonable estimate of the wing's center of pressure (i.e. where you'd place the lift vector both chord- and span-wise). In truth, this location varies with (at least) the airfoil section, wing planform, and Mach number, so when using it as a constant reference point we have to call it something different. I chose to call it the aero reference point. And since someone might reduce measured data using something other than the 1/4 chord of the MAC, this number needs to be configurable. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel __ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] 3D model origin proposal
On Mon, 16 Dec 2002 15:56:13 + David Luff [EMAIL PROTECTED] wrote: What about rotation (the taking-off one)? Surely in that case it rotates about the axles? Cheers - Dave Well ... sort of. In real life, yes, the gear is a pivot point. However, in the FDM sense, the ground isn't really there to pivot about - only a force and moment that is applied to the aircraft CG as is any other force/moment (aero, propulsion, etc.). We do not handle the rollout any differently because there is contact with the ground, really (except that the calculations are a b!t*h at very small velocities). The EOM still is working with forces and moments (rotations and translations) about the CG. When the aircraft rotates at about takeoff velocity, it is really rotating about the CG, but the CG is ALSO translating upward and slightly aft. The appearance could be taken to be physically rotating about the gear contact point with the ground, but mathematically, we are still rotating and translating about the CG. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] 3D model origin proposal
On Mon, 16 Dec 2002 15:30:31 - Jim Wilson [EMAIL PROTECTED] wrote: Yes and we already have that capability. What we don't have yet is a way to offset what the chase view is looking at, but that won't be a problem. So, being supplied with the Nose Ref Pt. lat/lon/alt won't give you anything new? That would be purely for proper viewing from the chase plane? (A worthy reason in itself). Another comment (sort of a question): I believe that the pilot eyepoint supplied in the JSBSim config file is being used for proper viewpoint positioning(?). I can't remember if this is true or not. IIRC, with LaRCSim, the view was taken from the CG. In something like a shuttle, or a 747, you (the pilot) are still quite a ways above the pavement when the main gear touches down, and as you rotate the nose down to likewise place the nosegear on terra firma, there is not only a rotation that occurs, but a translation of the pilot eyepoint. That is properly modeled, too? I haven't had time to look into that at all. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] 3D model origin proposal
Rex du Pont wrote: I've been watching this discussion for about a week. I am using the JSBSim model on a real airplane development project, to give you some background. Seems to me that the question is about how to make a 3D model look right from outside, probably from a distance of several wingspans away. In that case, you do not have to be precise about the congruence of the point of rotation and the cg, so long as you are not using the rotation point for any of the physics. I would guess that the cg is near the 25% chord point, and within a foot or so of the center of the wing vertically, so that if you know where that is relative to the nose, or other origin point, you can make it look right in flight. I'd vote for 25% chord point on the wing center line for rotation. If the model uses the nose as a reference, you would just have to know the correct offsets, or estimate them from a side view. You could have a problem at or near the ground for the reasons discussed before. On the ground you rotate about the gear, not the cg. You could either accept having the wheels sink into the runway (or float above it) or incorporate an "gear offset" when there is any WOW. I suppose this could jerk the plane onto the ground if the point of rotation is set low, but, on the whole it would give you a pretty realistic flight. I suppose you could resolve this by empirically setting the vertical CG position so that the gear looks right at rest, from outside, by cut and try. The FDM model must know where the CG is. The 3D view must know where the wings are in relation to the nose, etc. Where the MAC is on a swept wing is a matter of educated guesswork, unless someone tells you, but you could come pretty close visually. I would suggest that you try something like rotating in the air around something simple like the 25% chord guesstimate, on the centerline, and then adjust vertically to have the gear just touch the ground at rest. How does the 3D deal with gear extension? H. Try what looks right on the ground, then watch it take off and see what further adjustments you need. Rex du Pont Tony Peden wrote: --- Erik Hofman [EMAIL PROTECTED] wrote: Jon Berndt wrote: Well, to rotate the aircraft realistically the refference point should be known by the 3D modellers, but that aside. The rigid body rotates about the CG, not the aero ref. pt. Even when in motion? In the FDM's (all of them, AFAIK), yes. Always.In reality, the aircraft will rotate about the cg in air and some otherpoint if any of the gear are touching the ground. During takeoffrotation and landing de-rotation, for example, the aircraft will rotateabout the main gear. It seems to me there would otherwise be no need for a refferencepoint. It's still needed.In order to calculate the moment coefficients from measured moments,one needs to set a point on the aircraft to take the moment arms from. This has traditionally been chosen as the point 25% of the way aftalong the mean aerodynamic chord. The reasoning for this is that forlow speed aircraft, it is a reasonable estimate of the wing's center ofpressure (i.e. where you'd place the lift vector both chord- andspan-wise). In truth, this location varies with (at least) the airfoilsection, wing planform, and Mach number, so when using it as a constantreference point we have to call it something different. I chose tocall it the aero reference point. And since someone might reducemeasured data using something other than the 1/4 chord of the MAC, thisnumber needs to be configurable. Erik___Flightgear-devel mailing list[EMAIL PROTECTED]http://mail.flightgear.org/mailman/listinfo/flightgear-devel __Do you Yahoo!?Yahoo! Mail Plus - Powerful. Affordable. Sign up now.http://mailplus.yahoo.com___Flightgear-devel mailing list[EMAIL PROTECTED]http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Ground elevation at an arbitrary point
On 12/16/02 at 3:10 PM Jim Wilson wrote: David Luff [EMAIL PROTECTED] said: What does the scenery_center refer to? Is this the exact location at which I receive the terrain_elev, or the center of the tile? Neither actually, but it is a tile center. It is usually the center of the tile that the aircraft is currently located over. You're query location needs to be reasonably close to the scenery_center to get a good elevation. Depending on what you are doing (e.g. placing buildings) the the current FDM scenery_center is probably good enough. It's for the AI plane during taxiing and takeoff/landing run. In order to generate realistic radio traffic these may need to exist some distance from the fdm, but I guess that the rendering accuracy required decreases the further they are from the user. Going under the ground is not an option though if they are within sight of the user, unlike a building which may simply become less tall. Take a look at the code under Tile Manager Updates to approx line 1200 in main.cxx, to see how the query works. Note that prep_ssg_nodes needs to be run to reallign the scenery vertices if you change the scenery center, before doing a query. OK, I think I see what you're doing - changing the scenery center to the point of interest and then changing it back again when done. How expensive is this operation in the scheme of things - I see you do it every frame if the view location is different so I presume it can't be too bad? What is the abs_view_pos? This is where you are. If I recall this is in geocentric coordinates. Same units as the scenery_center. or do I need to pay more attention to it? Lastly, what do the radius and normal refer to - bounding sphere and normal of the specific intersected polygon perhaps? IIRC the normal would be the straight down vector to the intersecting ground polygon. It seems to me that Norman recently made some changes that simplified what you are trying to do. Not sure if they are in CVS or not. There's a good chance you can use the same technique I used (see that main.cxx reference) depending on what you want to do. Just heed the comment around line 1227...the view location update/query needs to be done last before the rendering. Thanks for the reply - I'll give it a go roughly along the lines of what you've done and see what happens! Cheers - Dave ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] 3D model origin proposal
On Mon, 16 Dec 2002 11:43:11 -0500 Rex [EMAIL PROTECTED] wrote: Rex du Pont wrote: Seems to me that the question is about how to make a 3D model look right from outside, probably from a distance of several wingspans away. In that case, you do not have to be precise about the congruence of the point of rotation and the cg, so long as you are not using the rotation point for any of the physics. I would guess that the cg is near the 25% chord point, and Well, with proper agreement and reference point, we can make this perfect. There's just some communication and cooperation needed for a little while, and I think we are nearly there. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] 3D model origin proposal
Arnt Karlsen writes: ..I like David M's proposal on FAA type datum points, those are available for all FAA-certified planes, and as we learn more, likely a good starting point for a datum FAQ for aero and 3D modellers of the not-yet/no-way!/non-FAA aircraft. In the end, it doesn't matter much, as long as the FDM gives us the offset vector from the CG to *some* known, fixed point on the aircraft (which the 3D model uses as its origin). All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] 3D model origin proposal
Jon Berndt wrote: Also, Andy: which point does YASim provide to FGFS? Is it the CG, or some other point? It provides the coordinates of the origin, be that the nose or centroid or FAA reference point or whatever. Going back into hiding now; wake me up if you need me to move the origins. :) Andy -- Andrew J. RossNextBus Information Systems Senior Software Engineer Emeryville, CA [EMAIL PROTECTED] http://www.nextbus.com Men go crazy in conflagrations. They only get better one by one. - Sting (misquoted) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] 3D model origin proposal
Tony Peden wrote: --- Erik Hofman [EMAIL PROTECTED] wrote: Jon Berndt wrote: Well, to rotate the aircraft realistically the refference point should be known by the 3D modellers, but that aside. The rigid body rotates about the CG, not the aero ref. pt. Even when in motion? In the FDM's (all of them, AFAIK), yes. Always. In reality, the aircraft will rotate about the cg in air and some other point if any of the gear are touching the ground. During takeoff rotation and landing de-rotation, for example, the aircraft will rotate about the main gear. This confuses me a bit. My gut feeling tels me that the lift generated on the various parts of the aircraft (fuselage included) would concentrate the aircrafts rotation around its aero reff. point instead of CG. Or is this the part where the moving CG comes in place? Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] 3D model origin proposal
Erik Hofman wrote: Jon Berndt wrote: Well, to rotate the aircraft realistically the refference point should be known by the 3D modellers, but that aside. The rigid body rotates about the CG, not the aero ref. pt. Even when in motion? It seems to me there would otherwise be no need for a refference point. That's exactly the point. The reference point is a completely arbitrary choice; it could be 4 light years away (well, with infinite precision floating point) and the math would still work just fine. The FDMs do the dynamics for you; if you draw the aircraft where they tell you it is, then you will always be drawing physically correct rotations. It is true that there is an *illusion* that happens when you look at a point far from the aircraft's c.g. which makes the airplane look like it is not rotating correctly. But this is an illusion; what is really happening is that the *viewpoint* is moving. The aircraft motion is correct in all cases. The fix for this issue is either to pick an origin near the c.g. (hard to enforce between FDM(s) and 3D model) or to have the view code explicitly look at the c.g. point instead of the origin (my preference, although it does complicate things a little). Andy -- Andrew J. RossNextBus Information Systems Senior Software Engineer Emeryville, CA [EMAIL PROTECTED] http://www.nextbus.com Men go crazy in conflagrations. They only get better one by one. - Sting (misquoted) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] 3D model origin proposal
David Luff wrote: Jon Berndt wrote: Well, to rotate the aircraft realistically the refference point should be known by the 3D modellers, but that aside. The rigid body rotates about the CG, not the aero ref. pt. What about rotation (the taking-off one)? Surely in that case it rotates about the axles? You're both right. Any point can be used as an origin, and any motion of a rigid body can be decomposed into a set of translations through space and rotations about that origin. There's really nothing magic about the center of gravity. It's just another point in the body's coordinate system. It's useful as a teaching aid because, in the absence (!) of any interaction, continuous (!) unaccelerated (!) motion of a rigid body can be captured by a constant velocity and a constant rotation speed. That's not true of other reference points (where unacclerated motion requires changing speeds and rotations). In the real world, bodies interact and accelerate, so the c.g. isn't quite as useful as a magic reference point (although it still simplifies the math internally). Here's a really quick thought experiment to make the point: Even if the aircraft is motionless on the ground, it's still rotating with a period of 24 hours about the center of the earth. The center of the Earth is most certainly *not* the c.g. of the aircraft. :) [This is not to say that current FDMs bother to model coriolis effects. I know for a fact that YASim doesn't.] Andy -- Andrew J. RossNextBus Information Systems Senior Software Engineer Emeryville, CA [EMAIL PROTECTED] http://www.nextbus.com Men go crazy in conflagrations. They only get better one by one. - Sting (misquoted) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] 3D model origin proposal
Jon S Berndt [EMAIL PROTECTED] said: On Mon, 16 Dec 2002 15:30:31 - Jim Wilson [EMAIL PROTECTED] wrote: Yes and we already have that capability. What we don't have yet is a way to offset what the chase view is looking at, but that won't be a problem. So, being supplied with the Nose Ref Pt. lat/lon/alt won't give you anything new? That would be purely for proper viewing from the chase plane? (A worthy reason in itself). Yes and no. It should greatly improve the situation as far as keeping the gear above the pavement in an external view. The other issue is the one I described before where it looks odd because the camera tracks the nose as it pitches up and down. That needs to be dealt with in the viewer code. Another comment (sort of a question): I believe that the pilot eyepoint supplied in the JSBSim config file is being used for proper viewpoint positioning(?). Actually I didn't know that existed. Being the last one to rework the viewer code I'm sure we aren't using it. I can't remember if this is true or not. IIRC, with LaRCSim, the view was taken from the CG. In a sense we are getting it from the CG under JSBSim because that is where the position data is being derived from on your end. The current view code is simply looking at the position and orientation data coming from the FDM. Position is assumed to be a fixed position on the aircraft. It is not of course, except in the case of YASim (AFAIK). Other things are applied but they are all user input related (things like turning the pilots head with the mouse). In something like a shuttle, or a 747, you (the pilot) are still quite a ways above the pavement when the main gear touches down, and as you rotate the nose down to likewise place the nosegear on terra firma, there is not only a rotation that occurs, but a translation of the pilot eyepoint. The pilot's view is always kept in sync with the 3D model's rotation (we actually start with the same matrices). Except as I noted above, when the user turns the pilots head additional rotations for that are applied. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] 3D model origin proposal
Andy Ross [EMAIL PROTECTED] said: It is true that there is an *illusion* that happens when you look at a point far from the aircraft's c.g. which makes the airplane look like it is not rotating correctly. But this is an illusion; what is really happening is that the *viewpoint* is moving. The aircraft motion is correct in all cases. The fix for this issue is either to pick an origin near the c.g. (hard to enforce between FDM(s) and 3D model) or to have the view code explicitly look at the c.g. point instead of the origin (my preference, although it does complicate things a little). That lookat is not a problem...almost got the fix done in my head already. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] 3D model origin proposal
On Mon, 16 Dec 2002 18:41:50 - Jim Wilson [EMAIL PROTECTED] wrote: Yes and no. It should greatly improve the situation as far as keeping the gear above the pavement in an external view. The other issue is the one I described before where it looks odd because the camera tracks the nose as it pitches up and down. That needs to be dealt with in the viewer code. This is exactly the issue: as we all know, the rotations are fine (a rotation is a rotation - the *orientation* of the vehicle always ends up correct). It's the translation issue that is cloudy. I think what we will do (and I think Tony is agreeable to this, and Andy sounds like he'll be able to do this if he is not already) is to provide the lat/lon/alt (LLA) of the nose/prop_hub_tip for the aircraft in our coordinate system. To restate what our coordinate system is: X positive aft Y positive right Z positive up origin - now irrelevant given that we would supply the lat/lon/alt of the NRP (Nose Ref. Pt.). I'm going to have to think for a moment how to supply that. We'll have the LLA of the CG, and we'll have the body to local transform matrix. I guess I can calculate the offset from current CG to NRP and then transform to Local frame and sum with the LLA of the CG. The pilot's view is always kept in sync with the 3D model's rotation (we actually start with the same matrices). Except as I noted above, when the user turns the pilots head additional rotations for that are applied. There probably needs to be a translation there, too. It would not really be noticable except in proximity formation flight or near the ground - but these are important visual cues and they need to be modeled correctly. Perhaps we should provide the pilot eyepoint location (LLA) as well? Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] 3D model origin proposal
On Mon, 16 Dec 2002 14:19:16 -0500 Norman Vine [EMAIL PROTECTED] wrote: Erik Hofman writes: The nose is something that everyone can instantly understand and locate. coughUFO, helicopter, balloon, parachutecough he he :-) Smart a$$e$. ;-) So, where's the bounding box for these items, too? Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] 3D model origin proposal
Tony Peden writes: The point we pick need not have any particular signifigance (we can calculate a lat/lon/alt for anyplace relative to the aircraft), so why should we pick a point which requires explanation and/or instruction on our part and more work on the part of the 3D modeler. The nose is something that everyone can instantly understand and locate. That is not true for the aero ref point, center of gravity, center of geometry, etc. xorig = fuselage length / 2 yorig = wingspan / 2 zorig = highest point / 2 usually top of tail obvious enough for me :-) Main Entry: 1cen·ter Pronunciation: 'sen-tr, 'se-nr Function: noun Etymology: Middle English centre, from Middle French, from Latin centrum, from Greek kentron sharp point, center of a circle, from kentein to prick; probably akin to Old High German hantag pointed Date: 14th century 1 a : the point around which a circle or sphere is described; broadly : a point that is related to a geometrical figure in such a way that for any point on the figure there is another point on the figure such that a straight line joining the two points is bisected by the original point -- called also center of symmetry b : the center of the circle inscribed in a regular polygon Norman audio.gif
Re: [Flightgear-devel] 3D model origin proposal
--- Andy Ross [EMAIL PROTECTED] wrote: Erik Hofman wrote: Jon Berndt wrote: Well, to rotate the aircraft realistically the refference point should be known by the 3D modellers, but that aside. The rigid body rotates about the CG, not the aero ref. pt. Even when in motion? It seems to me there would otherwise be no need for a refference point. That's exactly the point. The reference point is a completely arbitrary choice; it could be 4 light years away (well, with infinite precision floating point) and the math would still work just fine. This is true of the subject 3D model reference point, but not of the JSBSim aero reference point. That point needs to be at least close to the same point used to produce the coefficients you have. The FDMs do the dynamics for you; if you draw the aircraft where they tell you it is, then you will always be drawing physically correct rotations. It is true that there is an *illusion* that happens when you look at a point far from the aircraft's c.g. which makes the airplane look like it is not rotating correctly. But this is an illusion; what is really happening is that the *viewpoint* is moving. The aircraft motion is correct in all cases. The fix for this issue is either to pick an origin near the c.g. (hard to enforce between FDM(s) and 3D model) or to have the view code explicitly look at the c.g. point instead of the origin (my preference, although it does complicate things a little). Andy -- Andrew J. RossNextBus Information Systems Senior Software Engineer Emeryville, CA [EMAIL PROTECTED] http://www.nextbus.com Men go crazy in conflagrations. They only get better one by one. - Sting (misquoted) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel __ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] 3D model origin proposal
--- Norman Vine [EMAIL PROTECTED] wrote: Tony Peden writes: The point we pick need not have any particular signifigance (we can calculate a lat/lon/alt for anyplace relative to the aircraft), so why should we pick a point which requires explanation and/or instruction on our part and more work on the part of the 3D modeler. The nose is something that everyone can instantly understand and locate. That is not true for the aero ref point, center of gravity, center of geometry, etc. xorig = fuselage length / 2 yorig = wingspan / 2 zorig = highest point / 2 usually top of tail obvious enough for me :-) Main Entry: 1cen·ter Pronunciation: 'sen-tr, 'se-nr Function: noun Etymology: Middle English centre, from Middle French, from Latin centrum, from Greek kentron sharp point, center of a circle, from kentein to prick; probably akin to Old High German hantag pointed Date: 14th century 1 a : the point around which a circle or sphere is described; broadly : a point that is related to a geometrical figure in such a way that for any point on the figure there is another point on the figure such that a straight line joining the two points is bisected by the original point -- called also center of symmetry b : the center of the circle inscribed in a regular polygon Norman The equations and associated verbiage prove the point well, I think. ATTACHMENT part 2 image/gif name=audio.gif __ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] 3D model origin proposal
Jon S Berndt [EMAIL PROTECTED] said: This is exactly the issue: as we all know, the rotations are fine (a rotation is a rotation - the *orientation* of the vehicle always ends up correct). It's the translation issue that is cloudy. I think what we will do (and I think Tony is agreeable to this, and Andy sounds like he'll be able to do this if he is not already) is to provide the lat/lon/alt (LLA) of the nose/prop_hub_tip for the aircraft in our coordinate system. To restate what our coordinate system is: X positive aft Y positive right Z positive up Sounds good. The pilot's view is always kept in sync with the 3D model's rotation (we actually start with the same matrices). Except as I noted above, when the user turns the pilots head additional rotations for that are applied. There probably needs to be a translation there, too. It would not really be noticable except in proximity formation flight or near the ground - but these are important visual cues and they need to be modeled correctly. Perhaps we should provide the pilot eyepoint location (LLA) as well? Not sure what visual cues you are looking for. I would be hesitant to do a translation that would have the pilot's head bouncing around the cockpit. Right now the cockpit appears more or less stationary in relation to the pilot's eye. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] 3D model origin proposal
On Mon, 16 Dec 2002 20:17:43 - Jim Wilson [EMAIL PROTECTED] wrote: coordinate system is: X positive aft Y positive right Z positive up Sounds good. Good. Not sure what visual cues you are looking for. I would be hesitant to do a translation that would have the pilot's head bouncing around the cockpit. Right now the cockpit appears more or less stationary in relation to the pilot's eye. This may very well be OK right now. To clarify: When rendering the scene from the pilot eyepoint (inside the cockpit), the view must be correctly rendered so that once touchdown occurs, and the derotation is occurring, the pilot view out the front not only rotates (pitches down), but translates (remember the 747 example I mentioned earlier). The pilot eyepoint is NOT at the CG - which is why we provide it. The visual cue is the translational movement during touchdown when the nose gear descends to the runway. VERY important for large aircraft particularly; the CG doesn't translate in Z much after main gear touchdown, but the cockpit sure will. Again - this may be already being done correctly, but I worry because you say that the pilot eyepoint information is not being used. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] 3D model origin proposal
Norman Vine [EMAIL PROTECTED] said: xorig = fuselage length / 2 What if tail surfaces extend beyond the fueselage? yorig = wingspan / 2 Ok got that. zorig = highest point / 2 usually top of tail Is that with gear up or down? obvious enough for me :-) Main Entry: 1cen·ter Pronunciation: 'sen-tr, 'se-nr Function: noun Etymology: Middle English centre, from Middle French, from Latin centrum, from Greek kentron sharp point, center of a circle, from kentein to prick; probably akin to Old High German hantag pointed Date: 14th century 1 a : the point around which a circle or sphere is described; broadly : a point that is related to a geometrical figure in such a way that for any point on the figure there is another point on the figure such that a straight line joining the two points is bisected by the original point -- called also center of symmetry b : the center of the circle inscribed in a regular polygon 14th century? The aircraft wasn't invented yet. Now I'm really confused! ;-) Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] 3D model origin proposal
Jon S Berndt [EMAIL PROTECTED] said: main gear touchdown, but the cockpit sure will. Again - this may be already being done correctly, but I worry because you say that the pilot eyepoint information is not being used. Ah ok. Yes, that probably is a problem now because we are using the same reference as the model...ie the lon/lat/alt as reported for the CG. If we have just one fixed point of reference, like the nose/hub tip we'll be fine. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] 3D model origin proposal
Jon S Berndt wrote: Well, with proper agreement and reference point, we can make this perfect. There's just some communication and cooperation needed for a little while, and I think we are nearly there. Yes. I think several people are unclear about how this will work, and have concerns like If we make the nose the reference point, then the aircraft will appear to wag because the viewer code doesn't know about the offset. That won't happen if we identify a communication problem within the software and fix it properly. The way I see it is: WHAT TO DO: Wherever an aircraft position* is sent from one part of Flight Gear (e.g. an FDM) to another part (e.g. the part that positions the graphical model in the scene graph), we must define exactly what that position means as part of the definition of the interface function or variable or property, AND ALSO modify the data provider if necessary to ensure that it provides that particular position, and modify the receiver if necessary to ensure that it converts the position it is given into the position that it really wants. (Don't worry about the performance cost of two extra 3D transforms per frame.) Example: - We choose first to tackle the aircraft position reported by FDMs to Flight Gear. - We choose the tip of the nose for that particular interface, and write position of tip of nose in a comment by the declaration, or preferably incorporate NoseTip into the name of the function or variable or property. - In this example Jon would leave most of JSBsim as it is, generating the position of the centre of gravity, but he would add a little function to convert position of C of G to position of nose just before publishing the value to Flight Gear. - Someone would modify the function that updates the Flight Gear scene graph so that it puts the model geometry at the right position, by transforming from position of nose to origin of geometry (which will be different for each aircraft geometry model). Similarly, any other parts of Flight Gear that use this data must be checked and modified if necessary. HOW TO DO IT: We need data for the 3D transforms. Jon would need to know the position of the nose relative to the C of G, and he would probably get this in two or three steps: transform from C of G to the aero reference point, which he knows already; and then transform from the aero reference point to the nose. This relative position will have to be added to the JSBsim config files if it cannot be calculated from data already there. On the other side, putting the geometry into the scene graph at the specified position will involve converting from position of nose to origin of geometry; that transform would need to be read from the geometry file or the aircraft config file. Clearly the reference point for an interface should be one that both sides can reasonably understand. It is likely that it will have to be specified (differently) on both sides of the interface: nose relative to aerodynamic origin, and nose relative to geometry origin. It is not practical to get all FDM authors AND all geometry authors to use the same origin natively. By precisely defining an interface and providing the conversion offsets as data in an appropriate place, we can eliminate the errors. There is no need for arbitrary approximations to occur by design of the Flight Gear program architecture, but approximations may still occur due to lack of data. For example, to avoid having to update all config files at once, we might put in the geometry-reading subsystem something like if this geometry file does not specify the position of the nose, then use the average vertical coordinate and the front-most horizontal coordinate. Then move on to another interface, such as the camera/eye position, and go through the same thing. Where do we want the camera or eye to be (or to be looking towards)? Do we have the information that specifies the eye position relative to a known position? If not, it must be added to the aircraft config file (probable for the eye position) or calculated at run time (possible for a camera look-at point). Perhaps Curt or David M could kick-start the process by defining the meaning of one of those interface functions. You can't ask an FDM author to choose the reference point because they are all biased, and none of us lesser mortals would dare submit a patch for such a wide-reaching change. But if we want to share models across different FDMs then this work will have to be done. * Note that wherever I said position or point I should have said coordinate system or set of axes to include orientation as well, because especially the pitch attitude of an aircraft could easily suffer the same kind of ambiguity. - Julian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Some aircraft crash FlightGear upon startup
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Yesterday I downloaded, compiled, and installed the latest stable FlightGear, 0.9.1. Unfortunately, some of the aircraft do not work. When doing fgfs --aircraft=shuttle, the program dies as soon as soon as the cockpit view starts to pop up. I searched this list, and found some advice someone had given someone else about running the program with gdb and getting a backtrace, and I have done so, and will now present my results. I don't really know how to use the debugger for much, so I'll mention everything I did, just in case: $ gdb ./fgfs (from the directory FlightGear is in, of course; I installed it and some of the libraries it requires in a toplevel /flightgear directory) (gdb) run --aircraft=shuttle ... tons of output that can be supplied if needed... ... Start common FDM init ...initializing position... FGJSBsim::set_Longitude: -2.13556 FGJSBsim::set_Latitude: 0.656448 cur alt (ft) = 0 FGJSBsim::set_Altitude: -0.000431126 lat (deg) = 37.6117 Terrain altitude: -0.00141445 ...initializing ground elevation to -0.000431126ft... ...initializing sea-level radius... lat = 37.6117 alt = -0.000431126 ...initializing velocities... FGJSBsim::set_V_calibrated_kts: 0 ...initializing Euler angles... FGJSBsim::set_Euler_Angles: 0, 0.0074002, 5.19934 End common FDM init Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 1024 (LWP 4089)] SGPropertyNode::getDoubleValue (this=0x0) at props.cxx:1117 1117props.cxx: No such file or directory. in props.cxx (gdb) backtrace #0 SGPropertyNode::getDoubleValue (this=0x0) at props.cxx:1117 #1 0x0822fd3a in FGGain::Run (this=0x9891960) at FGGain.cpp:136 #2 0x0816ecc4 in FGFCS::Run (this=0x90315a0) at FGFCS.cpp:137 #3 0x08180762 in FGFDMExec::Run (this=0x8ddc130) at FGFDMExec.cpp:369 #4 0x081807ca in FGFDMExec::RunIC (this=0x8ddc130) at FGFDMExec.cpp:384 #5 0x08153167 in FGJSBsim::init (this=0x902b578) at JSBSim.cxx:234 #6 0x08050d57 in fgUpdateTimeDepCalcs () at main.cxx:909 #7 0x08051faf in fgMainLoop () at main.cxx:1177 #8 0x40090845 in idleWait () from /usr/lib/libglut.so.3 #9 0x0805700a in main (argc=2, argv=0xb824) at main.cxx:1823 #10 0x403963c1 in __libc_start_main () from /lib/libc.so.6 While I don't really know how to use the debugger, I do know C and C++, and it certainly appeared that SGPropertyNode::getDoubleValue was getting called with a NULL this pointer from FGGain::Run. I looked at the code, and indeed there are two calls to getDoubleValue in Run, both from pointers, so either InputNodes[0] or ScheduledBy is NULL. According to head, line 136 is LookupVal = ScheduledBy-getDoubleValue();, so ScheduledBy would appear to be the culprit to me. But it's not only the shuttle that does this; for example, using --aircraft=X15 results in the exact same output. I don't think these are the only two aircraft that do this either. If there's any more information I can provide or another way for me to be helpful in general, please let me know. Tommy McDaniel -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE9/e3ZVB8FYP9YqDcRAkBeAJwNN30TOcN+mSFDV032VZUDUPiMsgCfS18z RIoCX7oZ1MfVSHvzgIYm6l4= =P9F7 -END PGP SIGNATURE- __ Do you Yahoo!? New DSL Internet Access from SBC Yahoo! http://sbc.yahoo.com ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Scenery not working
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 As I mentioned in another message I just sent to this list, I installed the latest FlightGear yesterday. Of course, I couldn't go long without trying different terrain, and my first try was a piece including southeast Norway. The problem is that, when I try starting FlightGear up in that tile, there is no scenery, it says my coordinates are 0 degrees and 0 degrees, and the plane just doesn't do squat. I can tell the engine to throttle up, but the RPM indicator stays at 0, and the plane just flat doesn't do anything but sit there. Also, there seems to be an infinite number of no terrain intersection messages that begin to be output as soon as the plane is ready to go (if only it worked), interspersed with occassional Failed to remove nav-vor-ident sound messages and a few others. I looked through the list archives, and I found mention from October or so about --lon and --lat having problems, and someone suggesting that it was only the eastern hemisphere that wasn't working, perhaps because FlightGear was parsing coordinates in that hemisphere improperly. I therefore downloaded the terrain tile that includes Orlando, Florida, and lo and behold, it worked like a charm. It was suggested that the problem might be in options.cxx, and I have indeed looked at the file for a few minutes, but can find no particular error. In fact, when I run ./fgfs --lon=11 --lat=59 2 /dev/null from the directory FlightGear is in the very first output is: parse_time() = 11 parse_time() = 11 parse_time() = 59 parse_time() = 59 which seems to correspond to the coordinates I have entered. Perhaps someone that knows which variables to follow (and knows how to use the debugger, which I don't) can check out what's going on here. I have plenty of output messages that I can present if needed, but I doubt that they will be helpful. If there's anything I can do to help out here and restore half of the world to FlightGear (assuming that's what the problem is), just let me know. I know C and C++, for what it matters. Tommy McDaniel -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE9/fcyVB8FYP9YqDcRAre8AJ0R57OTsWO8lt6i1p3d6MIe+nlDYACffMV9 481jT9li4U0WEFfjxo18LC4= =Z9ph -END PGP SIGNATURE- __ Do you Yahoo!? New DSL Internet Access from SBC Yahoo! http://sbc.yahoo.com ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: [Flightgear-cvslogs] CVS: www/Docs/InstallGuidegetstart.html,1.1.1.1,1.2 getstart.pdf,1.1.1.1,1.2getstartap1.html,1.1.1.1,1.2 getstartap2.html,1.1.1.1,1.2getstartap3.html,1.1.1.1,1.2 getstartch1.html,1.1.1.1,1.2getstartch2.html,1.1.1.1,1.2 getstartch3.html,1.1.1.1,1.2getstartch4.html,1.1.1.1,1.2 getstartch5.html,1.1.1.1,1.2getstartli1.html,1.1.1.1,1.2 getstartli2.html,1.1.1.1,1.2getstartli3.html,1.1.1.1,1.2 getstartpa1.html,1.1.1.1,1.2getstartpa2.html,1.1.1.1,1.2 getstartpa3.html,1.1.1.1,1.2
Curtis L. Olson wrote: Update of /var/cvs/FlightGear-0.9/www/Docs/InstallGuide In directory seneca:/tmp/cvs-serv28258 Modified Files: getstart.html getstart.pdf getstartap1.html getstartap2.html getstartap3.html getstartch1.html getstartch2.html getstartch3.html getstartch4.html getstartch5.html getstartli1.html getstartli2.html getstartli3.html getstartpa1.html getstartpa2.html getstartpa3.html Log Message: Updates from Michael to slightly obfuscate email addresses. Well, I think even addresses like something @ something.com aren't save against spammers. So far the best recepie is to convert the address to little pixel graphics and to include the images on the page. CU, Christian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Scenery not working
Tommy, Here's a couple things you could try. - specify a starting airport: fgfs --airport=ENTC We have quite a few Norwegian airports in our database. - If you want to specify a lat/lon try avoiding exact whole number coordinates. Instead of --lat=59 --lon=10 try --lat=59.001 --lon=10.001 (or better yet, start at an aiport.) Regards, Curt. Tommy McDaniel writes: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 As I mentioned in another message I just sent to this list, I installed the latest FlightGear yesterday. Of course, I couldn't go long without trying different terrain, and my first try was a piece including southeast Norway. The problem is that, when I try starting FlightGear up in that tile, there is no scenery, it says my coordinates are 0 degrees and 0 degrees, and the plane just doesn't do squat. I can tell the engine to throttle up, but the RPM indicator stays at 0, and the plane just flat doesn't do anything but sit there. Also, there seems to be an infinite number of no terrain intersection messages that begin to be output as soon as the plane is ready to go (if only it worked), interspersed with occassional Failed to remove nav-vor-ident sound messages and a few others. I looked through the list archives, and I found mention from October or so about --lon and --lat having problems, and someone suggesting that it was only the eastern hemisphere that wasn't working, perhaps because FlightGear was parsing coordinates in that hemisphere improperly. I therefore downloaded the terrain tile that includes Orlando, Florida, and lo and behold, it worked like a charm. It was suggested that the problem might be in options.cxx, and I have indeed looked at the file for a few minutes, but can find no particular error. In fact, when I run ./fgfs --lon=11 --lat=59 2 /dev/null from the directory FlightGear is in the very first output is: parse_time() = 11 parse_time() = 11 parse_time() = 59 parse_time() = 59 which seems to correspond to the coordinates I have entered. Perhaps someone that knows which variables to follow (and knows how to use the debugger, which I don't) can check out what's going on here. I have plenty of output messages that I can present if needed, but I doubt that they will be helpful. If there's anything I can do to help out here and restore half of the world to FlightGear (assuming that's what the problem is), just let me know. I know C and C++, for what it matters. Tommy McDaniel -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE9/fcyVB8FYP9YqDcRAre8AJ0R57OTsWO8lt6i1p3d6MIe+nlDYACffMV9 481jT9li4U0WEFfjxo18LC4= =Z9ph -END PGP SIGNATURE- __ Do you Yahoo!? New DSL Internet Access from SBC Yahoo! http://sbc.yahoo.com ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] 3D model origin proposal
On Mon, 2002-12-16 at 07:24, Jon Berndt wrote: FWIW, I still think the location should be configurable by the 3D modeler in the FG xml files. FG would pass that info to the FDM and it would return the appropriate position or FG would do the calcs itself. The wind doesn't seem to be blowing that way, however ... Actually, I thought of that too and it seems like a good idea. That is, that the 3D model asks for the lat/lon/alt of a specific point on the aircraft. This is probably the most configurable and versatile way to go. However ... which point does the FGFS side ask for the position of? I would assume they would ask for the point of origin of the 3D model (perhaps the nose, perhaps the firewall, perhaps the center of bounding box). When the FGFS side asks us (FDM) for a position, how do we know where that position lies in our frame of reference? Point taken, you still have the relative to what? problem. When I think about this for long enough, I keep coming back to this: that if the nose is taken to be a common reference point between the FDM and the 3D model, then we (FDM) can simply provide the location of the Nose Reference Point (NRP) and the FGFS side can use that to properly place the vehicle. Now, the nose may not be the origin of the 3D model, but the NRP will be known relative to the 3D model origin. So, the FGFS side will be able to bias or offset the point we return and still place the model correctly in the scene. My $0.03. Jon -- Tony Peden [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] 3D model origin proposal
Julian Foad [EMAIL PROTECTED] said: - Someone would modify the function that updates the Flight Gear scene graph so that it puts the model geometry at the right position, by transforming from position of nose to origin of geometry (which will be different for each aircraft geometry model). Already done. See: http://www.flightgear.org/Docs/fgfs-model-howto.html#repositioning BTW the origin of geometry doesn't _have_ to be different. In some cases we'll offset because the model will already be done, and in other cases it might just be easier to work on if the origin is more or less centered. Similarly, any other parts of Flight Gear that use this data must be checked and modified if necessary. Like? Then move on to another interface, such as the camera/eye position, and go through the same thing. Where do we want the camera or eye to be (or to be looking towards)? Do we have the information that specifies the eye position relative to a known position? If not, it must be added to the aircraft config file (probable for the eye position) or calculated at run time (possible for a camera look-at point). We need to be able to offset the target in look-at mode. Currently you can only offset the camera (eye) from a position. It's a fairly trivial modification and addition to the viewer interface. Each aircraft configuration (the flight gear one, not the fdm's) currently has a pilot's eye configuration, this modification will add data for offsets to the chase view that won't really change anything other than eliminating the wagging effect and maybe centering the aircraft in the view. http://www.flightgear.org/Docs/fgfs-viewer-howto.html#offsets Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Some aircraft crash FlightGear uponstartup
On Mon, 16 Dec 2002 07:19:33 -0800 (PST) Tommy McDaniel [EMAIL PROTECTED] wrote: Yes, this is a recently discovered bug, and I have just now discovered the problem. Tony will have the solution. I hope. I'll discuss it on the JSBSim-devel list. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] 3D model origin proposal
On Mon, 2002-12-16 at 10:26, Erik Hofman wrote: Tony Peden wrote: --- Erik Hofman [EMAIL PROTECTED] wrote: Jon Berndt wrote: Well, to rotate the aircraft realistically the refference point should be known by the 3D modellers, but that aside. The rigid body rotates about the CG, not the aero ref. pt. Even when in motion? In the FDM's (all of them, AFAIK), yes. Always. In reality, the aircraft will rotate about the cg in air and some other point if any of the gear are touching the ground. During takeoff rotation and landing de-rotation, for example, the aircraft will rotate about the main gear. This confuses me a bit. My gut feeling tels me that the lift generated on the various parts of the aircraft (fuselage included) would concentrate the aircrafts rotation around its aero reff. point instead of CG. Or is this the part where the moving CG comes in place? No, think about the geometry of the situation. The gear can't go down and won't go up prior to liftoff. So aside from some possible changes in tire compression, the wheel axles do not translate up or down during the rotation or de-rotation. Another way to think about it may be in terms of a lever. The main gear act as the fulcrum about which the tail must produce/relieve enough force to rotate/de-rotate the aircraft. Erik ___ 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] Re: [Flightgear-cvslogs] CVS: www/Docs/InstallGuide getstart.html
Chrisitan, Well, I think even addresses like something @ something.com aren't save against spammers. I guessed it. So far the best recepie is to convert the address to little pixel graphics and to include the images on the page. ...which 100 or so graphics you are going to create...? ... and to maintain...? I am open for constructive ideas, though, which (a) should be able to implement via LaTeX without manual postediting of the HTML code (b) simple to implement and maintain. Regards, Michael -- Michael Basler, Jena, Germany [EMAIL PROTECTED] http://www.geocities.com/pmb.geo/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: www/Docs/InstallGuide getstart.html
Christian, Including images in LaTeX is no problem - that just leaves us with the problem how we are generating the images... Exactly. Although the HTML converter might become a bit slow with 100+ pix. Perhaps no serious problem. I'm sure that one of the Unix gurus knows a fast way to do that with a command line utility... In this case I'd sure co-operate. But still: Adresses have to be maintained. PS: Could the math mode in LaTeX perhaps help? Or does it translate to an ordinary italic when the stff written in it is simple? I tried this. It was still recognizable after conversion in the HTML. I simply searched for my address (Ctrl-GF in IE) and it was found :-( I tried several font changes etc. which all did not hide the address. A clever sign for/aft the @ being invisible but masking the address might help, too. Regards, Michael -- Michael Basler, Jena, Germany [EMAIL PROTECTED] http://www.geocities.com/pmb.geo/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: www/Docs/InstallGuide getstart.html
Michael Basler writes: Chrisitan, Well, I think even addresses like something @ something.com aren't save against spammers. I guessed it. So far the best recepie is to convert the address to little pixel graphics and to include the images on the page. ...which 100 or so graphics you are going to create...? ... and to maintain...? I am open for constructive ideas, though, which (a) should be able to implement via LaTeX without manual postediting of the HTML code (b) simple to implement and maintain. Michael, Could you fake something as an equation: $ curt\@flightgear.org $ latex2html would convert this to a graphic automatically ... although in equation mode you have to worry about things getting interpreted as equations and variables ... Curt. -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: www/Docs/InstallGuide getstart.html
Curt, Could you fake something as an equation: $ curt\@flightgear.org $ latex2html would convert this to a graphic automatically ... although in equation mode you have to worry about things getting interpreted as equations and variables ... Yes, latex2html does, but tex4ht which I use does not, at least not for simple one-liners (which some consider an advantage). I might look into the options if there's something hidden or if I can trick it into creating gifs. It does for square roots and more complicated stuff. The idea looks pretty indeed. I'll keep it, and when I'll find some time I'll try once more to get latex2html running under MiKTeX (it is possible, just non-trivial) or might even consider switching to fptex which is sort of tetex for windows, which has some flaws, too, but comes with a pre-installed latex2html (which last switch might be non-trivial as I need LaTeX for some business stuff, though). BTW, this problem does concern all addresses somewhere on the FlightGear pages... Thanks, Michael -- Michael Basler, Jena, Germany [EMAIL PROTECTED] http://www.geocities.com/pmb.geo/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Scenery not working
I have a similar problem with KSJC. I'm running fgfs 0.91, with the 0.90 base package, the KSJC photo-realistic scenery version 2.0, and lots of scenery for the northern part of the western hemisphere. It appears that I'm underground. The altimeter reads 0, but the radar altimeter reads something a little over 32800 feet. The aircraft is still stuck, even if I supply a --altitude=3 parameter. I can use the autopilot to fly to KSJC, though, without trouble if I start at another airport. I didn't submit this yet because my mix of versions could conceivably cause odd behavior, and I haven't looked into it. -Luke On Mon, 2002-12-16 at 18:18, Curtis L. Olson wrote: Tommy, Here's a couple things you could try. - specify a starting airport: fgfs --airport=ENTC We have quite a few Norwegian airports in our database. - If you want to specify a lat/lon try avoiding exact whole number coordinates. Instead of --lat=59 --lon=10 try --lat=59.001 --lon=10.001 (or better yet, start at an aiport.) Regards, Curt. Tommy McDaniel writes: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 As I mentioned in another message I just sent to this list, I installed the latest FlightGear yesterday. Of course, I couldn't go long without trying different terrain, and my first try was a piece including southeast Norway. The problem is that, when I try starting FlightGear up in that tile, there is no scenery, it says my coordinates are 0 degrees and 0 degrees, and the plane just doesn't do squat. I can tell the engine to throttle up, but the RPM indicator stays at 0, and the plane just flat doesn't do anything but sit there. Also, there seems to be an infinite number of no terrain intersection messages that begin to be output as soon as the plane is ready to go (if only it worked), interspersed with occassional Failed to remove nav-vor-ident sound messages and a few others. I looked through the list archives, and I found mention from October or so about --lon and --lat having problems, and someone suggesting that it was only the eastern hemisphere that wasn't working, perhaps because FlightGear was parsing coordinates in that hemisphere improperly. I therefore downloaded the terrain tile that includes Orlando, Florida, and lo and behold, it worked like a charm. It was suggested that the problem might be in options.cxx, and I have indeed looked at the file for a few minutes, but can find no particular error. In fact, when I run ./fgfs --lon=11 --lat=59 2 /dev/null from the directory FlightGear is in the very first output is: parse_time() = 11 parse_time() = 11 parse_time() = 59 parse_time() = 59 which seems to correspond to the coordinates I have entered. Perhaps someone that knows which variables to follow (and knows how to use the debugger, which I don't) can check out what's going on here. I have plenty of output messages that I can present if needed, but I doubt that they will be helpful. If there's anything I can do to help out here and restore half of the world to FlightGear (assuming that's what the problem is), just let me know. I know C and C++, for what it matters. Tommy McDaniel -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE9/fcyVB8FYP9YqDcRAre8AJ0R57OTsWO8lt6i1p3d6MIe+nlDYACffMV9 481jT9li4U0WEFfjxo18LC4= =Z9ph -END PGP SIGNATURE- __ Do you Yahoo!? New DSL Internet Access from SBC Yahoo! http://sbc.yahoo.com ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel -- Luke Scharf, Jack of Several Trades http://www.ccm.ece.vt.edu/~lscharf ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Scenery not working
I have a similar problem with KSJC. I'm running fgfs 0.91, with the 0.90 base package, the KSJC photo-realistic scenery version 2.0, and lots of scenery for the northern part of the western hemisphere. It appears that I'm underground. The altimeter reads 0, but the radar altimeter reads something a little over 32800 feet. The aircraft is still stuck, even if I supply a --altitude=3 parameter. I can use the autopilot to fly to KSJC, though, without trouble if I start at another airport. I didn't submit this yet because my mix of versions could conceivably cause odd behavior, and I haven't looked into it. -Luke On Mon, 2002-12-16 at 18:18, Curtis L. Olson wrote: Tommy, Here's a couple things you could try. - specify a starting airport: fgfs --airport=ENTC We have quite a few Norwegian airports in our database. - If you want to specify a lat/lon try avoiding exact whole number coordinates. Instead of --lat=59 --lon=10 try --lat=59.001 --lon=10.001 (or better yet, start at an aiport.) Regards, Curt. Tommy McDaniel writes: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 As I mentioned in another message I just sent to this list, I installed the latest FlightGear yesterday. Of course, I couldn't go long without trying different terrain, and my first try was a piece including southeast Norway. The problem is that, when I try starting FlightGear up in that tile, there is no scenery, it says my coordinates are 0 degrees and 0 degrees, and the plane just doesn't do squat. I can tell the engine to throttle up, but the RPM indicator stays at 0, and the plane just flat doesn't do anything but sit there. Also, there seems to be an infinite number of no terrain intersection messages that begin to be output as soon as the plane is ready to go (if only it worked), interspersed with occassional Failed to remove nav-vor-ident sound messages and a few others. I looked through the list archives, and I found mention from October or so about --lon and --lat having problems, and someone suggesting that it was only the eastern hemisphere that wasn't working, perhaps because FlightGear was parsing coordinates in that hemisphere improperly. I therefore downloaded the terrain tile that includes Orlando, Florida, and lo and behold, it worked like a charm. It was suggested that the problem might be in options.cxx, and I have indeed looked at the file for a few minutes, but can find no particular error. In fact, when I run ./fgfs --lon=11 --lat=59 2 /dev/null from the directory FlightGear is in the very first output is: parse_time() = 11 parse_time() = 11 parse_time() = 59 parse_time() = 59 which seems to correspond to the coordinates I have entered. Perhaps someone that knows which variables to follow (and knows how to use the debugger, which I don't) can check out what's going on here. I have plenty of output messages that I can present if needed, but I doubt that they will be helpful. If there's anything I can do to help out here and restore half of the world to FlightGear (assuming that's what the problem is), just let me know. I know C and C++, for what it matters. Tommy McDaniel -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE9/fcyVB8FYP9YqDcRAre8AJ0R57OTsWO8lt6i1p3d6MIe+nlDYACffMV9 481jT9li4U0WEFfjxo18LC4= =Z9ph -END PGP SIGNATURE- __ Do you Yahoo!? New DSL Internet Access from SBC Yahoo! http://sbc.yahoo.com ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel -- Luke Scharf, Jack of Several Trades http://www.ccm.ece.vt.edu/~lscharf ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Scenery not working
I have a similar problem with KSJC. I'm running fgfs 0.91, with the 0.90 base package, the KSJC photo-realistic scenery version 2.0, and lots of scenery for the northern part of the western hemisphere. It appears that I'm underground. The altimeter reads 0, but the radar altimeter reads something a little over 32800 feet. The aircraft is still stuck, even if I supply a --altitude=3 parameter. I can use the autopilot to fly to KSJC, though, without trouble if I start at another airport. I didn't submit this yet because my mix of versions could conceivably cause odd behavior, and I haven't looked into it. -Luke On Mon, 2002-12-16 at 18:18, Curtis L. Olson wrote: Tommy, Here's a couple things you could try. - specify a starting airport: fgfs --airport=ENTC We have quite a few Norwegian airports in our database. - If you want to specify a lat/lon try avoiding exact whole number coordinates. Instead of --lat=59 --lon=10 try --lat=59.001 --lon=10.001 (or better yet, start at an aiport.) Regards, Curt. Tommy McDaniel writes: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 As I mentioned in another message I just sent to this list, I installed the latest FlightGear yesterday. Of course, I couldn't go long without trying different terrain, and my first try was a piece including southeast Norway. The problem is that, when I try starting FlightGear up in that tile, there is no scenery, it says my coordinates are 0 degrees and 0 degrees, and the plane just doesn't do squat. I can tell the engine to throttle up, but the RPM indicator stays at 0, and the plane just flat doesn't do anything but sit there. Also, there seems to be an infinite number of no terrain intersection messages that begin to be output as soon as the plane is ready to go (if only it worked), interspersed with occassional Failed to remove nav-vor-ident sound messages and a few others. I looked through the list archives, and I found mention from October or so about --lon and --lat having problems, and someone suggesting that it was only the eastern hemisphere that wasn't working, perhaps because FlightGear was parsing coordinates in that hemisphere improperly. I therefore downloaded the terrain tile that includes Orlando, Florida, and lo and behold, it worked like a charm. It was suggested that the problem might be in options.cxx, and I have indeed looked at the file for a few minutes, but can find no particular error. In fact, when I run ./fgfs --lon=11 --lat=59 2 /dev/null from the directory FlightGear is in the very first output is: parse_time() = 11 parse_time() = 11 parse_time() = 59 parse_time() = 59 which seems to correspond to the coordinates I have entered. Perhaps someone that knows which variables to follow (and knows how to use the debugger, which I don't) can check out what's going on here. I have plenty of output messages that I can present if needed, but I doubt that they will be helpful. If there's anything I can do to help out here and restore half of the world to FlightGear (assuming that's what the problem is), just let me know. I know C and C++, for what it matters. Tommy McDaniel -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE9/fcyVB8FYP9YqDcRAre8AJ0R57OTsWO8lt6i1p3d6MIe+nlDYACffMV9 481jT9li4U0WEFfjxo18LC4= =Z9ph -END PGP SIGNATURE- __ Do you Yahoo!? New DSL Internet Access from SBC Yahoo! http://sbc.yahoo.com ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel -- Luke Scharf, Jack of Several Trades http://www.ccm.ece.vt.edu/~lscharf ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
