Curtis L. Olson writes:
Jon S Berndt writes:
Curtis L. Olson wrote:
Andy Ross writes:
and the code to calculate the scenery center for each tile can
simply go away.
This however isn't true. You still need to have an 'origin' for each
scenery tile so you know how to translate it
Andy Ross wrote:
Model coordinates (that is, the reference frame of the local aircraft,
into which the model and panel geometry will be drawn):
Origin = nose of the aircraft (?)
X = backwards
Y = up
Z = left
First confusion: the /sim/view/pilot/{x,y,z}-offset properties don't
Norman Vine wrote:
Andy Ross wrote:
The location of the scenery origin is another.
I thought I that this would have been self evident apon reading the
code sections I pointed out yesterday.
But just to be clear
THERE IS NO FIXED SCENERY ORIGIN
Norman, stop it. The world may be
Andy Ross writes:
Norman Vine wrote:
Andy Ross wrote:
The location of the scenery origin is another.
I thought I that this would have been self evident apon reading the
code sections I pointed out yesterday.
But just to be clear
THERE IS NO FIXED SCENERY ORIGIN
Norman, stop it.
Andy Ross writes:
Which begs the question (posed above, and still unanswered): what
*is* the location of the scenery origin when the tile is drawn?
Where does it come from? What must it be set to? Since it cannot
be the center of the earth, it must be somewhere else; where?
It wouldn't
Andy Ross writes:
The scenery center is set out of the main loop, and looks to me
like it can be easily replaced with the eyepoint with no loss of
function. This has two nice side effects: the view matrix
generation is no longer dependant on data stored in scenery tiles,
and the code
Jon S Berndt writes:
On Wed, 13 Mar 2002 16:46:17 -0600 (CST)
Curtis L. Olson [EMAIL PROTECTED] wrote:
Andy Ross writes:
and the code to calculate the scenery center for each tile can
simply go away.
This however isn't true. You still need to have an 'origin' for each
scenery
David Megginson wrote:
Andy Ross writes:
The scenery center is set out of the main loop, and looks to me
like it can be easily replaced with the eyepoint with no loss of
function.
That sounds like an excellent idea. Are there any hidden gotchas?
None yet. Code that doesn't exist
Jon S. Berndt wrote:
I don't know if this applies at all, but it worries me to hear what
Andy wrote about the code going away. Will this have any impact on the
ability to calculate the location, height, and orientation of an
aircraft on a tile given the tile may have a non-vertical
Andy Ross writes:
Good point, I overstated. The code to compute an exact center is not
longer an issue (any vertex on the tile will do) but clearly it has to
be stored somewhere. Still, getting it out of the way of the view
code can't do anything but help modularity.
Right, but at some
While I'm thinking about it, can someone with knowlege please let me
know that I've got the right facts for the following coordinate
systems:
Model coordinates (that is, the reference frame of the local aircraft,
into which the model and panel geometry will be drawn):
Origin = nose of the
Andy Ross writes:
While I'm thinking about it, can someone with knowlege please let me
know that I've got the right facts for the following coordinate systems:
What I'm fuzzier on is where
the origin is when the scenery tiles are drawn (it has to be local, as
floats don't have sufficient
12 matches
Mail list logo
