Re: [Flightgear-devel] waves white flag
Jon Berndt wrote: I give up. Sort of. No need to IMHO. I think we now have an excellent solution. Could someone file a patent request for this? There are some gotcha's involved which could mean some other points/locations should be exposed also in the future, but that's about it. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] waves white flag
Mathias Fröhlich wwrites: On Sonntag, 15. Februar 2004 10:49, Erik Hofman wrote: Jon Berndt wrote: I give up. Sort of. I hope you don't! No need to IMHO. I think we now have an excellent solution. Could someone file a patent request for this? There are some gotcha's involved which could mean some other points/locations should be exposed also in the future, but that's about it. And even then, JSBSim is now able to satisfy *every* request in that direction. I also did not understand why this simple feature is such a big question! The main remaining problem is that the rest of the subsystems have yet to take this adjustment into account also. Also from my reading of the current Model code it appears as if the absolute positioning of an aircraft with the world will be *very* dependent on the designer's choice of the VRP and I am also not sure if just with this addition the current code will fix the 'issue' that prompted the incarnation of this thread again. i.e. the aircraft appears to be rotating about the nose But since this is an abstract thing it is good to have a 'public' thrashing so all can gain an understanding of the issues involved please note this is non-trivial to most and not just a simple feature request which has far reaching consequences on the very 'core' of most everything within the SIM so to outline what I have gleaned so far 1) the 'modellers' coordinate frame will be [ X ] longitudinal increasing aft i.e. smallest at the nose [ Y ] latitudinal increasing righti.e. smallest at the left wing tip [ Z ] verticalincreasing up i.e. smallest at the ground 2) within this frame a VRP virtual refrence point will be designated to represent the origin of the coordinate frame with respect to the 'tip' of the nose of the aircraft. 3) The SSG will assume a 'similar frame' but keep in mind that the Object.getBSphere()-getCenter() will return the point that is 'magically' computed to be at the center of the 'Geomettry' when passed to SSG at Object creation time. Most likely this will not be the VRP and in any case can *not* be assumed to be, and is . IMPORTANT: This *is* the point ultimately used by the Rendering Engine from which any rotation and / or translation is derived. 4) The FDM will compute the center of 'Gravity' WRT to the frame and pass it's offset WRT to the VRP back to FGFS. note this is not and thus can *not* be assumed to be the same as the center of 'Geometry' that will be used by the Rendering Engine. 5) AFAICT FGFS will then reposition the AirCraft using the offset provided by the FDM and rotate the AirCraft to align itself with the orientation. Here is where I get confused and ... I am probably missing the obvious but nowhere in the above is the offset from the possibly corrected VRP WRT the Object.getBSphere()-getCenter() accounted for ?? Also I can not find in the code the mechanism that will rotate the AirCraft about any point other then the point returned by Object.getBSphere()-getCenter() as adjusted by the translation WRT the VRP which appears to be set at Model load time from the OffSet from the nose and not the Geometrical center about which rotations will occur. In order for this to occur you need two complimentary translations. One before and one after the rotation. Also there is this issue about where exactly the [ lat, lon. alt ] reported back from the FDM each cycle refers to that is yet to be decided Again I am probably missing the obvious here and should just go back to lurking so Erik doesn't start ignoring my posts too :-) HTH Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] waves white flag
On Sonntag, 15. Februar 2004 16:08, Norman Vine wrote: i.e. the aircraft appears to be rotating about the nose No, it does not rotate around the nose since the reported position is corrected by just that amount that is required to rotate around the correct axis. This is just a thing of proper coordinate system transforms at the right place. But since this is an abstract thing it is good to have a 'public' thrashing so all can gain an understanding of the issues involved please note this is non-trivial to most and not just a simple feature request which has far reaching consequences on the very 'core' of most everything within the SIM Ok, sorry! so to outline what I have gleaned so far 1) the 'modellers' coordinate frame will be [ X ] longitudinal increasing aft i.e. smallest at the nose [ Y ] latitudinal increasing righti.e. smallest at the left wing tip [ Z ] verticalincreasing up i.e. smallest at the ground JSBSim calls that the 'reference frame' since this seems to be the most often used representation in aircraft industry for construction drawings. I am at the moment not shure if a visual model (in ac3d for example) uses also this conventions. 2) within this frame a VRP virtual refrence point will be designated to represent the origin of the coordinate frame with respect to the 'tip' of the nose of the aircraft. No need for a nose tip of an aircraft at this time of an explanation. This visual reference point is just an arbitrary fixed location in this reference frame. In a JSBSim configuration file this one is also stored as a cordinate value inside this reference frame. And yes, if somone likes to have this visual reference point at the nosetip he can put it there. But you can equally well place it at any other fixed (fixed with respect to the reference frame) point in or outside the aircraft as long as you either place the origin of your visual model (ac3d/mdl/whatever file) at this fixed point. Alternativly you can correct this origin later by these offset values in the visual models xml file. 3) The SSG will assume a 'similar frame' but keep in mind that the Object.getBSphere()-getCenter() will return the point that is 'magically' computed to be at the center of the 'Geomettry' when passed to SSG at Object creation time. Most likely this will not be the VRP and in any case can *not* be assumed to be, and is . IMPORTANT: This *is* the point ultimately used by the Rendering Engine from which any rotation and / or translation is derived. I assume SSG is simple scene graph. Right? I am not really familiar with the code inside flightgear/plib here. So I may omit some things here. It is a requirement for the modeller to match the VRP configured in JSBSim with the origin of the ac3d file after applying the offsets from the xml file used to load/animate this ac3d file. When this matches the reported position/orientation is exactly that required for the getCenter() value of the aircraft model. 4) The FDM will compute the center of 'Gravity' WRT to the frame and pass it's offset WRT to the VRP back to FGFS. note this is not and thus can *not* be assumed to be the same as the center of 'Geometry' that will be used by the Rendering Engine. Hmm, no. Simply no. The FDM traces the center of gravity in the earth frame. I call this the dynamic center of gravity, because this one is not fixed in the reference frame due to fuel loss and such. JSBSim also traces the location of the dynamic center of gravity inside the reference frame. Now, when you know where the dynamic center of gravity is located in the earth frame (lat/lon/h) and you know where the dynamic center of gravity is in the reference frame, you can compute the location of the visual reference point in the earth frame. Of course you will also need the aircraft orientation for this computation. Then this visual reference point is reported to flightgear and plib uses this to draw the aircraft model on your screen. 5) AFAICT FGFS will then reposition the AirCraft using the offset provided by the FDM and rotate the AirCraft to align itself with the orientation. Yes. Here is where I get confused and ... I am probably missing the obvious but nowhere in the above is the offset from the possibly corrected VRP WRT the Object.getBSphere()-getCenter() accounted for ?? I don't completly understand what you mean here. If your configured JSBSim VRP matches the origin of the ac3d file everything fits. Does this help? Also I can not find in the code the mechanism that will rotate the AirCraft about any point other then the point returned by Object.getBSphere()-getCenter() as adjusted by the translation WRT the VRP which appears to be set at Model load time from the OffSet from the nose and not the Geometrical center about which rotations will occur. In order for this to occur you need two complimentary
RE: [Flightgear-devel] waves white flag
JSBSim calls that the 'reference frame' since this seems to be structural frame, actually. This stuff needs to be compiled into a comprehensible FAQ or document on Coordinate Systems Used, etc. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] waves white flag
On Sonntag, 15. Februar 2004 17:47, Jon Berndt wrote: JSBSim calls that the 'reference frame' since this seems to be structural frame, actually. Sorry, not the first time I called it reference frame. It seems to be burned in my head with the wrong name... Sure, it is called structural frame! This stuff needs to be compiled into a comprehensible FAQ or document on Coordinate Systems Used, etc. You have already a document about these frames. Can you incorporate? Greetings Mathias -- Mathias Fröhlich, email: [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] waves white flag
You have already a document about these frames. Can you incorporate? That's right. I forgot. I should. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] waves white flag
Mathias Fröhlich writes: Norman Vine wrote: Also I can not find in the code the mechanism that will rotate the AirCraft about any point other then the point returned by Object.getBSphere()-getCenter() as adjusted by the translation WRT the VRP which appears to be set at Model load time from the OffSet from the nose and not the Geometrical center about which rotations will occur. In order for this to occur you need two complimentary translations. One before and one after the rotation. You don't need to rotate around an other axis. I will make an example. Assume you will have an aircraft ac3d file whos origin is at tho nose tip. (REALLY JUST FOR EXAMPLE) Assume you have also configured the visual reference point equal to the nose tip. Assume the dynamic center of gravity does not move relative to the earth. Then, when the aircraft pitches the nose downwards around this dynamic center of gravity this pitching angle is reported to flightgear _and_ the reported location of the visual reference point (the nose tip in this case) moves downward. In effect the model rotates around the dynamic center of gravity. Simply stated the problem is that inorder to rotate an object about an arbritrary point you *must* do the equivalaent of the following 1) translate object so that it's 'rotation point' is at the 'point of rotation' 2) rotate the object 3) translate the object to it's 'desired' position this may not be it's original position depending on a) the 'coordinate frame' the object is described in which very likely is the case with an arbritrary VRP b) if the coordinate frame is dynamically changing as is the case with aerodynamic forces and gravity determining the 'frame' in a sophisticated FDM HTH Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] waves white flag
Jon Berndt writes:
Could this be solved if the camera viewpoint looked at the CG instead of
the VRP? What is being done, now?
The camera viewpoint need not necessarily be either or any fixed point
i.e. the camera should be free to look around :-)
What is required is that the 'center of rotation' of the aircraft is
about the proper point.
But since this is an abstract thing it is good to have a 'public'
thrashing so all can gain an understanding of the issues involved
please note this is non-trivial to most and not just a simple
feature request which has far reaching consequences on the very
'core' of most everything within the SIM
Definitely.
so to outline what I have gleaned so far
1) the 'modellers' coordinate frame will be
[ X ] longitudinal increasing aft i.e. smallest at the nose
[ Y ] latitudinal increasing righti.e. smallest
at the left wing tip
[ Z ] verticalincreasing up i.e. smallest
at the ground
This is definitely my strong preference, but can even this be adusted with
the offsets?
Yes this could be adjusted, probably easiest todo with a single matrix,
as is done with the conversion between SSG space and OpenGL space
ie in SSG space X is to the right, Y is away from the viewer, Z is up
and in OpenGL X is to right, Y is up, and Z is into the screen
and is conversion is accomplished by inserting the
sgMat4 _ssgOpenGLAxisSwapMatrix =
{
{ 1.0f, 0.0f, 0.0f, 0.0f },
{ 0.0f, 0.0f, -1.0f, 0.0f },
{ 0.0f, 1.0f, 0.0f, 0.0f },
{ 0.0f, 0.0f, 0.0f, 1.0f }
} ;
into the viewer pipeline, but do we want or need this extra flexibility
I think it best if we all just agree that this is the coordinate system
that will be used :-)
2) within this frame a VRP virtual refrence point will be designated
to represent the origin of the coordinate frame with respect to the
'tip' of the nose of the aircraft.
The VRP represents the location that the FDM reports the lat/lon/alt of,
since it is a comprehensible (by all parties) fixed point.
It was my understanding that the VRP was decided by the modeller,
most often for ease of 'modelling' and not for any 'physically based'
reasons. IMO we want a 'consistant' position on the frame to be the
reported [ lat, lon, alt ] location. I would argue that the position returned
by Object.getBsphere-getCenter() is the 'logical' choice for this as
it will make other parts of the SIM easier read more direct to keep in
sync, of course any location shift can be compensated for.
The rendering code is beyond me ...
The rendering code is no different WRT to the 'meaning' of the
various 'reference' points then the code the FDM needs to use
to place the objects appropriately into the 'world' with the added
complexity of merging the coordinate frames.
Cheers
Norman
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] waves white flag
On Sonntag, 15. Februar 2004 18:39, Norman Vine wrote: Simply stated the problem is that inorder to rotate an object about an arbritrary point you *must* do the equivalaent of the following 1) translate object so that it's 'rotation point' is at the 'point of rotation' 2) rotate the object 3) translate the object to it's 'desired' position this may not be it's original position depending on a) the 'coordinate frame' the object is described in which very likely is the case with an arbritrary VRP b) if the coordinate frame is dynamically changing as is the case with aerodynamic forces and gravity determining the 'frame' in a sophisticated FDM I don't see a problem. You can view at this in an other way. The visual reference point introduces an additional frame to the FDM. This addinitonal frame has axis looking into the direction of the structural frames axis and has its origin in the visual reference point relative to the structural frame. I will call it now visual reference frame. I hope that you agree that a FDM must be able to trace - the orientation the structural frame relative to the earth - the position of arbitrary points inside the structural frame Also a FDM must be able to translate the coordinate values in one frame to the coordinate values of an other frame. Then you are done. What you need to report to flightgear is the orientation and position of the visual reference frame relative to the earth fixed frame (lat/lon/h + angles). And all required 'corrections' that the model does not rotate around the nose but around the dynamic center of gravity are automatically included. Greetings Mathias -- Mathias Fröhlich, email: [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] waves white flag
Jon Berndt writes: Could this be solved if the camera viewpoint looked at the CG instead of the VRP? What is being done, now? The camera viewpoint need not necessarily be either or any fixed point i.e. the camera should be free to look around :-) What is required is that the 'center of rotation' of the aircraft is about the proper point. I used to think this way, but now I am very suspicious. EVEN IF the aircraft is properly rotating about its CG in world space (like it really would, physically) -- regardless of the method we use to implement that rotation (i.e. using the VRP achieves the same end result: rotation about the CG) ... EVEN IF the aircraft is correctly rotating about its CG, what does it LOOK LIKE it is doing if the camera is pointing AT the aircraft VRP (nose) AND if that look at point is kept centered in the view? I suspect that in this case, it will LOOK LIKE the aircraft is rotating about its nose. Its the same idea, in reverse, that lead us to create the VRP for actual aircraft rotations. What if the view instead is aimed so the look at point is the aircraft CG? Maybe this is the case now, already, and I am guessing off-target? Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] waves white flag
Mathias Fröhlich writes: What you need to report to flightgear is the orientation and position of the visual reference frame relative to the earth fixed frame (lat/lon/h + angles). Agreed And all required 'corrections' that the model does not rotate around the nose but around the dynamic center of gravity are automatically included. Please reread my earlier post on necessary steps for rotating an object about an arbritrary point. Cheers Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] waves white flag
Norman Vine wrote: Mathias Fröhlich writes: Norman Vine wrote: Also I can not find in the code the mechanism that will rotate the AirCraft about any point other then the point returned by Object.getBSphere()-getCenter() as adjusted by the translation WRT the VRP which appears to be set at Model load time from the OffSet from the nose and not the Geometrical center about which rotations will occur. In order for this to occur you need two complimentary translations. One before and one after the rotation. You don't need to rotate around an other axis. I will make an example. Assume you will have an aircraft ac3d file whos origin is at tho nose tip. (REALLY JUST FOR EXAMPLE) Assume you have also configured the visual reference point equal to the nose tip. Assume the dynamic center of gravity does not move relative to the earth. Then, when the aircraft pitches the nose downwards around this dynamic center of gravity this pitching angle is reported to flightgear _and_ the reported location of the visual reference point (the nose tip in this case) moves downward. In effect the model rotates around the dynamic center of gravity. Simply stated the problem is that inorder to rotate an object about an arbritrary point you *must* do the equivalaent of the following 1) translate object so that it's 'rotation point' is at the 'point of rotation' 2) rotate the object 3) translate the object to it's 'desired' position this may not be it's original position depending on a) the 'coordinate frame' the object is described in which very likely is the case with an arbritrary VRP b) if the coordinate frame is dynamically changing as is the case with aerodynamic forces and gravity determining the 'frame' in a sophisticated FDM The first item doesn't need to be done per-frame. It can be done once and remembered. -- Russ Conway's Law: The structure of a system tends to mirror the structure of the group producing it. -- Mel Conway Datamation (1968) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] waves white flag
Norman Vine wrote: Mathias Fröhlich wwrites: On Sonntag, 15. Februar 2004 10:49, Erik Hofman wrote: Jon Berndt wrote: I give up. Sort of. I hope you don't! No need to IMHO. I think we now have an excellent solution. Could someone file a patent request for this? There are some gotcha's involved which could mean some other points/locations should be exposed also in the future, but that's about it. And even then, JSBSim is now able to satisfy *every* request in that direction. I also did not understand why this simple feature is such a big question! The main remaining problem is that the rest of the subsystems have yet to take this adjustment into account also. Also from my reading of the current Model code it appears as if the absolute positioning of an aircraft with the world will be *very* dependent on the designer's choice of the VRP and I am also not sure if just with this addition the current code will fix the 'issue' that prompted the incarnation of this thread again. i.e. the aircraft appears to be rotating about the nose But since this is an abstract thing it is good to have a 'public' thrashing so all can gain an understanding of the issues involved please note this is non-trivial to most and not just a simple feature request which has far reaching consequences on the very 'core' of most everything within the SIM so to outline what I have gleaned so far 1) the 'modellers' coordinate frame will be [ X ] longitudinal increasing aft i.e. smallest at the nose [ Y ] latitudinal increasing righti.e. smallest at the left wing tip [ Z ] verticalincreasing up i.e. smallest at the ground This should not necessarily be a requirement for the 3D model. It is, however what the model must be translated to with the /offsets/ property. 2) within this frame a VRP virtual refrence point will be designated to represent the origin of the coordinate frame with respect to the 'tip' of the nose of the aircraft. 3) The SSG will assume a 'similar frame' but keep in mind that the Object.getBSphere()-getCenter() will return the point that is 'magically' computed to be at the center of the 'Geomettry' when passed to SSG at Object creation time. Most likely this will not be the VRP and in any case can *not* be assumed to be, and is . IMPORTANT: This *is* the point ultimately used by the Rendering Engine from which any rotation and / or translation is derived. The center of the bounding sphere shouldn't be relevant in this discussion. 4) The FDM will compute the center of 'Gravity' WRT to the frame and pass it's offset WRT to the VRP back to FGFS. note this is not and thus can *not* be assumed to be the same as the center of 'Geometry' that will be used by the Rendering Engine. 5) AFAICT FGFS will then reposition the AirCraft using the offset provided by the FDM and rotate the AirCraft to align itself with the orientation. Here is where I get confused and ... I am probably missing the obvious but nowhere in the above is the offset from the possibly corrected VRP WRT the Object.getBSphere()-getCenter() accounted for ?? The IG shouldn't be used to position the 3D model. If it being used, that's wrong. Also I can not find in the code the mechanism that will rotate the AirCraft about any point other then the point returned by Object.getBSphere()-getCenter() as adjusted by the translation WRT the VRP which appears to be set at Model load time from the OffSet from the nose and not the Geometrical center about which rotations will occur. In order for this to occur you need two complimentary translations. One before and one after the rotation. Also there is this issue about where exactly the [ lat, lon. alt ] reported back from the FDM each cycle refers to that is yet to be decided Again I am probably missing the obvious here and should just go back to lurking so Erik doesn't start ignoring my posts too :-) HTH Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel -- Russ Conway's Law: The structure of a system tends to mirror the structure of the group producing it. -- Mel Conway Datamation (1968) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] waves white flag
Russell Suter writes: The IG shouldn't be used to position the 3D model. If it being used, that's wrong. By IG I am assuming you mean Image Generator, and you have to understand how the things are drawn or else you are bound to get surprised at least occassionally :-) Cheers Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] waves white flag
Jim Wilson writes: Norman Vine said: Here is where I get confused and ... I am probably missing the obvious but See 3. Ummm...think about how rotation in 3D space really works for a minute. Easier to just wait for all this to get coded up and then see it live on the monitor :-) Cheers Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] waves white flag
On Sonntag, 15. Februar 2004 19:26, Norman Vine wrote: And all required 'corrections' that the model does not rotate around the nose but around the dynamic center of gravity are automatically included. Please reread my earlier post on necessary steps for rotating an object about an arbritrary point. Yes, I know how this relates, at least I believe. :) I will tell you that looking at the problem the way I described, you will see that you don't need to care for that forward and backward translation and rotation since you can reinterprete this sequence - translations and rotations you have in mind to place the model in the world - translate to the rotation axis - rotate - translate back as a matrix product of model transforms. But the same resulting transform matrix can also result from a completly different sequence. And viewing at the problem the way I suggested in my last mail will show you that you will also gain this resulting transform matrix by - translate to lat/lon/h of the vrp - rotate by the given angles I may have described the transforms in the wrong order, but in principle it sould be ok. Greetings Mathias -- Mathias Fröhlich, email: [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] waves white flag
Norman Vine wrote:
Jon Berndt writes:
Could this be solved if the camera viewpoint looked at the CG instead of
the VRP? What is being done, now?
The camera viewpoint need not necessarily be either or any fixed point
i.e. the camera should be free to look around :-)
What is required is that the 'center of rotation' of the aircraft is
about the proper point.
But since this is an abstract thing it is good to have a 'public'
thrashing so all can gain an understanding of the issues involved
please note this is non-trivial to most and not just a simple
feature request which has far reaching consequences on the very
'core' of most everything within the SIM
Definitely.
so to outline what I have gleaned so far
1) the 'modellers' coordinate frame will be
[ X ] longitudinal increasing aft i.e. smallest at the nose
[ Y ] latitudinal increasing righti.e. smallest
at the left wing tip
[ Z ] verticalincreasing up i.e. smallest
at the ground
This is definitely my strong preference, but can even this be adusted with
the offsets?
Yes this could be adjusted, probably easiest todo with a single matrix,
as is done with the conversion between SSG space and OpenGL space
ie in SSG space X is to the right, Y is away from the viewer, Z is up
and in OpenGL X is to right, Y is up, and Z is into the screen
and is conversion is accomplished by inserting the
sgMat4 _ssgOpenGLAxisSwapMatrix =
{
{ 1.0f, 0.0f, 0.0f, 0.0f },
{ 0.0f, 0.0f, -1.0f, 0.0f },
{ 0.0f, 1.0f, 0.0f, 0.0f },
{ 0.0f, 0.0f, 0.0f, 1.0f }
} ;
into the viewer pipeline, but do we want or need this extra flexibility
I think it best if we all just agree that this is the coordinate system
that will be used :-)
2) within this frame a VRP virtual refrence point will be designated
to represent the origin of the coordinate frame with respect to the
'tip' of the nose of the aircraft.
The VRP represents the location that the FDM reports the lat/lon/alt of,
since it is a comprehensible (by all parties) fixed point.
It was my understanding that the VRP was decided by the modeller,
most often for ease of 'modelling' and not for any 'physically based'
reasons. IMO we want a 'consistant' position on the frame to be the
reported [ lat, lon, alt ] location. I would argue that the position returned
by Object.getBsphere-getCenter() is the 'logical' choice for this as
it will make other parts of the SIM easier read more direct to keep in
sync, of course any location shift can be compensated for.
No! The Bounding Sphere is used to decide if the 3D model appears in
the viewing
frustum. The characteristics of a Bounding Sphere can change. As an
example, if a
sidewinder missile is launched from the tip of the wing, the verticies
of the missile
will no longer be part of the model and the center of the Bounding
Sphere can shift
relative to the rest of the model. If the Bounding Sphere is being used
to move the
model through the scene, it should be changed to use the product of this:
From sgLoad3DModel (in SimGear/simgear/scene/model.cxx):
ssgTransform * alignmainmodel = new ssgTransform;
alignmainmodel-addKid(model);
sgMat4 res_matrix;
sgMakeOffsetsMatrix(res_matrix,
props.getFloatValue(/offsets/heading-deg, 0.0),
props.getFloatValue(/offsets/roll-deg, 0.0),
props.getFloatValue(/offsets/pitch-deg, 0.0),
props.getFloatValue(/offsets/x-m, 0.0),
props.getFloatValue(/offsets/y-m, 0.0),
props.getFloatValue(/offsets/z-m, 0.0));
alignmainmodel-setTransform(res_matrix);
Thanks to Jim Wilson for posting this snippet.
The rendering code is beyond me ...
The rendering code is no different WRT to the 'meaning' of the
various 'reference' points then the code the FDM needs to use
to place the objects appropriately into the 'world' with the added
complexity of merging the coordinate frames.
--
Russ
Conway's Law: The structure of a system tends to mirror the
structure of the group producing it.
-- Mel Conway Datamation (1968)
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] waves white flag
Russell Suter writes: Norman Vine wrote: Simply stated the problem is that inorder to rotate an object about an arbritrary point you *must* do the equivalaent of the following 1) translate object so that it's 'rotation point' is at the 'point of rotation' 2) rotate the object 3) translate the object to it's 'desired' position this may not be it's original position depending on a) the 'coordinate frame' the object is described in which very likely is the case with an arbritrary VRP b) if the coordinate frame is dynamically changing as is the case with aerodynamic forces and gravity determining the 'frame' in a sophisticated FDM The first item doesn't need to be done per-frame. It can be done once and remembered. Agreed, and this is AFAICT what is done know although I don't believe the dynamic adjustment to the CG is accounted for yet FWIW AFAICT what isn't done is (3) Cheers Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] waves white flag
I give up. Sort of. I just want things to work out properly between the FDM and the 3D model. JSBSim now can provide the lat/lon/alt of a fixed point on the aircraft. This includes the possibility of providing an offset from the initial CG to the current CG. We can provide whatever is desired. I've proposed a solution that many of us agreed on at one point, and which I think makes sense given the perspectives of the two camps (FDM and 3D Model). I've made my argument. You can take it, or provide a different solution. We'll be happy to provide whatever is requested. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] waves white flag
Personally, I think the nose VRP makes a lot of sense. I think people are trying to make this a lot more complicated than it is. It's just a simple solution to a small problem. I vote Yea. Josh Jon Berndt wrote: I give up. Sort of. I just want things to work out properly between the FDM and the 3D model. JSBSim now can provide the lat/lon/alt of a fixed point on the aircraft. This includes the possibility of providing an offset from the initial CG to the current CG. We can provide whatever is desired. I've proposed a solution that many of us agreed on at one point, and which I think makes sense given the perspectives of the two camps (FDM and 3D Model). I've made my argument. You can take it, or provide a different solution. We'll be happy to provide whatever is requested. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
