"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
Jon Berndt wrote:
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 prob
> 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 onl
Jon Berndt wrote:
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
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,
> >
> >
> 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
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
> 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
> som
On Sonntag, 15. Februar 2004 14:12, Martin Spott wrote:
> 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
> 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.
Yes, thank you. This is the primary reason for using the nose as the VRP,
IMHO.
> Adopted to the current case this means:
"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
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 ma
> 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. S
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.
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 provi
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 th
> 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
Jon Berndt wrote:
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
Jim Wilson wrote:
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!
On Saturday 14 Feb 2004 6:27 pm, Norman Vine wrote:
> 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
>
> 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
>
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,
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 mos
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
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
> 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
> 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 fli
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 r
Jim Wilson wrote:
Vivian Meazza 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 cock
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 'adj
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
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-necess
Norman Vine wrote:
> Why this position is expressed as [lat, lon, alt] instead of [X,Y,Z]
> ( or perhaps both shold be passed ) is a relavant question but
The lat/lon/alt stuff is a sane convention, and especially easy for
simple code (Nasal scripts, for instance) to parse and use.
I agree t
Norman Vine said:
> 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...
Argh!! I hate that. I am sorry. And now that I look, t
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 fi
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 intere
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 y
Vivian Meazza <[EMAIL PROTECTED]> said:
>
>
> 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 ev
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...
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 1
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 Fr
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
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 ter
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
Jon Berndt writes:
>
> 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?
Hopefully any system can figure out on it's own where something is
from the poition and orientation
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
Yo
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
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'
> 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
> 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
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
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 te
> 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 f
> 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.
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,
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,
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 model
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 disag
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.
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
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 (
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 base
> 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
poin
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:
>
> -
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 c
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 t
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)
-
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
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
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 eyepoi
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 align
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 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
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)
> a
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
On Fri, 13 Feb 2004 11:23:40 -0700
Russell Suter <[EMAIL PROTECTED]> wrote:
Jon Berndt wrote:
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
...
You may be thinking of the Body frame sy
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 g
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 t
On Fri, 13 Feb 2004 16:01:52 -
"Jim Wilson" <[EMAIL PROTECTED]> wrote:
Jon S Berndt <[EMAIL PROTECTED]> said:
Maybe we should just try to work with what we already have before
deciding more is necessary. Does anyone oppose enabling the change to
JSBSim.cxx and then attempting to configure
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 mo
Norman Vine wrote:
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
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
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
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 dow
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 prop
Jon S Berndt wrote:
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 th
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 ide
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 th
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
Jon S Berndt <[EMAIL PROTECTED]> said:
> 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 righ
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 mod
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
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
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.
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 identica
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 i
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. I
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
>
>
> JS
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
Mathias Fröhlich wrote
On Freitag, 13. Februar 2004 09:26, Vivian Meazza wrote:
> > 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 aircr
1 - 100 of 127 matches
Mail list logo
