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 k
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
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 nor
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
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 'origi
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 c
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:
>
>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 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
Andy Ross writes:
>
>In still other cases, I haven't been able to puzzle it out yet. The
>weird dichotomy between the numbers I see in the DC-3 model file and
>the convention used for an offset to those numbers is one.
I believe DaveM mentioned wanting to keep the DC3 in a side
profile view wi
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
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
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 airc
13 matches
Mail list logo
