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],
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 moved as a
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 sort of tile
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 over the
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?
Are
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.
Yes and
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 still see a
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 );
Comment out that single line and
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
---
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 (agl 0.0)
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
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 correction to
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 center?
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 little
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
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 steps. Also,
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 what is
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 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 -
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's
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 high in the
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
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 Cub and
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
--
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
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 0.5m is
too
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 that
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 isn't
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 depend which
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
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 by
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.5m). I'm
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
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 understanding the
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. Does
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 working on
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 elevation for each
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
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-1,2.3)
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
40 matches
Mail list logo
