Re: [Flightgear-devel] Aerodynamic centre and 3D models
Jon Berndt [EMAIL PROTECTED] wrote: Adopted to the current case this means: The longest distance from whichever CG you take to the edges of the aircraft is _always_ smaller than the longest distance from the nose to arbitrary edges. This results in smaller relative 'errors' in case some details don't get modelled as exact as it probably could be. In this case, you could also say that using the empty weight CG might actually _mask_ an error, where as using the nose would be more likely to expose an error (when doing ground ops). It depends on there you put the focus ;-) Consinder the case as an example that the flight model (not the FDM) is built upon data from an early design of some aircraft - because access to this data is easier. On the other hand, the 3D designer takes recent pictures as a basis for his model, because old picures from the early design are hard to find. [...] Yes. True. How many aircraft do we now model where this is the case? As an engineer I tend to install preventive measures _before_ we have a matching case Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Aerodynamic centre and 3D models
Russell Suter wrote: Of course someone must know this relationship. That doesn't mean they must be the same point. Someone must not only know the relationship but also be able to calculate, measure, or WAG a delta x,y,z between these two frames of reference and put them in the XML wrapper file. But the understanding need not be a prior agreement!!! So the answer is still NO! I think we should all live with what we have now. I am going to ignore any of your posts on this subject (congratulations, you're the first ever!). Now we go on doing some useful stuff. Thank you very much. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Aerodynamic centre and 3D models
Jim Wilson Sent: 13 February 2004 15:31 David Megginson [EMAIL PROTECTED] said: Jim Wilson wrote: Yes it is. I'm probably being really dense, but I can't think of a reason why it would be important to know what the origin is in fdm coordinates. So long as position is reported to fgfs at the nose, we should be fine. Assuming that the model also has its origin at the nose. If we can tell the FDM to report a different point, then the model can have its origin anywhere. The *.ac file doesn't actually need to be changed in any case. You can always use the offsets to move the 3D model origin to the nose. IIRC these are the offset properties that were originally used to place MSFS models that we couldn't edit. That dimmension would be easy to figure out because it would be the distance from the 3D model's origin to the location of the nose. For those who don't know what I'm refering to see: http://www.flightgear.org/Docs/fgfs-model-howto.html#repositioning In a sense what I've described here is analogous what you suggest, it's just the FDM doesn't actually need to know it (besides what ever you report would have to refer to some sort of static location). If we stick to having the only thing connecting the 3D to the FDM those /orientation and /position properties, then we'll be in better shape for multi-instance FDMs. That makes sense. So, I apply an offset to the 3d model, then an appropriate one to the views to bring those to the CofG (dry, I suppose). Then we can dynamically adjust the view offset to account for variations in the CofG with time so that the 3d model appears to rotate around the correct point at all times. Or will the views be offset some other way? Vivian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Aerodynamic centre and 3D models
On Sunday 15 February 2004 01:08, Jon Berndt wrote: [snip...] I am trying to preclude confusion amongst the audience of 3D modelers and flight model creators. Jon I'm not confused - am I doing something wrong? ;) LeeE ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Aerodynamic centre and 3D models
Jon S Berndt [EMAIL PROTECTED] wrote: On Fri, 13 Feb 2004 10:23:56 -0700 Russell Suter [EMAIL PROTECTED] wrote: Jon S Berndt wrote: But then, the FDM still has to report where the FDM is in a common reference frame. Exactly! At my company, we call this the control point and we have standardized on the Empty Weight CG. The 3D model designer will likely have no idea where the empty weight CG is, nor will they often care. They do know where physical points on the aircraft are, however. Additionally, the empty weight CG will be a slippery item to standardize on. Does that mean no fuel? No cargo? nothing? no stores? the C/D model or the A/B model? etc. The VRP is a **solid** point of reference. I realize that it is useful to agree to the nose as VRP in purpose to take the load off the 3D model designer to determine the empty weight CG. This is a valid argument. Albeit I don't want to hide an argument that speaks for the empty weight as a VRP which stems from practical experience as an engineer in say a production environment, where reality 'sometimes' differs from how things _should_ be in theory. You could call the rule: Reduce possbile errors already in early stages of design. Adopted to the current case this means: The longest distance from whichever CG you take to the edges of the aircraft is _always_ smaller than the longest distance from the nose to arbitrary edges. This results in smaller relative 'errors' in case some details don't get modelled as exact as it probably could be. Consinder the case as an example that the flight model (not the FDM) is built upon data from an early design of some aircraft - because access to this data is easier. On the other hand, the 3D designer takes recent pictures as a basis for his model, because old picures from the early design are hard to find. If you take the empty weight as VRP then chances are that the 3D model fits to the flight model with a smaller error because probably during development the shape of the nose has changed, a different radar was chosen (military aircraft), later production models got a different propeller with a different spinner (light aircraft) or whatever reason it might have had. Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Aerodynamic centre and 3D models
Jon Berndt said: The _only_ difference between now and what we had before is now the position may be reported at a fixed location on the aircraft by JSBsim. Before it was reported at the _current_ center of gravity which varies according to load, fuel consumption, etc. I'm sorry to be so dense, but could some explain what this is going to mess up? Say that initially JSBSim and the 3D model both agreed on where the center was - for JSBSim we simply report the CG location. OK, so the 3D model is flying along nicely - even took off nicely (since the CG matches where the 3D model rotates about in this example). Now, let's say we have fuel burnoff on one wing tank but not the other, so we end up with a CG that is two feet to the left of the fuselage at around the quarter chord (if you could even fly that, but humour me). The 3D model stil thinks the center of rotation is at the initially specified CG point, right? Now, when the aircraft lands, the FDM knows about all the contact points and where the CG is currently, and say one main gear (right) touches down well before the other. When the aircraft touches down the right gear, visually the right gear would hover above the runway some distance, because it is rotating about the initial CG, yet the FDM is rotating about the left-displaced CG, which has also a different altitude than is visually being shown That's not really true because you are providing us with a translated VRP position (which while arbitrary will always have the correct altitude). That visual wheel should hit the ground exactly on time. You wrote the code didn't you? ;-) Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Aerodynamic centre and 3D models
Jon Berndt said: That's not really true because you are providing us with a translated VRP position (which while arbitrary will always have the correct altitude). That visual wheel should hit the ground exactly on time. You wrote the code didn't you? ;-) Best, Jim Sorry - I meant the above would happen if the change was not incorporated - that it would be fixed with the VRP. Phew! You had me worried. :-) Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Aerodynamic centre and 3D models
It didn't seem so obvious when you said this: If we are providing the position of the nose, and the 3D model has some arbitrary origin (that's *not* the nose) then it's not gonna work. Yes, that probably didn't help matters. In this lengthy and convoluted thread it's probably not the only thing I stated confusingly. My assumption has been all along that the 3D model would use an arbitrary frame and origin and that the scene code would have to translate the frame for the 3D model so that the nose was (_effectively_) at the (0,0,0) point. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Aerodynamic centre and 3D models
Lee Elliott wrote On Friday 13 February 2004 06:16, Jon Berndt wrote: True, but... This is a chunk of calculations running every frame. In the olden days, the cost would be too high. These days, it's not even a spec on a flea on the butt of an elephant in terms of the overall FDM calculations - which in turn are not much of a spec on a flea in the overall FlightGear calculations. Our Aerodynamic modelers always seemed to know where the empty weight CG was every frame without additional calculations. That's not the issue, though. We FDM guys know absolutely where everything is at all times within the FDMs. Yep:) Everything's right where we put it:) LeeE I'm about halfway through generating a 3d cockpit for the Seahawk model - are you going to move the origin of the model? I'd like a heads up, it will probably affect how I go about the rest of the work. Regards Vivian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Aerodynamic centre and 3D models
On Saturday 14 February 2004 13:07, Vivian Meazza wrote: Lee Elliott wrote On Friday 13 February 2004 06:16, Jon Berndt wrote: True, but... This is a chunk of calculations running every frame. In the olden days, the cost would be too high. These days, it's not even a spec on a flea on the butt of an elephant in terms of the overall FDM calculations - which in turn are not much of a spec on a flea in the overall FlightGear calculations. Our Aerodynamic modelers always seemed to know where the empty weight CG was every frame without additional calculations. That's not the issue, though. We FDM guys know absolutely where everything is at all times within the FDMs. Yep:) Everything's right where we put it:) LeeE I'm about halfway through generating a 3d cockpit for the Seahawk model - are you going to move the origin of the model? I'd like a heads up, it will probably affect how I go about the rest of the work. Regards Vivian That's great news. The only change that's likely to the Sea Hawk model will be to shift the origin to the nose;) This won't actually be too much of a problem and will only require simple offsets to the numbers in the anim and fdm files: Say I need to move the model 3 metres back and 0.1 metre up, then all we need to do is add 3 metres to all the 'x' measurements, and 0.1 to all the 'z' measurements in the fdm and anim files to line everything up again. (Heh!... or it might be _subtract_ 3 metres... maths was never my strong point) LeeE ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Aerodynamic centre and 3D models
Lee Elliott Sent: 14 February 2004 13:35 To: FlightGear developers discussions Subject: Re: [Flightgear-devel] Aerodynamic centre and 3D models On Saturday 14 February 2004 13:07, Vivian Meazza wrote: Lee Elliott wrote On Friday 13 February 2004 06:16, Jon Berndt wrote: True, but... This is a chunk of calculations running every frame. In the olden days, the cost would be too high. These days, it's not even a spec on a flea on the butt of an elephant in terms of the overall FDM calculations - which in turn are not much of a spec on a flea in the overall FlightGear calculations. Our Aerodynamic modelers always seemed to know where the empty weight CG was every frame without additional calculations. That's not the issue, though. We FDM guys know absolutely where everything is at all times within the FDMs. Yep:) Everything's right where we put it:) LeeE I'm about halfway through generating a 3d cockpit for the Seahawk model - are you going to move the origin of the model? I'd like a heads up, it will probably affect how I go about the rest of the work. Regards Vivian That's great news. The only change that's likely to the Sea Hawk model will be to shift the origin to the nose;) This won't actually be too much of a problem and will only require simple offsets to the numbers in the anim and fdm files: Say I need to move the model 3 metres back and 0.1 metre up, then all we need to do is add 3 metres to all the 'x' measurements, and 0.1 to all the 'z' measurements in the fdm and anim files to line everything up again. (Heh!... or it might be _subtract_ 3 metres... maths was never my strong point) Then readjust all the animations to make them work correctly - fun eh? I'll try to make the cockpit reasonably independent of the origin - I've done it for instruments and I'll try and extend it to other stuff. Vivian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Aerodynamic centre and 3D models
On Saturday 14 February 2004 13:52, Vivian Meazza wrote: Lee Elliott Sent: 14 February 2004 13:35 To: FlightGear developers discussions Subject: Re: [Flightgear-devel] Aerodynamic centre and 3D models On Saturday 14 February 2004 13:07, Vivian Meazza wrote: Lee Elliott wrote On Friday 13 February 2004 06:16, Jon Berndt wrote: True, but... This is a chunk of calculations running every frame. In the olden days, the cost would be too high. These days, it's not even a spec on a flea on the butt of an elephant in terms of the overall FDM calculations - which in turn are not much of a spec on a flea in the overall FlightGear calculations. Our Aerodynamic modelers always seemed to know where the empty weight CG was every frame without additional calculations. That's not the issue, though. We FDM guys know absolutely where everything is at all times within the FDMs. Yep:) Everything's right where we put it:) LeeE I'm about halfway through generating a 3d cockpit for the Seahawk model - are you going to move the origin of the model? I'd like a heads up, it will probably affect how I go about the rest of the work. Regards Vivian That's great news. The only change that's likely to the Sea Hawk model will be to shift the origin to the nose;) This won't actually be too much of a problem and will only require simple offsets to the numbers in the anim and fdm files: Say I need to move the model 3 metres back and 0.1 metre up, then all we need to do is add 3 metres to all the 'x' measurements, and 0.1 to all the 'z' measurements in the fdm and anim files to line everything up again. (Heh!... or it might be _subtract_ 3 metres... maths was never my strong point) Then readjust all the animations to make them work correctly - fun eh? I'll try to make the cockpit reasonably independent of the origin - I've done it for instruments and I'll try and extend it to other stuff. Vivian The only readjustments that would be needed are the simple x z offsets - all the axis would remain unchanged so, for example, the aileron axis numbers wouldn't need to be changed, just their location, in line with the simple x/z offsets. LeeE ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Aerodynamic centre and 3D models
Norman Vine [EMAIL PROTECTED] said: Russell Suter writes: Jon S Berndt wrote: I don't see any advantage to your approach. By your responses, you give me no indication that you even understand what I'm saying. I seem to be alone in my dissent anyway... What you are planning will work just fine. snip Curiously looking forward to the kludges in the code in future code modules to adjust the radar displays for other aircraft locations :-) Could you be more specific about the nature of the kludge required for the radar display? Now is the time to look at the change that Jon has made and figure out the real ramifications rather than sitting back and doing nothing just so you can come back a year later and say I told you so. Dig in and really look at the problem, please. Believe it or not most of us do appreciate your insight :-) FWIW _all_ this patch does is allow the specification of a static location for the FDM to report aircraft position at in JSBsim. Previously it was reported from the current center of gravity. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Aerodynamic centre and 3D models
Jim Wilson writes: Norman Vine [EMAIL PROTECTED] said: Please try to configure your mailer to not quote raw e-mail addresses in your replies. Let's not make the spam harvesters' life any easier... Russell Suter writes: By your responses, you give me no indication that you even understand what I'm saying. snip Curiously looking forward to the kludges in the code in future code modules to adjust the radar displays for other aircraft locations :-) Could you be more specific about the nature of the kludge required for the radar display? I certainly hope you are not planning on publishing the 'position' as reported by the FDM for things like collision detection and related instrumentation such as a radar display with out some kind of 'adjustment' No-digging-necessary'ly-yr's Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Aerodynamic centre and 3D models
Norman Vine wrote: I certainly hope you are not planning on publishing the 'position' as reported by the FDM for things like collision detection and related instrumentation such as a radar display with out some kind of 'adjustment' No-digging-necessary'ly-yr's Collision detection could be an interesting point. Radar seems like a stretch unless you are *extremely* close to the target (at which point you probably aren't watching your radar anyway.) In RL you are probably going to get wierd results that close anyway. Curt. -- Curtis Olson Intelligent Vehicles Lab 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] Aerodynamic centre and 3D models
Jon S. Berndt wrote: IIRC, YASim provides for the origin at the nose tip too (or something close to that). YASim doesn't care, actually. It reports the output lat/lon/alt value as the location of the coordinate origin of the airframe (that is, the 0,0,0 referenced by all the coordinates it finds in the aircraft definition file). I've always suggested the nose as an obvious and hard-to-mistake location, but there's nothing in code to enforce that. If the aircraft lacks a well-defined nose, then we can pick something else; the only requirement is that all the FDM configurations and 3D models for a single aircraft agree. There's not need to unify conventions for across all possible aircraft. Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Aerodynamic centre and 3D models
Curtis L. Olson writes: Norman Vine wrote: I certainly hope you are not planning on publishing the 'position' as reported by the FDM for things like collision detection and related instrumentation such as a radar display with out some kind of 'adjustment' No-digging-necessary'ly-yr's Collision detection could be an interesting point. Radar seems like a stretch unless you are *extremely* close to the target (at which point you probably aren't watching your radar anyway.) In RL you are probably going to get wierd results that close anyway. Hmm.. conventional radar usage is perhaps a bit of a stretch but things such as automated landings use radar verification where being off by half the length of a 747 could lead to 'interesting' things .. there are other interesting uses for radar like things too that are most useful when you aren't necessarily watching the 'screen' * ALARM * ALARM * ALARM * Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Aerodynamic centre and 3D models
Norman Vine said: Jim Wilson writes: I certainly hope you are not planning on publishing the 'position' as reported by the FDM for things like collision detection and related instrumentation such as a radar display with out some kind of 'adjustment' The _only_ difference between now and what we had before is now the position may be reported at a fixed location on the aircraft by JSBsim. Before it was reported at the _current_ center of gravity which varies according to load, fuel consumption, etc. I'm sorry to be so dense, but could some explain what this is going to mess up? Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Aerodynamic centre and 3D models
Jim Wilson writes: Norman Vine said: Thanks for making the mailer fix :-) I certainly hope you are not planning on publishing the 'position' as reported by the FDM for things like collision detection and related instrumentation such as a radar display with out some kind of 'adjustment' The _only_ difference between now and what we had before is now the position may be reported at a fixed location on the aircraft by JSBsim. Before it was reported at the _current_ center of gravity which varies according to load, fuel consumption, etc. AFAIK In most systems if an object is represented by a point location it is expected that said location will be 'near' the center of the object in question. In the case of radar the center point of the 'target's on-screen echo' when extrapolated to account for the 'display properties' is most often close to the center point of the object 'sensed'. I know it is really much more complicated then this but ... it is certainly closer to the center point then one of the extremities unless that extremity and the center point line up on a vector emanating from the radar Note this has nothing to do with how FGFS has or will do things but reflects common practice and deviation from this will 'often' have to be accounted for. hence my original 'kludge' comment Cheers Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Aerodynamic centre and 3D models
Jim Wilson wrote: Vivian Meazza snip said: I'm about halfway through generating a 3d cockpit for the Seahawk model - are you going to move the origin of the model? I'd like a heads up, it will probably affect how I go about the rest of the work. If the model is already animated (and/or cockipit models positioned) I would recommend using this to reposition the model: http://www.flightgear.org/Docs/fgfs-model-howto.html#repositioning I should have known. It's already there! This is exactly the meta data I was talking about! With this, you can pick ***ANY*** static point in the model. A few seconds with a calculator and done! Since you can pick any static point, there is no need to calculate a new one. It's like paying double to use the toll road. I suspect these properties are applied anyway -- even if they are zero. I don't know if these are applied per frame or if they are applied once to the model. In the latter case, you can ride the toll road all day and only have to pay the toll once! -- 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] Aerodynamic centre and 3D models
On Fri, 2004-02-13 at 10:23, Russell Suter wrote: Jon Berndt wrote: So, instead of defining some arbitrary frame, _we_use_an_industry_standard_, which is the structural frame that the manufacturer defines, when available. It is always (in my experience) X positive aft, Y positive right, with the origin being seemingly arbitrary. I wouldn't go so far as to say this is an industry standard. FG is the first sim I've seen that uses this coordinate system. The one I've seen the most is X positive forward, Y positive right and Z positive down. Someone once told me this was named the Boeing system. On the sim I'm working on now, it's positive Y forward, positive X to the right and positive Z up. I'll admit that most of the sims I've worked on are relatively old in FORTRAN and C. There really are no industry standards here. Body axis, earth local, and earth fixed are commonly used in simulation. A system like our structural system is commonly used by manufacturing, ground ops, and flight ops folks. But even then, the origins vary from airplane to airplane. Don't get me wrong, I'm not saying this is a bad system, I'm just not sure I agree it is an industry standard... -- Tony Peden [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Aerodynamic centre and 3D models
FWIW _all_ this patch does is allow the specification of a static location for the FDM to report aircraft position at in JSBsim. Previously it was reported from the current center of gravity. That's exactly right. Furthermore, if the VRP is set to the empty weight CG for an aircraft flight model, and the 3D modeler talks with the flight modeler to communicate where exactly the empty weight CG is (since it is the flight modeler that will be setting this location based on physical parameters), then everyone is happy, as well. The VRP code now in JSBSim simply allows an agreed upon point to be reported to FlightGear - whether it's the empty weight CG, or the nose tip, or the left wingtip, as long as it is agreed upon between the 3D modeler and the flight modeler, the rendition will come out looking right. There's nothing nefarious about the new code in JSBSim. Nothing that leads to a dead end. The big question seems to be about where the common reference point should be. Think about that one. Think about what each modeler will know. Think about what both will know. Think about whether the common visual reference should be the same (a convention) across all models so it doesn't lead to confusion. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Aerodynamic centre and 3D models
There really are no industry standards here. Body axis, earth local, and earth fixed are commonly used in simulation. A system like our structural system is commonly used by manufacturing, ground ops, and flight ops folks. But even then, the origins vary from airplane to airplane. Yes, the origin varies widely in all the specifications I have seen, but the directions of the axes have all been the same (i.e. like our structural frame). As well, all of them have been measured in inches, too. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Aerodynamic centre and 3D models
Russell Suter said: I suspect these properties are applied anyway -- even if they are zero. I don't know if these are applied per frame or if they are applied once to the model. In the latter case, you can ride the toll road all day and only have to pay the toll once! Exactly. 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); Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Aerodynamic centre and 3D models
Jim Wilson writes: Russell Suter said: I suspect these properties are applied anyway -- even if they are zero. I don't know if these are applied per frame or if they are applied once to the model. In the latter case, you can ride the toll road all day and only have to pay the toll once! Exactly. 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); Yup, something like that is how it's supposed to work but ... I remember your asking about how to set this up and that you didn't like the axis angle form that we were using but I hadn't realized that this code had actually changed ... hmm... I have to think about this for a while ... anyway see attached for a much quicker equivalent of the current code Norman mat_test.cxx Description: Binary data ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Aerodynamic centre and 3D models
Norman Vine wrote: Hmm.. conventional radar usage is perhaps a bit of a stretch but things such as automated landings use radar verification where being off by half the length of a 747 could lead to 'interesting' things .. there are other interesting uses for radar like things too that are most useful when you aren't necessarily watching the 'screen' * ALARM * ALARM * ALARM * Actually: * Warning * Warning * * Warning * Warning * Or my favorite: * PULL UP * PULL UP* Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Aerodynamic centre and 3D models
Jim Wilson wrote: The _only_ difference between now and what we had before is now the position may be reported at a fixed location on the aircraft by JSBsim. Before it was reported at the _current_ center of gravity which varies according to load, fuel consumption, etc. I'm sorry to be so dense, but could some explain what this is going to mess up? The reported lat/lon/alt would swing around a certain other location when displayed on an external radar display. To correct that you would need the heading vector and the relative static CG distance and compute the actual rotational point. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Aerodynamic centre and 3D models
The _only_ difference between now and what we had before is now the position may be reported at a fixed location on the aircraft by JSBsim. Before it was reported at the _current_ center of gravity which varies according to load, fuel consumption, etc. I'm sorry to be so dense, but could some explain what this is going to mess up? Say that initially JSBSim and the 3D model both agreed on where the center was - for JSBSim we simply report the CG location. OK, so the 3D model is flying along nicely - even took off nicely (since the CG matches where the 3D model rotates about in this example). Now, let's say we have fuel burnoff on one wing tank but not the other, so we end up with a CG that is two feet to the left of the fuselage at around the quarter chord (if you could even fly that, but humour me). The 3D model stil thinks the center of rotation is at the initially specified CG point, right? Now, when the aircraft lands, the FDM knows about all the contact points and where the CG is currently, and say one main gear (right) touches down well before the other. When the aircraft touches down the right gear, visually the right gear would hover above the runway some distance, because it is rotating about the initial CG, yet the FDM is rotating about the left-displaced CG, which has also a different altitude than is visually being shown Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Aerodynamic centre and 3D models
On Saturday 14 Feb 2004 6:27 pm, Norman Vine wrote: snip AFAIK In most systems if an object is represented by a point location it is expected that said location will be 'near' the center of the object in question. In the case of radar the center point of the 'target's on-screen echo' when extrapolated to account for the 'display properties' is most often close to the center point of the object 'sensed'. I know it is really much more complicated then this but ... it is certainly closer to the center point then one of the extremities unless that extremity and the center point line up on a vector emanating from the radar Note this has nothing to do with how FGFS has or will do things but reflects common practice and deviation from this will 'often' have to be accounted for. Oo! Oo! but this is a simulator, isn't it? So won't it simulate the electromagnetic pulse from our aircraft's antenna, modify it for the medium between us and the target, query the position (of the nose :¬) and orientation of the target, calculate the effective radar cross-section, and return the reflection to the receiver? We wouldn't just draw a blip on a radar instrument screen, being a projection of X.target, Y.target, Z.target, would we? (OK, maybe if the target squawked). :-P Jonathan I've got a more serious observations on the Reference Point Skirmish, though. At least in the early part of the debate it would have helped if we had a diagram to refer to, just to get the nomenclature clear. A picture paints 1K words, etc. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Aerodynamic centre and 3D models
No. No. No. No. There need not be a prior agreement. The 3D modeler uses whatever origin suits. It appears in many cases that's the nose. Yes, yes. There has to be an understanding of the difference between the frames of reference (FDM and 3D model). If we are providing the position of the nose, and the 3D model has some arbitrary origin (that's *not* the nose) then it's not gonna work. I think you understand this. The point is, SOMEONE has to know how to relate the two frames of reference - THAT's what I mean by agreed-upon. Look, I understand 3D graphics. I wrote an application 15 years ago that took reams of simulation data and wrote an animation (frame-by-frame) to videotape using IRIX-GL (before there was OpenGL: http://www.hal-pc.org/~jsb/lambs.jpg). I've created often used shuttle 3D models for rendering under POV-Ray: http://www.hal-pc.org/~jsb/shuttlepov.html. I am trying to preclude confusion amongst the audience of 3D modelers and flight model creators. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Aerodynamic centre and 3D models
Norman Vine wrote: Jim Wilson writes: Exactly. From sgLoad3DModel (in SimGear/simgear/scene/model.cxx): Yup, something like that is how it's supposed to work but ... I remember your asking about how to set this up and that you didn't like the axis angle form that we were using but I hadn't realized that this code had actually changed ... hmm... I have to think about this for a while ... This looks fine, I guess I was just surprised that I hadn't noticed the code change earlier, and since this is currently only called once for any model it isn't time sensitive either although we might as well use the 'faster' code :-) Cheers Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Aerodynamic centre and 3D models
Jon Berndt wrote: No. No. No. No. There need not be a prior agreement. The 3D modeler uses whatever origin suits. It appears in many cases that's the nose. Yes, yes. There has to be an understanding of the difference between the frames of reference (FDM and 3D model). If we are providing the position of the nose, and the 3D model has some arbitrary origin (that's *not* the nose) then it's not gonna work. Then what the H E double toothpicks are these properties for: */offsets/x-m* The distance to reposition the model along the x-axis. */offsets/y-m* The distance to reposition the model along the y-axis. */offsets/z-m* The distance to reposition the model along the z-axis. */offsets/heading-deg* The angle by which to rotate the model around the z-axis. */offsets/roll-deg* The angle by which to rotate the model around the x-axis. */offsets/pitch-deg* The angle by which to rotate the model around the y-axis. I think you understand this. The point is, SOMEONE has to know how to relate the two frames of reference - THAT's what I mean by agreed-upon. Of course someone must know this relationship. That doesn't mean they must be the same point. Someone must not only know the relationship but also be able to calculate, measure, or WAG a delta x,y,z between these two frames of reference and put them in the XML wrapper file. But the understanding need not be a prior agreement!!! So the answer is still NO! Personally, I have matched FDMs that I did not create with 3D models I did not create each with different frames of reference using something very similar to the /offsets/ properties. Look, I understand 3D graphics. I wrote an application 15 years ago that took reams of simulation data and wrote an animation (frame-by-frame) to videotape using IRIX-GL (before there was OpenGL: http://www.hal-pc.org/~jsb/lambs.jpg). I've created often used shuttle 3D models for rendering under POV-Ray: http://www.hal-pc.org/~jsb/shuttlepov.html. I mean no disrespect, nor do I question your ability. But, you don't seem to entirely understand the power of the offsets property. If the FDM reports a position, say the nose, as you intend to do. Now say that the 3D model has the origin at the tail. All is not lost. As long as someone can determine the deltas x,y,z between these two fixed points, these deltas become the /offsets/ properties in the XML wrapper file that tell the IG software how to shift the 3D model to the FDM's reported position. That JSBSim reported the nose is not significant. It's fixed point to fixed point but they don't need to be the same fixed point. I am trying to preclude confusion amongst the audience of 3D modelers and flight model creators. This is a false sense of security. Not all FDMs will use the nose, nor will all 3D models. There is another mechanism to correlate the two. That mechanism is the /offsets/ properties in the wraper file. Reread the section Jim Wilson referenced: http://www.flightgear.org/Docs/fgfs-model-howto.html#repositioning And, as Jim confirmed earlier, this mechanism ALWAYS happens, even if the offsets are 0,0,0. -- 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] Aerodynamic centre and 3D models
Russell Suter David Megginson wrote: Andy Ross wrote: I'm not sure exactly what this is for. I can (and probably should) export the C.G. position for the view code to use appropriately. But the VRP stuff seems like a double-correction. It's basically identical to the view center offset stuff, isn't it? It's the location on the plane where the FDM reports the lon/lat/alt. It's kind-of a nifty idea, actually. True, but... This is a chunk of calculations running every frame. In the olden days, the cost would be too high. Our Aerodynamic modelers always seemed to know where the empty weight CG was every frame without additional calculations. That said, we made the graphic artists translate the visual model such that the 0,0,0 point for the model was the empty weight CG. That's what I did for the Hunter model - seemed to make sense, and I could readily derive the CofG from the YASim calculations. I was aided in this decision by the fact that the CofG of that aircraft does not move much as fuel is consumed. That said, it's marginally easier to draw the model with the origin at the nose, and then move it. (not offset - just moving it in the drawing package). It seems, from a visual point of view, equally valid to leave the origin at the nose and to offset the views. Is the a technical reason to prefer one or other choice? What is clear from all this discussion, that to use the nose of the 3d model as the origin, and not to adjust the views to the CofG will produce the visual impression that rotations are taking place about the nose, even though the FDM's are of course rotating about the CofG. I remain disconcerted that the visual model appears to roll through 180 degs vertically on the up and down legs of a loop when in chase or helicopter view. Not the end of the world, but lacking realism. If you are not confused by now, you don't understand the problem. Vivian Meazza ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Aerodynamic centre and 3D models
Vivian Meazza writes: I remain disconcerted that the visual model appears to roll through 180 degs vertically on the up and down legs of a loop when in chase or helicopter view. Not the end of the world, but lacking realism. Yes this is a short coming of the math method used. Note that the cursor should also be restrained in the vertical direction so as to not wrap from the top to the bottom, or visa versa, not doing so potentially compounds the confusion Put simply the matrix math used supports a 'restrained' cylindrical viewer not a true spherical viewer. The reasons that FlightGear does not use a quaternion model for this, I will leave for others to explain. HTH Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Aerodynamic centre and 3D models
Jon Berndt [EMAIL PROTECTED] said: David Megginson [EMAIL PROTECTED] said: It's the location on the plane where the FDM reports the lon/lat/alt. It's kind-of a nifty idea, actually. In relation to? It is always 0,0,0 in Yasim. Best, Jim JSBSim could also define the tip of the nose as (0,0,0). It really doesn't matter a whole lot. However, internally, the FDMs really don't care about exact locations - only relative distances. I think we all agree on that. So, instead of defining some arbitrary frame, _we_use_an_industry_standard_, which is the structural frame that the manufacturer defines, when available. It is always (in my experience) X positive aft, Y positive right, with the origin being seemingly arbitrary. For us, that solution works great and is very appropriate. When the frame is not known, we could just as easily decide that the origin could be at the nose tip. In any case, given the potential variances in structural coordinate frames - and especially considering that there are many FDMs, the 3D model placement code needs to be able to match up with the FDM. I think our VRP solution works well, and is versatile given our situation. Yes it is. I'm probably being really dense, but I can't think of a reason why it would be important to know what the origin is in fdm coordinates. So long as position is reported to fgfs at the nose, we should be fine. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Aerodynamic centre and 3D models
Jim Wilson wrote: Yes it is. I'm probably being really dense, but I can't think of a reason why it would be important to know what the origin is in fdm coordinates. So long as position is reported to fgfs at the nose, we should be fine. Assuming that the model also has its origin at the nose. If we can tell the FDM to report a different point, then the model can have its origin anywhere. All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Aerodynamic centre and 3D models
Norman Vine [EMAIL PROTECTED] said: Vivian Meazza writes: I remain disconcerted that the visual model appears to roll through 180 degs vertically on the up and down legs of a loop when in chase or helicopter view. Not the end of the world, but lacking realism. Yes this is a short coming of the math method used. Note that the cursor should also be restrained in the vertical direction so as to not wrap from the top to the bottom, or visa versa, not doing so potentially compounds the confusion Put simply the matrix math used supports a 'restrained' cylindrical viewer not a true spherical viewer. The reasons that FlightGear does not use a quaternion model for this, I will leave for others to explain. That is a problem, but it isn't the issue here. In the chase views the camera is aft of the aircraft position (horizontally). On going into the upside down part of a loop the heading of the aircraft does a sudden 180, so aft is now the other way. And thus the direction of view is doing a 180. If you want to avoid this then you need a different type of view configuration. One way is to not set the heading input for the view. Then you will always look at the plane from the North. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Aerodynamic centre and 3D models
Russell Sutter wrote: David Megginson wrote: Andy Ross wrote: I'm not sure exactly what this is for. I can (and probably should) export the C.G. position for the view code to use appropriately. But the VRP stuff seems like a double-correction. It's basically identical to the view center offset stuff, isn't it? It's the location on the plane where the FDM reports the lon/lat/alt. It's kind-of a nifty idea, actually. True, but... This is a chunk of calculations running every frame. In the olden days, the cost would be too high. It's a vector addition; I think we can handle it. Seriously, YASim in particular is doing *so* much more work than this that the overhead would be literally immesurable. My objection is that it seems to be handled in multiple places, and we should just pick one. Right now we can adjust the model and view origins with any/all of the following: + Move the model origin. (Add an offset to all the vertices in the .ac file) + Move the FDM origin.(Ditto for the FDM configuration) + Use the /view/config/*-offset-m properties (see the 747 for an example) Adding the VRP is yet another mechanism, basically a direct analog of the view offset stuff on the FDM side. I just don't see the need. If we decide the VRP is the right way to do it, we should chuck the view offset stuff for simplicity and orthogonality. Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Aerodynamic centre and 3D models
On Fri, 13 Feb 2004 07:07:05 -0800 Andy Ross [EMAIL PROTECTED] wrote: Adding the VRP is yet another mechanism, basically a direct analog of the view offset stuff on the FDM side. I just don't see the need. If we decide the VRP is the right way to do it, we should chuck the view offset stuff for simplicity and orthogonality. Andy Can the view offset or rendering code (whatever it is that draws the 3D aircraft models) move the origin of the set of vertices that defines the model per-frame so that the CG aligns with that reported by the FDM? But then, the FDM still has to report where the FDM is in a common reference frame. The 3D model and the FDM don't really know that much about each other - it's dort of open-loop. It's not clear to me how you are proposing that the 3D modeling code would know how to exactly interpret what the FDM is telling it - apart from there being a convention such as the VRP. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Aerodynamic centre and 3D models
Jim Wilson writes: Norman Vine [EMAIL PROTECTED] said: Put simply the matrix math used supports a 'restrained' cylindrical viewer That is a problem, but it isn't the issue here. There is a singularity in the math model which in effect snaps the orientation of the model 180* when the mouse wraps in the vertical sense Cheers Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Aerodynamic centre and 3D models
Norman Vine [EMAIL PROTECTED] said: Jim Wilson writes: Norman Vine [EMAIL PROTECTED] said: Put simply the matrix math used supports a 'restrained' cylindrical viewer That is a problem, but it isn't the issue here. There is a singularity in the math model which in effect snaps the orientation of the model 180* when the mouse wraps in the vertical sense Yeah I know. Sometimes it just wiggles back and forth. For example you can't possibly look straight down. We could switch to quats or we could just put something in there that avoids looking exactly straight down (or up). I'm pretty sure I know what he was referring to with the flight loops. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Aerodynamic centre and 3D models
Jim Wilson advised: Norman Vine [EMAIL PROTECTED] said: Vivian Meazza writes: I remain disconcerted that the visual model appears to roll through 180 degs vertically on the up and down legs of a loop when in chase or helicopter view. Not the end of the world, but lacking realism. Yes this is a short coming of the math method used. Note that the cursor should also be restrained in the vertical direction so as to not wrap from the top to the bottom, or visa versa, not doing so potentially compounds the confusion Put simply the matrix math used supports a 'restrained' cylindrical viewer not a true spherical viewer. The reasons that FlightGear does not use a quaternion model for this, I will leave for others to explain. That is a problem, but it isn't the issue here. In the chase views the camera is aft of the aircraft position (horizontally). On going into the upside down part of a loop the heading of the aircraft does a sudden 180, so aft is now the other way. And thus the direction of view is doing a 180. If you want to avoid this then you need a different type of view configuration. One way is to not set the heading input for the view. Then you will always look at the plane from the North. Best, Jim Thanks Jim, that saved me several days of devilling around - works beautifully. Vivian Meazza ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Aerodynamic centre and 3D models
Andy Ross wrote: Russell Sutter wrote: David Megginson wrote: Andy Ross wrote: I'm not sure exactly what this is for. I can (and probably should) export the C.G. position for the view code to use appropriately. But the VRP stuff seems like a double-correction. It's basically identical to the view center offset stuff, isn't it? It's the location on the plane where the FDM reports the lon/lat/alt. It's kind-of a nifty idea, actually. True, but... This is a chunk of calculations running every frame. In the olden days, the cost would be too high. It's a vector addition; I think we can handle it. Seriously, YASim in particular is doing *so* much more work than this that the overhead would be literally immesurable. That really wasn't the point, but whatever. I don't question anyone's ability or really even so much the cost. I'm simply trying to point out alternatives. My objection is that it seems to be handled in multiple places, and we should just pick one. Right now we can adjust the model and view origins with any/all of the following: Yes, exactly! I'm on your side here Andy, so be nice to me... ;-) + Move the model origin. (Add an offset to all the vertices in the .ac file) + Move the FDM origin.(Ditto for the FDM configuration) + Use the /view/config/*-offset-m properties (see the 747 for an example) Adding the VRP is yet another mechanism, basically a direct analog of the view offset stuff on the FDM side. I just don't see the need. If we decide the VRP is the right way to do it, we should chuck the view offset stuff for simplicity and orthogonality. The VRP is a fine idea but if you change your point of view from the FDM and to the model, as long as you have a fixed point calculated in the FDM, why not use it. Translate the model to that point. The translation can be done once when the .ac file is loaded. For us it was the Empty Weight CG. If the IG software supports the concept of an Static Coordinate System (SCS) node, the process is simple. For those familiar with SGI's Performer, you know what I'm talking about. Then the VRP becomes meta data for the model instead of the FDM. We did this on the last two devices I worked on. -- 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] Aerodynamic centre and 3D models
Andy Ross wrote: Jon S. Berndt wrote: Can the view offset or rendering code (whatever it is that draws the 3D aircraft models) move the origin of the set of vertices that defines the model per-frame so that the CG aligns with that reported by the FDM? Well, yes, because they're just properties. But unless I misunderstand you, you don't want to do that. The FDM reports the lat/lon/alt of the aircraft coordinate origin, not the c.g., no? I don't think that's what he means. I took him to mean that the visual model origin is translated to the CG every frame. If that's what you mean, you really don't want to do that. That's a matrix transform for every vertex in the model. -- 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] Aerodynamic centre and 3D models
Russell Suter writes: I don't think that's what he means. I took him to mean that the visual model origin is translated to the CG every frame. If that's what you mean, you really don't want to do that. That's a matrix transform for every vertex in the model. This is boils down to just one matrix by matrix multiplication Every vertex has to have a transform any way and this just 'conditions' the matrix for that transform Cheers Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Aerodynamic centre and 3D models
One other point and then I'll shut the heck up. In the case of military aircraft with loadouts, you'll want to consider the visual transition between a missile on the rail and flyout as an example. When we first implemented this kind of thing, the missile looked fine on the rail but when fired, it appeared to flyout from above the wing. The customer was not happy... -- 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] Aerodynamic centre and 3D models
Jon S Berndt [EMAIL PROTECTED] said: On Fri, 13 Feb 2004 08:22:15 -0800 Andy Ross [EMAIL PROTECTED] wrote: Jon S. Berndt wrote: Can the view offset or rendering code (whatever it is that draws the 3D aircraft models) move the origin of the set of vertices that defines the model per-frame so that the CG aligns with that reported by the FDM? Well, yes, because they're just properties. But unless I misunderstand you, you don't want to do that. The FDM reports the lat/lon/alt of the aircraft coordinate origin, not the c.g., no? Andy No. JSBSim currently (the version in in FlightGear, anyhow), reports the position of the CG, since that is what the EOM natively tracks, anyhow. We can *report* anything, though of course, as we have intimate knowledge of euler angles, CG position, and offset from the CG (dynamic) to any other point on the aircraft at any time. I really think we should stick to the previous plan of reporting lon/lat/alt at the nose position. Even if we tried it and then found out it was all wrong it would involve far less labor then we've spent reacting on this mailing list to every objection that gets raised by someone that doesn't understand the problem. This really has been discussed very thoroughly in the past. We do not need anything else. YASim is fine as is. Jon, if you want to make the change I'll go through the 3D model wrappers and make the necessary adjustment to each one. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Aerodynamic centre and 3D models
Russell Suter wrote: Don't get me wrong, I'm not saying this is a bad system, I'm just not sure I agree it is an industry standard... The FAA uses positive numbers towards the tail in specifying longitudinal weight and balance limits in the TCDS; all weight and balance calculations I've seen so far (textbooks, POH's, software) also use a positive number towards the tail in the longitudinal axis. I think that any small-aircraft pilot or mechanic would find a coordinate system that was positive towards the nose simply bizarre. The Y and Z axes are not so obvious, because we don't work with those numbers so regularly (pilots don't do a lateral or vertical balance computation before every flight, but mechanics do have to balance planes laterally before weighing them). I just took a glance at the stations in the service and maintenance manual for the PA-28-151/161, and the technical drawings have measurements positive towards the tail in the longitudinal (x) axis and positive upwards in the vertical (Z) axis. In the lateral (y) axis, they use positive in *both* directions (go figure). All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Aerodynamic centre and 3D models
David Megginson wrote: I just took a glance at the stations in the service and maintenance manual for the PA-28-151/161, and the technical drawings have measurements positive towards the tail in the longitudinal (x) axis and positive upwards in the vertical (Z) axis. In the lateral (y) axis, they use positive in *both* directions (go figure). Ah, the mythic ambidexterous coordinate system. Euclid must be rolling in his grave. (For the record: a right handed frame would have +Y pointing out the right wing in such a scheme). Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Aerodynamic centre and 3D models
Jon S Berndt wrote: On Fri, 13 Feb 2004 10:23:56 -0700 Russell Suter [EMAIL PROTECTED] wrote: Jon S Berndt wrote: But then, the FDM still has to report where the FDM is in a common reference frame. Exactly! At my company, we call this the control point and we have standardized on the Empty Weight CG. The 3D model designer will likely have no idea where the empty weight CG is, nor will they often care. Correct. They will draw to an origin based on the data they have. They do know where physical points on the aircraft are, however. Yes, relative to a defined origin. Additionally, the empty weight CG will be a slippery item to standardize on. I don't disagree. I'm not really even advocating it. It's what our aero guys have chosen. Does that mean no fuel? No cargo? nothing? no stores? the C/D model or the A/B model? etc. Correct again. No fuel, cargo, stores. The value may be different between A/B and C/D models. It most certainly is different for the F/A-18 Hornet and Super Hornet. The VRP is a **solid** point of reference. Yes, that is most likely different for each aircraft, No? Maybe I've missed something here but as I understand it, the VRP is an attempt to define a fixed point of reference in the FDM that correlates to the origin of the visual model. I'm not speaking for Andy here, but this is what I'm trying to get across. The VRP is an excellent idea. I know that it can be used to solve the problem. I also know that the cost (for a single instance) is relatively inexpensive. The cost is not even an issue at all. I'm not going to argue this here given the nature of FlightGear and its use. Let me just say that it can be an issue. In the training device I'm currently working on, we have a requirement for 1000 emission sources. and we are scrambling for every last ounce of CPU to meet it. We can get faster CPUs at the cost of changing drawings, documentation, etc. When scaling occurs even the slightest cost snowballs. My point is that it really is unnecessary. If you already have a fixed point reference in the FDM, then use it. Translate the visual model to that point ONCE either by the graphic artist moving the model, or doing it automatically when the model is loaded. Instead of the VRP data being used by the FDM, it becomes meta data for the model. What do you mean metadata for the model Instead of just loading the model file and running with it. FG would load an XML file which describes the model file, and any translations, rotations, scales that need to occure to the model. These operations would be performed once when the model is loaded. So, for the sake of arguement, let's assume that the FDM's fixed control point is decided to be the eyepoint of the pilot in the cockpit. Let's further assume that the model uses the nose as it's origin. When FG starts up, it loads the XML file which defines the .ac file to be loaded and (x,y,z) offsets from the nose to the eyepoint. The .ac file verticies are translated by the (x,y,z) offsets once and from that point on, the visual model and the FDM exactly match. Now think in terms of the F/A-18. The Super Hornet is a larger version of the Hornet. The XML file can also have a scale factor and the visual model can be correctly used for both Hornet and Super Hornet. The order of operation for translate, rotate, and scale would need to be defined up front. This way, the graphic artists can use whatever origin they want based on the data they have. This is already the case! The 3D modeler can and _do_ use any origin they want. They may often know only what the plane ***looks*** like. This is why the VRP is required. There needs to be a common point of reference that both the FDMs (plural) and the 3D *visual* model know about without question. The empty weight CG and the current (dynamic) CG is **not** it. I absolutely agree. But, there's more to this than simply getting the visual models to correctly align with the FDM. There are also potential view points that too are fixed. For instance a mounted camera, a maverick missile camera on a rail. Are you going to calculate VRP's for these too? There can be pilot eyepoint, copilot eyepoint, jump seat eyepoint, etc. As long as the FDM reports **one** fixed point relative to the aircraft, all other items can be **easily** made to conform to that point. Ideally, all FDMs would use the same point. -- 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] Aerodynamic centre and 3D models
On Freitag, 13. Februar 2004 20:53, Russell Suter wrote: point. Ideally, all FDMs would use the same point. Ideally this point is configurable. Greetings Mathias -- Mathias Fröhlich, email: [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Aerodynamic centre and 3D models
Jon S Berndt wrote: On Fri, 13 Feb 2004 08:22:15 -0800 Andy Ross [EMAIL PROTECTED] wrote: Jon S. Berndt wrote: Can the view offset or rendering code (whatever it is that draws the 3D aircraft models) move the origin of the set of vertices that defines the model per-frame so that the CG aligns with that reported by the FDM? Well, yes, because they're just properties. But unless I misunderstand you, you don't want to do that. The FDM reports the lat/lon/alt of the aircraft coordinate origin, not the c.g., no? Andy No. JSBSim currently (the version in in FlightGear, anyhow), reports the position of the CG, since that is what the EOM natively tracks, anyhow. We can *report* anything, though of course, as we have intimate knowledge of euler angles, CG position, and offset from the CG (dynamic) to any other point on the aircraft at any time. So then the pilot's eyepoint is relative to the dynamic CG? I guess I just assumed JSBSim reported a position from a fixed point on the aircraft. Ack! Would your VRP then become the point from which the pilot's eyepoint is derived? -- 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] Aerodynamic centre and 3D models
On Fri, 13 Feb 2004 13:09:30 -0700 Russell Suter [EMAIL PROTECTED] wrote: So then the pilot's eyepoint is relative to the dynamic CG? I guess I just assumed JSBSim reported a position from a fixed point on the aircraft. Ack! Would your VRP then become the point from which the pilot's eyepoint is derived? All JSBSim points are defined in structural frame (including the VRP). All of these are fixed in that frame except the CG - which may move as fuel burns off. This is another reason why the VRP is reported. The offset from the VRP to the JSBSim eyepoint is constant. The JSBSim pilot eyepoint isn't used by flightgear, though. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Aerodynamic centre and 3D models
On Fri, 13 Feb 2004 12:53:45 -0700 Russell Suter [EMAIL PROTECTED] wrote: The VRP is a **solid** point of reference. Yes, that is most likely different for each aircraft, No? Maybe I've missed something here but as I understand it, the VRP is an attempt to define a fixed point of reference in the FDM that correlates to the origin of the visual model. Not necessarily to the origin. The 3D modeler may choose not to make the nose tip the origin. It could not matter, as long as everyone understands that the VRP refers to the nose tip, and by convention the 3D modeler also knows that, so the rendering code would do whatever it needs to do ... The XML file can also have a scale factor and the visual model can be correctly used for both Hornet and Super Hornet. The order of operation for translate, rotate, and scale would need to be defined up front. This might not be a bad idea, but I'm not a rendering guy. I absolutely agree. But, there's more to this than simply getting the visual models to correctly align with the FDM. There are also potential view points that too are fixed. For instance a mounted camera, a maverick missile camera on a rail. Are you going to calculate VRP's for these too? There can be pilot eyepoint, copilot eyepoint, jump seat eyepoint, etc. As long as the FDM reports **one** fixed point relative to the aircraft, all other items can be **easily** made to conform to that point. Ideally, all FDMs would use the same point. I think so, too. As far as calculating viewpoints for missiles, etc. this would come naturally. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Aerodynamic centre and 3D models
Russell Suter [EMAIL PROTECTED] said: Jon S Berndt wrote: On Fri, 13 Feb 2004 08:22:15 -0800 Andy Ross [EMAIL PROTECTED] wrote: Jon S. Berndt wrote: Can the view offset or rendering code (whatever it is that draws the 3D aircraft models) move the origin of the set of vertices that defines the model per-frame so that the CG aligns with that reported by the FDM? Well, yes, because they're just properties. But unless I misunderstand you, you don't want to do that. The FDM reports the lat/lon/alt of the aircraft coordinate origin, not the c.g., no? Andy No. JSBSim currently (the version in in FlightGear, anyhow), reports the position of the CG, since that is what the EOM natively tracks, anyhow. We can *report* anything, though of course, as we have intimate knowledge of euler angles, CG position, and offset from the CG (dynamic) to any other point on the aircraft at any time. So then the pilot's eyepoint is relative to the dynamic CG? I guess I just assumed JSBSim reported a position from a fixed point on the aircraft. Ack! Would your VRP then become the point from which the pilot's eyepoint is derived? That's the whole idea. The only real change is JSBSim will now be reporting aircraft position from a fixed location on the aircraft. Jon, I forget, what exactly is the reason for defining a VRP in the config file? I thought that JSBSim already knew where the nose was. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Aerodynamic centre and 3D models
On Fri, 13 Feb 2004 20:30:35 - Jim Wilson [EMAIL PROTECTED] wrote: Jon, I forget, what exactly is the reason for defining a VRP in the config file? I thought that JSBSim already knew where the nose was. We normally track: - Initial empty weight CG - Dynamic CG (includes fuel burnoff) - landing gear ground contact points - scrape points - pilot eyepoint (for calculating pilot accels for motion base systems and instruments) and now, - the Visual Reference Point (tm) The VRP is what is returned to JSBSim.cxx (FGJSBsim == FGInterface) But, as discussed, this has not been given the final push into operations, yet. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Aerodynamic centre and 3D models
On Fri, 13 Feb 2004 20:30:35 - Jim Wilson [EMAIL PROTECTED] wrote: Jon, I forget, what exactly is the reason for defining a VRP in the config file? I thought that JSBSim already knew where the nose was. Also, Jim: will the view code be able to place a 3D model correctly no matter what the FDM is? I mean, if I have a 747 model, and an A-4, for instance, does that make things difficult? Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Aerodynamic centre and 3D models
Jon S Berndt [EMAIL PROTECTED] said: On Fri, 13 Feb 2004 20:30:35 - Jim Wilson [EMAIL PROTECTED] wrote: Jon, I forget, what exactly is the reason for defining a VRP in the config file? I thought that JSBSim already knew where the nose was. Also, Jim: will the view code be able to place a 3D model correctly no matter what the FDM is? I mean, if I have a 747 model, and an A-4, for instance, does that make things difficult? Not any differently than it would now. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Aerodynamic centre and 3D models
Jon S Berndt [EMAIL PROTECTED] said: On Fri, 13 Feb 2004 20:30:35 - Jim Wilson [EMAIL PROTECTED] wrote: Jon, I forget, what exactly is the reason for defining a VRP in the config file? I thought that JSBSim already knew where the nose was. We normally track: - Initial empty weight CG - Dynamic CG (includes fuel burnoff) - landing gear ground contact points - scrape points - pilot eyepoint (for calculating pilot accels for motion base systems and instruments) and now, - the Visual Reference Point (tm) The VRP is what is returned to JSBSim.cxx (FGJSBsim == FGInterface) So is the VRP what we see as lon/lat/alt? If not, then what does it look like? If it is, then what do we need to change in the JSBSim config files? Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Aerodynamic centre and 3D models
Jon, I forget, what exactly is the reason for defining a VRP in the config file? I thought that JSBSim already knew where the nose was. In JSBSim the locations of things along the longitudinal (X) axis are defined in the configuration file based on an arbitrary point on this axis. The point is arbitrary in the sense that the user can pick any point. The point can have meaning elsewhere, or it can be meaningless - doesn't matter. For instance, the Cessna 172p configuration has the origin at the firewall, resulting in the engine's and prop's x-locations being negative numbers. I believe this spot was chosen because it used elsewhere in actual C-172 documents. Most often we use the nose as the origin, because it's easy to find, and seems natural in that no negative numbers appear. Since we usually use the nose as our origin, then the location of the VRP will be [0, 0, 0] in most cases. In the case of the C-172P config, the VRP will be at about [-40, 0, 26]. Dave -- David Culp davidculp2[at]comcast.net ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Aerodynamic centre and 3D models
David Culp [EMAIL PROTECTED] said: Jon, I forget, what exactly is the reason for defining a VRP in the config file? I thought that JSBSim already knew where the nose was. In JSBSim the locations of things along the longitudinal (X) axis are defined in the configuration file based on an arbitrary point on this axis. The point is arbitrary in the sense that the user can pick any point. The point can have meaning elsewhere, or it can be meaningless - doesn't matter. For instance, the Cessna 172p configuration has the origin at the firewall, resulting in the engine's and prop's x-locations being negative numbers. I believe this spot was chosen because it used elsewhere in actual C-172 documents. Most often we use the nose as the origin, because it's easy to find, and seems natural in that no negative numbers appear. Since we usually use the nose as our origin, then the location of the VRP will be [0, 0, 0] in most cases. In the case of the C-172P config, the VRP will be at about [-40, 0, 26]. Ah ok. The VRP needs to be set so that JSBSim knows where the lon/lat/alt should be reported at (i.e. where the nose is when the FDM origin is not the nose). So this basically avoids refiguring all the locations in the JSBSim configs. Right? Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Aerodynamic centre and 3D models
Jon S Berndt wrote: On Fri, 13 Feb 2004 20:30:35 - Jim Wilson [EMAIL PROTECTED] wrote: Jon, I forget, what exactly is the reason for defining a VRP in the config file? I thought that JSBSim already knew where the nose was. We normally track: - Initial empty weight CG - Dynamic CG (includes fuel burnoff) - landing gear ground contact points - scrape points - pilot eyepoint (for calculating pilot accels for motion base systems and instruments) and now, - the Visual Reference Point (tm) The VRP is what is returned to JSBSim.cxx (FGJSBsim == FGInterface) Although I strongly agree that JSBSim reporting a fixed point relative to the aircraft is good, I'm not particularly thrilled with the point you have chosen. I am more than happy to agree to disagree on that one though. But, as discussed, this has not been given the final push into operations, yet. Certainly don't let my prattling stop you... ;-) -- 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] Aerodynamic centre and 3D models
On Fri, 13 Feb 2004 21:25:42 - Jim Wilson [EMAIL PROTECTED] wrote: Jon S Berndt [EMAIL PROTECTED] said: We normally track: - Initial empty weight CG - Dynamic CG (includes fuel burnoff) - landing gear ground contact points - scrape points - pilot eyepoint (for calculating pilot accels for motion base systems and instruments) and now, - the Visual Reference Point (tm) The VRP is what is returned to JSBSim.cxx (FGJSBsim == FGInterface) So is the VRP what we see as lon/lat/alt? If not, then what does it look like? If it is, then what do we need to change in the JSBSim config files? Let me clear up something said in an earlier email (by David Culp): I don't recall what the structural frame is for most of our aircraft - but I don't think they have their origins at the nose neccesarily. Although, it doesn't matter. JSBSim reports a lat/lon/alt. Our recent changes will make it the lat/lon/alt of the VRP. It accounts for the offset from the CG and rotation of the aircraft, so that if you place the nose of the aircraft at this spot, all will be well. Given each JSBSim aircraft config file, we will need to add the AC_VRP ### entry to each aircraft file. This may take some measuring ... may take some figuring. The location of the gear will alreay be there, as will the locations of scrape points (in some cases), the location of the eyepoint, etc. So, we ought to be able to figure the location of the nose tip in JSBSim structural coordinates. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Aerodynamic centre and 3D models
On Fri, 13 Feb 2004 14:33:43 -0700 Russell Suter [EMAIL PROTECTED] wrote: Although I strongly agree that JSBSim reporting a fixed point relative to the aircraft is good, I'm not particularly thrilled with the point you have chosen. I am more than happy to agree to disagree on that one though. Just out of curiousity, which point would you favor -- given that we have multiple FDMs, and model various aircraft, for which there are various modelers who may have no clue about where the CG is? Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Aerodynamic centre and 3D models
Jon S Berndt wrote: On Fri, 13 Feb 2004 14:33:43 -0700 Russell Suter [EMAIL PROTECTED] wrote: Although I strongly agree that JSBSim reporting a fixed point relative to the aircraft is good, I'm not particularly thrilled with the point you have chosen. I am more than happy to agree to disagree on that one though. Just out of curiousity, which point would you favor -- given that we have multiple FDMs, and model various aircraft, for which there are various modelers who may have no clue about where the CG is? Well, Jon, I think you already know the answer to that question. The way you phrase it though implies that I somehow believe that the modeler (aka. graphic artist) must know where the CG is. That is not the case. But, I do believe it is better to match the model to the FDM, and not the other way around. I also believe that the Image Generation software is the best tool for the job. The IG already has the ability to translate the model anywhere. That's how it moves the model through the scene. The IG has the ability to set viewpoint offsets from any reference point. That's how you can get certain chase views. In fact, when you implement the VRP, I suspect some of these offsets (like the pilot's eyepoint) will need to be adjusted to match the new reference location which will move forward significantly. My preference is the empty weight CG. Every plane has one. It is aerodynamically significant. Its already tracked. Its independent of any model. The method I've described previously doesn't require a modeler to model to that point either. And, everything in the visual world can be made to effectively use it. In your example of the 747 model with the A4 FDM, the 747 should appear to pitch about it's nose. If you switch them around, and have an A4 model with a 747 FDM, it will appear that the model's pitch is significantly aft of the model -- like on being manipulated by a stick. If you used the empty weight CG, in both instances, the models would appear closer to normal. -- 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] Aerodynamic centre and 3D models
On Fri, 13 Feb 2004 16:52:12 -0700 Russell Suter [EMAIL PROTECTED] wrote: Well, Jon, I think you already know the answer to that question. The You probably answered that several times, but I didn't catch it in your email. way you phrase it though implies that I somehow believe that the modeler (aka. graphic artist) must know where the CG is. That is not the case. But, I do believe it is better to match the model to the FDM, and not the other way around. I also We are not really matching the FDM *to* anything. We can report any reference point with ease, and are just giving the location of the reference point that makes it easiest for agreeable placement of the 3D model. Using the empty weight CG would not make the FDM's job any easier. Remember, the CG moves as time goes on and fuel burns off, stores are dropped, etc. It's conceivable that the fuel could be burned off of one wing tank only, which would really skew the CG. The view code will still have a 3D model with an origin at the original (empty) CG, but the FDM will be reporting a location that is perhaps several feet off to one side. So, the solution to that is that instead of the FDM calculating the offset to the VRP, the offset to the empty weight CG is calculated and reported to FlightGear instead. Very well. Yes, that would work. However, it assumes that the 3D modeler is going to know where the empty weight CG is. Otherwise, how will the modeler know where to place the origin? You seem to say that it doesn't matter, that we will just use metadata to relate the CG (which the FDM designer knows about) to the 3D model origin (which the modeler knows about), but that will require that one or both people will need to know both things about a model. I don't see any advantage to your approach. In this case we decided to use the VRP after debating it for a very looong time (and considering many of the same points you bring up here). In this case, the FDM designer only needs to know about what an FDM designer always knows about PLUS where the nose of the aircraft is. Easy. The 3D modeler only needs to know about what a 3D modeler knows about PLUS where the nose is. It's sort of like object-oriented design, with encapsulation. Or, like navigation: you and I don't know where each other are, but we could both meet in Chicago. As for using an A4 FDM with a 747 model or whatever, that's a red herring. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Aerodynamic centre and 3D models
Jon S Berndt wrote: Given each JSBSim aircraft config file, we will need to add the AC_VRP ### entry to each aircraft file. No, let's not do that -- instead, let FlightGear pass the VRP through the JSBSim API. That way, we can use different 3D models with the same flight model. All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Aerodynamic centre and 3D models
David Megginson [EMAIL PROTECTED] said: Jon S Berndt wrote: Given each JSBSim aircraft config file, we will need to add the AC_VRP ### entry to each aircraft file. No, let's not do that -- instead, let FlightGear pass the VRP through the JSBSim API. That way, we can use different 3D models with the same flight model. Doesn't this get back to the 3D Modeler having to know where the FDM's origin is? If that is the case, why pass anything at all? If I understand correctly, all the AC_VRP does is ensure that the lon/lat/alt is reported at the nose. You can position _any_ 3D model in relation to that location however you like with the model offsets. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Aerodynamic centre and 3D models
If I understand correctly, all the AC_VRP does is ensure that the lon/lat/alt is reported at the nose. You can position _any_ 3D model in relation to that location however you like with the model offsets. Jim Yes. For JSBSim only we will know where our published VRP is at any time. This just gave me an idea, though: will we need to give any other points, such as the altitude a radar altimeter (attached to the aircraft in some avionics bay) reports? Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Aerodynamic centre and 3D models
Jon S Berndt wrote: Given each JSBSim aircraft config file, we will need to add the AC_VRP ### entry to each aircraft file. No, let's not do that -- instead, let FlightGear pass the VRP through the JSBSim API. That way, we can use different 3D models with the same flight model. That _absolutely_ defeats the whole purpose. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Aerodynamic centre and 3D models
Uncle! Jon S Berndt wrote: I don't see any advantage to your approach. By your responses, you give me no indication that you even understand what I'm saying. I seem to be alone in my dissent anyway... What you are planning will work just fine. -- 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] Aerodynamic centre and 3D models
Jon Berndt wrote: No, let's not do that -- instead, let FlightGear pass the VRP through the JSBSim API. That way, we can use different 3D models with the same flight model. That _absolutely_ defeats the whole purpose. I don't see that. What is the benefit of a configurable VRP at all, if the 3D modeller cannot set it in the XML config file for the model? In that case, you might as well just report the 0,0,0 point, as Jim suggests. On that point, though, I'm still not sure that the nose is a good, standard reference point -- I think that the leading edge of the wing at the wing root might be better for fixed-wing aircraft, though I don't know what to suggest for helicopters. For example, the propeller spinner is required on the Cherokee, so it counts as part of the nose proper; on other aircraft, the spinner is optional, so it does not count as part of the nose. Ditto for sensing booms projecting forward from the nose. It is also possible that there are aircraft where the nacelles project further forward than the nose, though I cannot think of one offhand. All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Aerodynamic centre and 3D models
Uncle! Jon S Berndt wrote: I don't see any advantage to your approach. By your responses, you give me no indication that you even understand what I'm saying. Playing dumb has never been so effective. ;-) It's been a very arduous set of discussions over time, so I'm game to take the Nike approach and Just Do It. I did _think_ I understood what you were saying, though, and still wish I understood your approach. But I've had a very long week and maybe I'm just brain dead today. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Aerodynamic centre and 3D models
I don't see that. What is the benefit of a configurable VRP at all, if the 3D modeller cannot set it in the XML config file for the model? Aaargh! It's the FDM's item to configure. See below. In that case, you might as well just report the 0,0,0 point, as Jim suggests. This would require that the visual modeler have access to the flight dynamics model (in our case, for instance, c172.xml). What if the flight model does not exist yet (someone's got to be first). The VRP is an agreed-upon point - a convention - that the flight modeler and the 3D modeler can be assured will give correct placement. The flight modeler and the 3D modeler don't even need to _know_ each other in this case. They can exist in different worlds. There's _got_ to be some kind of convention here, because the flight modeler (for us) defines things in structural coordinates of which the 3D modeler will likely have NO knowledge of before building a 3D model. It boils down to this: The flight modeler and the 3D modeler will have different base coordinate frames of importance. The obvious choice of common origin - the CG - floats, so that's out. There then must be a registration mark that the two worlds can agree on that will allow seamless overlay. IIRC, YASim provides for the origin at the nose tip too (or something close to that). JSBSim can provide that, and I (and others) have proposed that the tip of the nose is as good a convention as any. As far as a problem with the spinner missing: gimme a break. There are always going to be special cases. The 3D modeler can remove the spinner if they want to to provide a realistic model leave the origin where it was or would be _with_ a spinner. We've got a chance to make progress, the code is there, I want to move this forward and move onto something else. If it ends up being a loser approach, we can change it then, with some experience to back us up. I'm sick to death of rehashing this. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Aerodynamic centre and 3D models
David Megginson [EMAIL PROTECTED] said: Jon Berndt wrote: No, let's not do that -- instead, let FlightGear pass the VRP through the JSBSim API. That way, we can use different 3D models with the same flight model. That _absolutely_ defeats the whole purpose. I don't see that. What is the benefit of a configurable VRP at all, if the 3D modeller cannot set it in the XML config file for the model? In that case, you might as well just report the 0,0,0 point, as Jim suggests. On that point, though, I'm still not sure that the nose is a good, standard reference point -- I think that the leading edge of the wing at the wing root might be better for fixed-wing aircraft, though I don't know what to suggest for helicopters. For example, the propeller spinner is required on the Cherokee, so it counts as part of the nose proper; on other aircraft, the spinner is optional, so it does not count as part of the nose. Ditto for sensing booms projecting forward from the nose. It is also possible that there are aircraft where the nacelles project further forward than the nose, though I cannot think of one offhand. Actually when I say 0,0,0 I meant the same thing as the VRP. The VRP performs the same function as 0,0,0 in YASim coordinates (defines specific locaton of lon/lat/alt). VRP is only used by JSBsim to identify where the nose is. The issue of booms, etc was discussed here about two or three weeks ago. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Aerodynamic centre and 3D models
Jon Berndt wrote: so I'm game to take the Nike approach and Just Do It. That's probably wise. I did _think_ I understood what you were saying, though, and still wish I understood your approach. I think it better that I scrape up some time somehow and implement the meta file approach. It's easier to show than to tell -- especially to one not familiar with IG software. What you are planning will correct (what I believe is a major) problem. That, right now, is more important. The other bad part is I'm really late in the game. It has only been reciently that I've begun to view FlightGear as more than just a video game... All the best, Over, and out! -- 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] Aerodynamic centre and 3D models
Russell Suter writes: Jon S Berndt wrote: I don't see any advantage to your approach. By your responses, you give me no indication that you even understand what I'm saying. I seem to be alone in my dissent anyway... What you are planning will work just fine. Russell You are not alone :-) Your position is, to some of us, the 'obvious' one but we all seem to end up crying Uncle since anything can be made to work .. Curiously looking forward to the kludges in the code in future code modules to adjust the radar displays for other aircraft locations :-) Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Aerodynamic centre and 3D models
On Thu, 12 Feb 2004 15:09:15 -0500 David Megginson [EMAIL PROTECTED] wrote: So, given that the aerodynamic centre of an aircraft can shift based on loading and flight conditions, how can we report that from the FDM back to the 3D model code? Is this something people worked out in a previous thread? I'm assuming that the 3D model and the FDM config file are using the same reference datum for coordinates. First, the aircraft - like any body - rotates about its CG (according to the EOM) - not usually the same as the AC. JSBSim made a change recently that is likely not yet in FlightGear CVS. The lat/lon/alt position now reported by JSBSim (CVS) is the position of the VRP (Visual Reference Point) - i.e. the tip of the prop hub (or similar nose tip location on non-prop aircraft). As long as the aircraft is placed in the scene so that the nose of the 3D model falls at the location reported by JSBSim - everything works out. This assumes that the aircraft model is defined using the correct English units - because all points that the FDM is concerned with are measured in the structural frame and in inches. Yes, we have gone over this ad nauseum in the past. :-) Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Aerodynamic centre and 3D models
Jon S Berndt wrote: JSBSim made a change recently that is likely not yet in FlightGear CVS. The lat/lon/alt position now reported by JSBSim (CVS) is the position of the VRP (Visual Reference Point) - i.e. the tip of the prop hub (or similar nose tip location on non-prop aircraft). As long as the aircraft is placed in the scene so that the nose of the 3D model falls at the location reported by JSBSim - everything works out. I'm not sure I see how this helps -- the model code still doesn't know where the CG is, so it still doesn't know where the centre of rotation for the model should be. All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Aerodynamic centre and 3D models
On Thu, 12 Feb 2004 15:35:59 -0500 David Megginson [EMAIL PROTECTED] wrote: Jon S Berndt wrote: I'm not sure I see how this helps -- the model code still doesn't know where the CG is, so it still doesn't know where the centre of rotation for the model should be. This is precisely *why* the nose is used as a reference point. If the scene graph (is that the right term/subsystem?) places the aircraft at the spot reported by JSBSim -- that is, where JSBSim says the nose of the aircraft is -- the perceived CG of the 3D aircraft as viewed in the scene will fall exactly in the spot that the FDM says it should be at. Look at it this way: the FDM tracks the motion of the CG, and the rotation of the aircraft about the CG. The FDM knows teh location of the CG at any point in time, as well as the euler angles of the aircraft at that point in time. If we were to report the location of this CG to FlightGear, and IF the origin of the 3D model was allowed to shift (by some magic) and always be coincident with the virtual CG in the 3D model, then we'd all always be happy and everything would match up fine. The problem is, the CG shifts and the 3D model coordinate system can't. Since the FDM knows (or can calculate) where the nose is at all times, we simply report the nose location to FlightGear, and by convention FlightGear places the 3D model's nose at the point reported by JSBSim - the CG falls into place as needed IFF the 3D model is defined (or scaled/rotated/translated in the scene graph) correctly as described previously. Takeoffs and landings would look fine, etc. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Aerodynamic centre and 3D models
Hello all, Just a few comments from a sideline observer following the discussion for many months. Jon seems to be providing a point representing a vector from the current (dynamic) CG to an agreed point in space where the plane nose is expected. If this vector is updated regularly both in magnitude ( fuel burn change of CG, etc) and direction (pitch and yaw in a real-world reference), the model nose is drawn at the VRP each frame, and the model orientation tracks the matching pitch and yaw, the center of the model should stay matched to the CG the FDM uses. Now how do you determine which step in the above assumptions is failing? -- Bill Earnest [EMAIL PROTECTED] Linux Powered Allentown, PA, USA Computers, like air conditioners, work poorly with Windows open. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Aerodynamic centre and 3D models
David Megginson [EMAIL PROTECTED] said: OK, everyone, here's the problem. I tested watching the PA28-161 from a fixed point on the ground, and it does, in fact pivot around its nose still. Maybe not. Your cvs log shows that you did not make the target offset correction for the tower views only the view n=1 chase view. See the p51d config. The problem is that the model code gets the roll/pitch/yaw from the FDM and then applies it to the 0,0,0 point in the 3D model, which happens to be the tip of the spinner for the Warrior (as it is in the weight-and-balance section of the POH). YASim isn't doing anything wrong; the model code just doesn't know where the aerodynamic centre of the model is, so it doesn't know what point to rotate the plane around. With Jim's suggested patch, the camera rotates with the plane in the chase views, so it *looks* like the plane is rotating in the right place, but it is not. Well the patch is necessary always. Unless the origins are defined at the aerodynamic center (an ambiguous location). So, given that the aerodynamic centre of an aircraft can shift based on loading and flight conditions, how can we report that from the FDM back to the 3D model code? Is this something people worked out in a previous thread? I'm assuming that the 3D model and the FDM config file are using the same reference datum for coordinates. Ah ok. Sorry folks. This is _a_ problem: fuselage ax=0.5 ay=0 az=0 bx=-7.75 by=0 bz=0 width=1.5 taper=0.2 midpoint=0.3/ To make this work both the FDM origin (where lon/lat/alt are reported at) and the 0,0,0 origin of the 3D model should be the nose. If you do that, then all will be fine. In this case you've got the origin a half meter back in the FDM and the 3D model is 0,0,0 at tip of nose cone. Visually the error is probably barely noticable. Please keep this simple. It is exactly as it needs to be. FWIW I fought Andy on this issue (didn't believe him either) a while back. Then all of a sudden a light came on and I got it. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Aerodynamic centre and 3D models
David Megginson [EMAIL PROTECTED] said: Jon S Berndt wrote: JSBSim made a change recently that is likely not yet in FlightGear CVS. The lat/lon/alt position now reported by JSBSim (CVS) is the position of the VRP (Visual Reference Point) - i.e. the tip of the prop hub (or similar nose tip location on non-prop aircraft). As long as the aircraft is placed in the scene so that the nose of the 3D model falls at the location reported by JSBSim - everything works out. I'm not sure I see how this helps -- the model code still doesn't know where the CG is, so it still doesn't know where the centre of rotation for the model should be. The distance between any two vertices of a 3D model stays the same when you pitch the aircraft. For example: if you subtract the forward most vertext at the root of the left wing, from the vertext at the tip of the nose cone, you will always get the same X,Y,Z dimmension. No matter what the attitude of the aircraft is. That is why the model code does not need to know where the CG is. The 3D model designer does need to know the FDM origin or reference point or whatever you want to call the vertex in space at which the FDM reports the lon/lat/alt of the aircraft. So if she puts the origin of the model (0,0,0) in that place, the 3D model will rotate correctly. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Aerodynamic centre and 3D models
On Thu, 12 Feb 2004 21:19:25 - Vivian Meazza [EMAIL PROTECTED] wrote: Jon S Berndt tells us First, the aircraft - like any body - rotates about its CG (according to the EOM) - not usually the same as the AC. So put the (visual) model origin at or near the CofG - what's the problem? Seems to work OK in practice. Really confused now That is certainly one solution. Then define the VRP in the JSBSim config file (for JSBSim aircraft - I don't know how YASim does this), as coincident with the CG. Then, build your 3D model with the origina at the CG. HOWEVER: when the CG moves due to leanding gear deployment, or dropping loads, or fuel burnoff, the vehicle will rotate about the wrong point, eventually. It won't be real noticeable, but it will be there. That's why we provide the capability for both the 3D model designer and the FDM designer to agree on a common visual reference point, and things can be made much more accurate and allow for dynamic effects. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Aerodynamic centre and 3D models
Vivian Meazza wrote: So put the (visual) model origin at or near the CofG - what's the problem? Seems to work OK in practice. It depends on the aircraft. A light trainer like the Piper Cherokee or the Cessna 172 typically allows only about a foot of variation in the location of the CG along the longitudinal axis (though, unfortunately, pilots often exceed that). That's enough to show up visually, but only just barely -- the main place it would be noticable would be landing with the nosewheel low. A big airliner, on the other hand, can have a CG variation much larger, and that might be very noticeable. If we're going to solve this problem for the 747, we might as well solve it for the 172 the same way. All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Aerodynamic centre and 3D models
Jim Wilson wrote: That is why the model code does not need to know where the CG is. The 3D model designer does need to know the FDM origin or reference point or whatever you want to call the vertex in space at which the FDM reports the lon/lat/alt of the aircraft. So if she puts the origin of the model (0,0,0) in that place, the 3D model will rotate correctly. Thanks -- your explanation and Jon's has made it all clear, and the discussion has been useful. So, as far as I understand, JSBSim supports this in JSBSim CVS but not yet in FlightGear. Does YASim support setting the reference point yet? All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Aerodynamic centre and 3D models
David Megginson [EMAIL PROTECTED] said: Jim Wilson wrote: That is why the model code does not need to know where the CG is. The 3D model designer does need to know the FDM origin or reference point or whatever you want to call the vertex in space at which the FDM reports the lon/lat/alt of the aircraft. So if she puts the origin of the model (0,0,0) in that place, the 3D model will rotate correctly. Thanks -- your explanation and Jon's has made it all clear, and the discussion has been useful. So, as far as I understand, JSBSim supports this in JSBSim CVS but not yet in FlightGear. Does YASim support setting the reference point yet? Yes. In YASim, the 0,0,0 of the fuselage property is the origin. So if ax=0, ay=0, az=0 is used then the nose is origin in YASim. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Aerodynamic centre and 3D models
On Donnerstag, 12. Februar 2004 22:37, David Megginson wrote: Thanks -- your explanation and Jon's has made it all clear, and the discussion has been useful. So, as far as I understand, JSBSim supports this in JSBSim CVS but not yet in FlightGear. Does YASim support setting the reference point yet? Even JSBSim CVS does not support this visual reference point yet. There is a patch pending in Jon's mailbox to report the visual reference point to flightgear and define a reference point in each JSBSim aircraft config. Also there is a bugfix which is required to make the VRP patch work correct. This one is in JSBSim cvs but I believe did not yet find the way into fightgear. Greetings Mathias -- Mathias Fröhlich, email: [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Aerodynamic centre and 3D models
On Donnerstag, 12. Februar 2004 23:11, Jon S Berndt wrote: ?? I thought I had already committed these. You might want to double check. In any case, I already committed to CVS the code that reports the VRP, as well as to make the corrections to the transforms (as you pointed out). These are committed. However, in JSBSim.cxx, the relevant code *may* still be commented out, Yes, this is definitly missing. waiting for the VRP specification in the aircraft models. It's a matter of timing, I think; we need to get everything together, then submit it. But, I think this will require work for the 3D model, too. ? This stuff was also included in the patch. I put the visual reference point at dynamic center of gravity at initialization time. This choice fits well for the models we have in jsbsim cvs. Are there additional models in flightgear? Greetings Mathias -- Mathias Fröhlich, email: [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Aerodynamic centre and 3D models
Jim Wilson wrote: Yes. In YASim, the 0,0,0 of the fuselage property is the origin. So if ax=0, ay=0, az=0 is used then the nose is origin in YASim. It would be nice to be able to specify the point in YASim as well, so we don't have to physically alter the models. For the PA-28-161, though, I'll just have to move the model down a little bit. All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Aerodynamic centre and 3D models
On Thu, 2004-02-12 at 12:53, Jon S Berndt wrote: On Thu, 12 Feb 2004 15:35:59 -0500 David Megginson [EMAIL PROTECTED] wrote: Jon S Berndt wrote: I'm not sure I see how this helps -- the model code still doesn't know where the CG is, so it still doesn't know where the centre of rotation for the model should be. This is precisely *why* the nose is used as a reference point. If the scene graph (is that the right term/subsystem?) places the aircraft at the spot reported by JSBSim -- that is, where JSBSim says the nose of the aircraft is -- the perceived CG of the 3D aircraft as viewed in the scene will fall exactly in the spot that the FDM says it should be at. Look at it this way: the FDM tracks the motion of the CG, and the rotation of the aircraft about the CG. The FDM knows teh location of the CG at any point in time, as well as the euler angles of the aircraft at that point in time. If we were to report the location of this CG to FlightGear, and IF the origin of the 3D model was allowed to shift (by some magic) and always be coincident with the virtual CG in the 3D model, then we'd all always be happy and everything would match up fine. The problem is, the CG shifts and the 3D model coordinate system can't. Since the FDM knows (or can calculate) where the nose is at all times, we simply report the nose location to FlightGear, and by convention FlightGear places the 3D model's nose at the point reported by JSBSim - the CG falls into place as needed IFF the 3D model is defined (or scaled/rotated/translated in the scene graph) correctly as described previously. And said nose location *includes* any translation the nose experiences due to the aircraft rotating about the cg. In other words, if you could move the aircraft such that only the pitch angle changes (not terribly real, but humor me) and that pitch angle change results in the nose rising 10 feet, then the FDM reports the nose location as the CG altitude + 10 feet. So now, if the 3D model code positions the nose of the aircraft at that location and pitches it to the corresponding angle, the CG will not have moved at all but the nose will. And that means that the model will appear to rotate around the CG, just like it should (in free air, at least. On the ground is a different thing) Takeoffs and landings would look fine, etc. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel -- Tony Peden [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Aerodynamic centre and 3D models
David Megginson wrote: Thanks -- your explanation and Jon's has made it all clear, and the discussion has been useful. So, as far as I understand, JSBSim supports this in JSBSim CVS but not yet in FlightGear. Does YASim support setting the reference point yet? I'm not sure exactly what this is for. I can (and probably should) export the C.G. position for the view code to use appropriately. But the VRP stuff seems like a double-correction. It's basically identical to the view center offset stuff, isn't it? Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Aerodynamic centre and 3D models
Andy Ross wrote: I'm not sure exactly what this is for. I can (and probably should) export the C.G. position for the view code to use appropriately. But the VRP stuff seems like a double-correction. It's basically identical to the view center offset stuff, isn't it? It's the location on the plane where the FDM reports the lon/lat/alt. It's kind-of a nifty idea, actually. All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Aerodynamic centre and 3D models
David Megginson [EMAIL PROTECTED] said: Andy Ross wrote: I'm not sure exactly what this is for. I can (and probably should) export the C.G. position for the view code to use appropriately. But the VRP stuff seems like a double-correction. It's basically identical to the view center offset stuff, isn't it? It's the location on the plane where the FDM reports the lon/lat/alt. It's kind-of a nifty idea, actually. In relation to? It is always 0,0,0 in Yasim. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Aerodynamic centre and 3D models
David Megginson [EMAIL PROTECTED] said: It's the location on the plane where the FDM reports the lon/lat/alt. It's kind-of a nifty idea, actually. In relation to? It is always 0,0,0 in Yasim. Best, Jim JSBSim could also define the tip of the nose as (0,0,0). It really doesn't matter a whole lot. However, internally, the FDMs really don't care about exact locations - only relative distances. I think we all agree on that. So, instead of defining some arbitrary frame, _we_use_an_industry_standard_, which is the structural frame that the manufacturer defines, when available. It is always (in my experience) X positive aft, Y positive right, with the origin being seemingly arbitrary. For us, that solution works great and is very appropriate. When the frame is not known, we could just as easily decide that the origin could be at the nose tip. In any case, given the potential variances in structural coordinate frames - and especially considering that there are many FDMs, the 3D model placement code needs to be able to match up with the FDM. I think our VRP solution works well, and is versatile given our situation. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Aerodynamic centre and 3D models
David Megginson wrote: Andy Ross wrote: I'm not sure exactly what this is for. I can (and probably should) export the C.G. position for the view code to use appropriately. But the VRP stuff seems like a double-correction. It's basically identical to the view center offset stuff, isn't it? It's the location on the plane where the FDM reports the lon/lat/alt. It's kind-of a nifty idea, actually. True, but... This is a chunk of calculations running every frame. In the olden days, the cost would be too high. Our Aerodynamic modelers always seemed to know where the empty weight CG was every frame without additional calculations. That said, we made the graphic artists translate the visual model such that the 0,0,0 point for the model was the empty weight CG. This operation was done once. We were always able to put those spare calculations to good use adding fidelity elsewhere. Realize that I don't have a dog in this fight. I'm just conveying a bit of simulation history. It's up to you folks to decide what to do with the blessings of Moore's law... :-) -- Russ Conway's Law: The structure of a system tends to mirror the structure of the group producing it. -- Mel Conway Datamation (1968) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Aerodynamic centre and 3D models
True, but... This is a chunk of calculations running every frame. In the olden days, the cost would be too high. These days, it's not even a spec on a flea on the butt of an elephant in terms of the overall FDM calculations - which in turn are not much of a spec on a flea in the overall FlightGear calculations. Our Aerodynamic modelers always seemed to know where the empty weight CG was every frame without additional calculations. That's not the issue, though. We FDM guys know absolutely where everything is at all times within the FDMs. Jon -- Project Coordinator JSBSim Flight Dynamics Model http://www.jsbsim.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Aerodynamic centre and 3D models
On Freitag, 13. Februar 2004 02:59, Andy Ross wrote: David Megginson wrote: Thanks -- your explanation and Jon's has made it all clear, and the discussion has been useful. So, as far as I understand, JSBSim supports this in JSBSim CVS but not yet in FlightGear. Does YASim support setting the reference point yet? I'm not sure exactly what this is for. I can (and probably should) export the C.G. position for the view code to use appropriately. But the VRP stuff seems like a double-correction. It's basically identical to the view center offset stuff, isn't it? If you denote with C.G. a _FIXED_ point in your aircraft like the static center of gravity which does not move relative to the aircraft when you burn fuel, then more or less, yes. What you gain is that the coordinate values, you can read off from blueprints, can be used directly to position submodels in your 3D model, without first shifting that positions with the center of gravity. Also, if a modeller likes to have the visual reference point identical to the static center of gravity, he can simply place it there. Greetings Mathias -- Mathias Fröhlich, email: [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
