Michael,
What you are observing isn't exactly how you describe, although it appears
that way. I was trying to simplify things by just pointing out that the
aircraft stays horizontal (appears to not roll) in the chase view, but that
isn't exactly how it works.
The difference is that the xyz
Below are some ideas I proposed for chase and tower views. I am wondering
if some things like this might now be included w/ the improved view code.
I'll reiterate a little.
Chase views:
[1] One view like the old one, but minus the sway that was due to
sideslip. In this case the horizon on
Michael Selig [EMAIL PROTECTED] said:
Chase views:
[1] One view like the old one, but minus the sway that was due to
sideslip. In this case the horizon on the screen is always level. (I
don't think the new chase view behaves like this. The horizon is not
level, it rolls w/ the
At 4/2/02, you wrote:
Michael Selig [EMAIL PROTECTED] said:
Chase views:
[1] One view like the old one, but minus the sway that was due to
sideslip. In this case the horizon on the screen is always level. (I
don't think the new chase view behaves like this. The horizon is not
On Mon 11. March 2002 18:21, you wrote:
Martin Dressler writes:
There are some diferents how the viewer is initialized and from
where it take new position. Your viewpoint could be static or
change position or (and) up vector in some dependency on FDM or
maybe time.
Right, but none
On Sat 9. March 2002 20:36, you wrote:
As far as I can figure out, there are only three situations we need to
deal with in the viewer code:
1. Looking away from a known position.
2. Looking towards a known position from a known distance and
angle(s).
3. Looking from one known position
Martin Dressler writes:
There are some diferents how the viewer is initialized and from
where it take new position. Your viewpoint could be static or
change position or (and) up vector in some dependency on FDM or
maybe time.
Right, but none of that's the viewer's concern. As long as
David Megginson wrote:
I disagree -- the view code gets *very* hard to understand very
easily. If that information is tracked, it should be tracked
externally (the view manager, again?) and not in the viewer code
itself.
Amen. I spent many hours over the weekend trying to make the view
Michael Selig writes:
With respect to the chase view (2), three potential options come to mind:
These are excellent suggestions, but I think that we'll want them to
end up in the view manager (or elsewhere) rather than in the viewer
proper. As long as we tell the viewer, for each frame, what
David Megginson [EMAIL PROTECTED] said:
In every case, we want to be able to specify offsets for all six
degrees of freedom. I think that it makes sense to put all of this in
a single, configurable viewer class, rather than having separater
viewer_lookat, viewer_rph, and (eventually)
Jim Wilson writes:
At first look this doesn't seem all that bad. The hardest part is
going to be cleaning up the hard coded bits out there.
Here are most of the required outputs, from an analysis I did earlier:
- the VIEW matrix, a matrix containing the transformations to put the
view
David Megginson [EMAIL PROTECTED] said:
As far as I can figure out, there are only three situations we need to
deal with in the viewer code:
1. Looking away from a known position.
2. Looking towards a known position from a known distance and
angle(s).
3. Looking from one known
12 matches
Mail list logo
