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
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.
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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,
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
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,
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
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
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
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
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
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
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
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
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
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
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
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
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.
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
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
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
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
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
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
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
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
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
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
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
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
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,
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
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
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
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
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
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
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)
-
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
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
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
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
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
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
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
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.
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
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
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
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
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
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.
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
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
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
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
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
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.
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
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
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
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
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
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
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
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
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
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
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
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
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
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,
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
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
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
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
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
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?
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
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
98 matches
Mail list logo
