Ok, good catch, thanks.
Curt.
Jim Wilson writes:
> "Curtis L. Olson" <[EMAIL PROTECTED]> said:
>
> >
> > That seems to work reasonably well here with a 24 bit depth buffer
> > too. I can live with that and it would definitely simplify things and
> > seems to work every bit as good.
>
> One co
Another thing...should've just redone the patch...
Line 906 should read:
sgScaleVec3( lift_vec, 0.0 + agl / 20.0 );
instead of:
sgScaleVec3( lift_vec, 1.0 + agl / 20.0 );
There isn't any need to lift the lights an extra meter in 16bpp mode.
Best,
Jim
Jim Wilson <[EMAIL PROTEC
"Curtis L. Olson" <[EMAIL PROTECTED]> said:
>
> That seems to work reasonably well here with a 24 bit depth buffer
> too. I can live with that and it would definitely simplify things and
> seems to work every bit as good.
One correction to what you added to cvs.
Line 899 should read:
if (ag
Revised patch, eliminating distance component.
Best,
Jim
Index: src/Scenery/tileentry.cxx
===
RCS file: /var/cvs/FlightGear-0.9/FlightGear/src/Scenery/tileentry.cxx,v
retrieving revision 1.10
diff -u -r1.10 tileentry.cxx
--- src/Sc
Jim Wilson writes:
> Jim Wilson <[EMAIL PROTECTED]> said:
>
> > "Curtis L. Olson" <[EMAIL PROTECTED]> said:
> >
> > > Are you sure you actually disabled the lift vector? At about line
> > > #915 in tileentry.cxx you should find:
> > >
> > > sgAddVec3( lt_trans, lift_vec );
> > >
> > > Comm
Jim Wilson <[EMAIL PROTECTED]> said:
> "Curtis L. Olson" <[EMAIL PROTECTED]> said:
>
> > Are you sure you actually disabled the lift vector? At about line
> > #915 in tileentry.cxx you should find:
> >
> > sgAddVec3( lt_trans, lift_vec );
> >
> > Comment out that single line and see if you
"Curtis L. Olson" <[EMAIL PROTECTED]> said:
> Are you sure you actually disabled the lift vector? At about line
> #915 in tileentry.cxx you should find:
>
> sgAddVec3( lt_trans, lift_vec );
>
> Comment out that single line and see if you still see a jumping when
> crossing a tile boundary.
On Wednesday 30 October 2002 10:50 am, David Megginson wrote:
> Jim Wilson writes:
> > Ok good...got it. I think we can come up with a simple solution, but
> > it could take some trial on error with the 16 bit cards. When i get
> > running on the voodoo i'll test it.
>
> You can also switch a
Jim Wilson writes:
> Hmmm...in my tests even if the lifting code is *completely* disabled (approx
> line 900, tilentry.cxx), the lights still jump up a couple meters near the end
> of KSFO runway 28R when crossing the tile boundry. What do you think?
> Precision error in the transform vector?
Ar
"Curtis L. Olson" <[EMAIL PROTECTED]> said:
> This is exactly why for the long term we don't want to be raising up
> the lights based on the distnace to the center of the current tile ...
Hmmm...in my tests even if the lifting code is *completely* disabled (approx
line 900, tilentry.cxx), the lig
Jim Wilson writes:
> No kidding? I didn't realize that scaled the depth buffer bpp as well.
I think it does -- at least, the 2D/3D panel starts showing through
the fuselage in outside view at 16bpp, suggesting a limited z-buffer.
All the best,
David
--
David Megginson, [EMAIL PROTECTED],
Jim Wilson wrote:
> No kidding? I didn't realize that scaled the depth buffer bpp as
> well.
It doesn't have to. If you run glxinfo, you'll see a huge list of X11
visuals with varying configurations: depth buffer depth, alpha depth,
stencil depth, back buffer, etc... You can get a 16 bit depth
David Megginson <[EMAIL PROTECTED]> said:
> Jim Wilson writes:
>
> > Ok good...got it. I think we can come up with a simple solution, but it
> > could take some trial on error with the 16 bit cards. When i get running on
> > the voodoo i'll test it.
>
> You can also switch a GeForce card o
Jim Wilson writes:
> Ok good...got it. I think we can come up with a simple solution, but it
> could take some trial on error with the 16 bit cards. When i get running on
> the voodoo i'll test it.
You can also switch a GeForce card over the 16bpp for testing
purposes. Inside the Screen se
"Curtis L. Olson" <[EMAIL PROTECTED]> said:
> Jim Wilson writes:
> > The problem I'm seeing is the lights suddenly elevate at the tile
> > boundry down the other end of 28R at KSFO. Up to what appears to be
> > the 2m or so you mentioned earlier. It seems that perhaps this is
> > may be some sor
David Megginson writes:
> Jim Wilson writes:
>
> > The distant lights seem about right on my display. Is this looking
> > bad on the 16bit cards? What is the problem? Are you seeing
> > z-fighting or do they look strangely positioned?
>
> They seem to slope upwards.
The lights are all move
Jim Wilson writes:
> The distant lights seem about right on my display. Is this looking
> bad on the 16bit cards? What is the problem? Are you seeing
> z-fighting or do they look strangely positioned?
They seem to slope upwards.
All the best,
David
--
David Megginson, [EMAIL PROTECTED
Jim Wilson writes:
> The problem I'm seeing is the lights suddenly elevate at the tile
> boundry down the other end of 28R at KSFO. Up to what appears to be
> the 2m or so you mentioned earlier. It seems that perhaps this is
> may be some sort of tile boundry bug...it needs to be looked into it
>
David Megginson writes:
> Jim Wilson writes:
>
> > Finally, I did look at the code closer. Took all of 1 minute to
> > figure out what was going on :-). Maybe something similar can be
> > done with the distance...which could make sense and avoid adding a
> > few extra steps. Also, knowing w
David Megginson <[EMAIL PROTECTED]> said:
> Jim Wilson writes:
>
> > Finally, I did look at the code closer. Took all of 1 minute to
> > figure out what was going on :-). Maybe something similar can be
> > done with the distance...which could make sense and avoid adding a
> > few extra step
Jim Wilson writes:
> Finally, I did look at the code closer. Took all of 1 minute to
> figure out what was going on :-). Maybe something similar can be
> done with the distance...which could make sense and avoid adding a
> few extra steps. Also, knowing what is happening, I now have no
> p
"Curtis L. Olson" <[EMAIL PROTECTED]> said:
> We may want to think the patch ...
>
> Probably the right thing to do if we can spare the cpu cycles is raise
> the lights based on distance from the center of the airport or
> distance from the center of the light group.
>
> That would require a li
"Curtis L. Olson" <[EMAIL PROTECTED]> said:
> If you look at the code in tileentry.cxx starting about line #881:
> We calculate an agl value, then we calculate a dist value.
> The "lift" vector is calcuated from both these numbers.
>
Ah, ok I'll look again. Take it the distance is from tile cen
Jim Wilson writes:
> "Curtis L. Olson" <[EMAIL PROTECTED]> said:
>
> > Actually this takes away the AGL component until you are >30m AGL, but
> > there is also a distance component that this doesn't account for.
>
> Yes, but the AGL is what makes the lights appear to rise up higher (than
> the 0
"Curtis L. Olson" <[EMAIL PROTECTED]> said:
> Actually this takes away the AGL component until you are >30m AGL, but
> there is also a distance component that this doesn't account for.
Yes, but the AGL is what makes the lights appear to rise up higher (than
the 0.5m). I'm not sure what you mean
Jim Wilson writes:
> That tiny patch I submitted yesterday takes care of that. It makes it so the
> lights don't adjust upward until you are above 30mhigh enough that it
> isn't noticable...and low enough that it should take care of any z-buffer
> issues.
Actually this takes away the AGL co
"Curtis L. Olson" <[EMAIL PROTECTED]> said:
> Jim Wilson writes:
> > What I'm seeing is more like the 0.5m...a little high but hardly enough to
> > look way wrong (it isn't going to be picture perfect anyway). Can anyone
> > explain why I don't get the 2m effect like Andy and David?
>
> It will
Jim Wilson writes:
> > Yes, that's about right. The lights pass well over the top of the
> > plane during the takeoff roll, which looks quite silly. Even 0.5m is
> > too high on the ground.
>
> What I'm seeing is more like the 0.5m...a little high but hardly enough to
> look way wrong (it
Jim Wilson writes:
> What I'm seeing is more like the 0.5m...a little high but hardly enough to
> look way wrong (it isn't going to be picture perfect anyway). Can anyone
> explain why I don't get the 2m effect like Andy and David?
It will depend which airport you are visiting, which runway at th
David Megginson <[EMAIL PROTECTED]> said:
> Andy Ross writes:
>
> > > When you say "very high", how high do you mean?
> >
> > It looks like about 2m to me.
>
> Yes, that's about right. The lights pass well over the top of the
> plane during the takeoff roll, which looks quite silly. Even
You know, I haven't been following this conversation very carefully, so I
don't know the viability of the suggestion I'm going to throw out (nor if it
has been discussed, yet) - and I have only a minute in between the jury duty
I served this morning and going back to work, so it won't be very detai
Andy Ross writes:
> > When you say "very high", how high do you mean?
>
> It looks like about 2m to me.
Yes, that's about right. The lights pass well over the top of the
plane during the takeoff roll, which looks quite silly. Even 0.5m is
too high on the ground.
All the best,
David
--
Jim Wilson wrote:
> Hmmm...I don't remember ever having to to look up to see lights when running
> the voodoo card.
>
> When you say "very high", how high do you mean?
It looks like about 2m to me. Is it possible that you guys are just
using different aircraft? David tends to hang out in the Cu
David Megginson <[EMAIL PROTECTED]> said:
> Note, though, that even with 32bpp the lights are floating very high.
>
Hmmm...I don't remember ever having to to look up to see lights when running
the voodoo card.
When you say "very high", how high do you mean?
Best,
Jim
___
David Megginson writes:
> Curtis L. Olson writes:
>
> > > Unfortunately, not for 16bpp -- the lights are still so high that I
> > > have to use to mouse to look up to see them. I tried commenting out
> > > the 16bpp detection and using the 32bpp lift, but the lights were
> > > still floating
Curtis L. Olson writes:
> > Unfortunately, not for 16bpp -- the lights are still so high that I
> > have to use to mouse to look up to see them. I tried commenting out
> > the 16bpp detection and using the 32bpp lift, but the lights were
> > still floating high in the air. This looks like it
David Megginson writes:
> Jim Wilson writes:
>
> > It looks pretty good with this patch:
> >
> > RCS file: /var/cvs/FlightGear-0.9/FlightGear/src/Scenery/tileentry.cxx,v
> > retrieving revision 1.9
> > diff -r1.9 tileentry.cxx
> > 891c891,893
> > < * SG_FEET_TO_METER - globals-
Jim Wilson writes:
> It looks pretty good with this patch:
>
> RCS file: /var/cvs/FlightGear-0.9/FlightGear/src/Scenery/tileentry.cxx,v
> retrieving revision 1.9
> diff -r1.9 tileentry.cxx
> 891c891,893
> < * SG_FEET_TO_METER - globals->get_scenery()->get_cur_elev();
> ---
>
David Megginson <[EMAIL PROTECTED]> said:
> Curtis L. Olson writes:
>
> > Yes ... a 0.5 elevation difference just isn't enough to maintain
> > zbuffer separation from common viewing distances and angles. This
> > gets significantly worse on a card with a 16 bit depth buffer
> > (i.e. voodoo-
Curtis L. Olson writes:
> Yes ... a 0.5 elevation difference just isn't enough to maintain
> zbuffer separation from common viewing distances and angles. This
> gets significantly worse on a card with a 16 bit depth buffer
> (i.e. voodoo-1,2.3)
>
> I believe the code to lift up the runway
"Curtis L. Olson" <[EMAIL PROTECTED]> said:
> David Megginson writes:
> > I'm still working on understanding the code. First, you have
> >
> > point_list geod_light_nodes
> > = calc_elevations( root, light_nodes.get_node_list(), 0.5 );
> >
> > That means that the base elevat
David Megginson <[EMAIL PROTECTED]> said:
> Curtis L. Olson writes:
>
> > We artifically raise the lights a bit to attempt to avoid zbuffer
> > fighting. The formula is based on the altitude above ground and the
> > distance away ... however, it's rough and imperfect ...
>
> I'm still workin
David Megginson writes:
> I'm still working on understanding the code. First, you have
>
> point_list geod_light_nodes
> = calc_elevations( root, light_nodes.get_node_list(), 0.5 );
>
> That means that the base elevation for each light is already 0.5m
> above the runway. Doe
David Megginson writes:
>
> Curtis L. Olson writes:
>
> > We artifically raise the lights a bit to attempt to avoid zbuffer
> > fighting. The formula is based on the altitude above ground and the
> > distance away ... however, it's rough and imperfect ...
>
> I'm still working on understandin
Curtis L. Olson writes:
> We artifically raise the lights a bit to attempt to avoid zbuffer
> fighting. The formula is based on the altitude above ground and the
> distance away ... however, it's rough and imperfect ...
I'm still working on understanding the code. First, you have
po
David Megginson writes:
> Jim Wilson writes:
>
> > The new airport lighting is really impressive. At dusk it looked pretty good
> > on the screen so here's a couple shots:
> >
> > http://www.spiderbark.com/fgfs/cubsightseeing.png
> > http://www.spiderbark.com/fgfs/towerview.png
>
> They do
Jim Wilson writes:
> The new airport lighting is really impressive. At dusk it looked pretty good
> on the screen so here's a couple shots:
>
> http://www.spiderbark.com/fgfs/cubsightseeing.png
> http://www.spiderbark.com/fgfs/towerview.png
They do look great, but I find it disturbing that
The new airport lighting is really impressive. At dusk it looked pretty good
on the screen so here's a couple shots:
http://www.spiderbark.com/fgfs/cubsightseeing.png
http://www.spiderbark.com/fgfs/towerview.png
Best,
Jim
___
Flightgear-devel mailing
48 matches
Mail list logo