Martin Dressler wrote:
> Please no! No hardcoded views. I want to run FlightGear one day in RC
> mode with tower view as a default view. If you think that somewhere in
> the code you need to know type of view, there should be function
> globals->get_current_view()->get_type()
I didn't mean th
> It's just occurred to me that we may want to back off on the 100%
> general view solution. One immediate problem is that the euler angle
> conventions, in face, depend on context.
>
> Inside the cockpit, when you move the view to the left (by moving the
> mouse or hat switch to the left), you
Andy Ross <[EMAIL PROTECTED]> said:
> David Megginson wrote:
> > > Wolfram Kuss writes:
> > > > Are r,p,h relative to the plane or the current view?
> >
> > I imagine two RPH vectors: the main vector (which would in some cases
> > be the orientation of the plane) and the offset vector, which
David Megginson wrote:
> > Wolfram Kuss writes:
> > > Are r,p,h relative to the plane or the current view?
>
> I imagine two RPH vectors: the main vector (which would in some cases
> be the orientation of the plane) and the offset vector, which are
> relative to the main ones. For the pilot
David wrote:
>Norman Vine writes:
>
> > Well the Mouse code certainly could but let's leave that alone
> > as I REALLY don't want the Mouse reading properties :-)
>
>Not read them, but set them. It wouldn't much matter if the mouse
>code called
>
> globals->get_current_view()->set_orientation_o
Norman wrote:
>>The resulting matrix, far from being view-only, in fact includes the
>>global orientation as well.
>
>Again the 'test_matrix' or something like it should probably become
>the ''resultant of all the user inputs on the view" note this had NO
>global orientation in it nor should i
Jim Wilson writes:
> What I was volunteering for was something less ambitious.
> Basically just merging the pilot and lookat viewers, looking at the
> outputs and combining the ones that are essentially the same kinds
> of values, and mostly preserving how things work now.
I think that's an
On Wed, 13 Mar 2002, David Megginson wrote:
> Andy Ross writes:
>
> > Actually, YASim already does model c.g. change. If you change the
> > value of a tag's property, you'll see the appropriate change
> > in c.g. behavior. YASim does not, however, model fuel consumption
> > yet, so the mo
Andy Ross <[EMAIL PROTECTED]> said:
>
> It is not mutable by anything but the mouse code. I want a hat swtich
> to change view direction. This is not even vaguely possible with the
> current implementation (especially if you refuse to read properties
> from the mouse code -- properties are all
Erik Hofman wrote:
> David Megginson wrote:
>
>> We might be approaching a point that we'll need separate stable and
>> development CVS branches. The stable branch should have bug-fixes
>> only, while the development branch can have bleeding-edge new code for
>> people to try out and review. Th
Norman Vine <[EMAIL PROTECTED]> said:
> Jim Wilson writes:
> >
> >Norman Vine <[EMAIL PROTECTED]> said:
> >
> >> So I say lets take a little time and discuss or 'High Level'
> conceptualization
> >> and the possible ramifications of the possible way of doing
> >things before we just tear things a
David Megginson writes:
>
>Norman Vine writes:
>
> > However I STRONGLY suggest that the first pass is written in
> > 'pseudo code' and posted to the Net somewhere for Review and
> > Comment before anything is actually implemented.
> >
> > A Wiki would be ideal for this kind of thing :-)
>
>CVS is
David Megginson writes:
>
>The issue is code design --
Indeed !
>the view code needs to be fully decoupled
It is
except for the
current_tilt
current offset
goal_view_offset
goal_tilt_offset
mechanisms.
These are dynamical properties that should be stored in either
a quat or a matrix an
Norman Vine writes:
> However I STRONGLY suggest that the first pass is written in
> 'pseudo code' and posted to the Net somewhere for Review and
> Comment before anything is actually implemented.
>
> A Wiki would be ideal for this kind of thing :-)
CVS is good for this kind of thing as wel
Norman Vine <[EMAIL PROTECTED]> said:
> So I say lets take a little time and discuss or 'High Level'
> conceptualization
> and the possible ramifications of the possible way of doing things before we
> just tear things apart just to fix the 'current crisis'
>
> Object derivation can help a LOT h
Norman Vine writes:
> > globals->get_current_view()->set_orientation_offsets(r, p, h);
> >
> >or
> >
> > view_roll_node->setDoubleValue(r);
> > view_pitch_node->setDoubleValue(p);
> > view_heading_node->setDoubleValue(h);>
>
> Here is where I say you are WAY over enamoured with your
Jim Wilson writes:
> The mouse code should just output an RPH
>vector similar to what the "pilot offset" code does.
The problem is IMHO the other way around the External
View code should be exporting a matrix instead of a vector
Which is exactly what the Mouse Code did except for the
vestigial
David Megginson writes:
>
>Norman Vine writes:
>
> > Well the Mouse code certainly could but let's leave that alone
> > as I REALLY don't want the Mouse reading properties :-)
>
>Not read them, but set them. It wouldn't much matter if the mouse
>code called
>
> globals->get_current_view()->set_o
On Wed, 2002-03-13 at 04:22, David Megginson wrote:
> Jim Wilson writes:
>
> > It's still a little weird with a steep roll angle. Found an
> > article on quarternions. It seems that they can be used to solve
> > the problem of the rotation being off center.
>
> Actually what we need to know
Norman Vine writes:
> Well the Mouse code certainly could but let's leave that alone
> as I REALLY don't want the Mouse reading properties :-)
Not read them, but set them. It wouldn't much matter if the mouse
code called
globals->get_current_view()->set_orientation_offsets(r, p, h);
or
Norman Vine writes:
> Well the Mouse code certainly could but let's leave that alone
> as I REALLY don't want the Mouse reading properties :-)
Not read them, but set them. It wouldn't much matter if the mouse
code called
globals->get_current_view()->set_orientation_offsets(r, p, h);
or
Norman Vine writes:
> David Megginson writes:
>
> >(and de-quat the mouse code)
>
> exactly the kind of response that led me to coin the phrase
>
> "MAYDAY MAYDAY FlightGear has been hijacked"
Actually, that was Andy's idea, but I do agree with it entirely.
I'm not saying to de-qua
Jim Wilson writes:
> It's still a little weird with a steep roll angle. Found an
> article on quarternions. It seems that they can be used to solve
> the problem of the rotation being off center.
Actually what we need to know is the center of gravity (CG) for each
plane, or maybe the aero r
Andy Ross writes:
>
>For a quickie example, look at the places in the code that read the
>view_offset and view_tilt stuff. These are the values that represent
>the direction of the pilot's head, and as such should be used only by
>the core view code to decide on a view direction for the 3D
>proje
Jim Wilson writes:
> I could really use some help visualizing
> the matrices. Which elements are which axis (in Plib)?
x is 1st
y is 2nd
z is 3rd < up >
where x cross y equals z
same as OpenGL xcept there Y is up
> And what does the fourth row/col represent?
fourth column is scaling almo
Norman Vine wrote:
> David Megginson wrote:
> > Thanks -- the internal cockpit view seems much better. Now the ball's
> > in Andy's court to patch up the virtual panel code (and de-quat the
> > mouse code), and we're flying!
>
> exactly the kind of response that led me to coin the phrase
>
> It's still a little weird with a steep roll angle. Found an article on
> quarternions. It seems that they can be used to solve the problem of the
> rotation being off center. Not sure yet how to apply it to this problem.
> Maybe if we can feed it an axis that appears a little behind the
> ori
David Megginson writes:
>(and de-quat the mouse code)
exactly the kind of response that led me to coin the phrase
"MAYDAY MAYDAY FlightGear has been hijacked"
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman
David Megginson <[EMAIL PROTECTED]> said:
> Jim Wilson writes:
>
> > This seems to pretty much correct the problem. Part of the problem
> > is that rotations are occuring at the firewall (model origin) which
> > seems a little un-natural inside the cockpit. The rest of the
> > problem is I
Jim Wilson writes:
> This seems to pretty much correct the problem. Part of the problem
> is that rotations are occuring at the firewall (model origin) which
> seems a little un-natural inside the cockpit. The rest of the
> problem is I am just learning how this stuff works (I know I've
>
30 matches
Mail list logo