[Flightgear-devel] screen shots lights
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 list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re: [Flightgear-devel] screen shots lights
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 lights float so high above the runway (especially when they come flying through the window during the takeoff roll) -- could it have to do with a disparity between the published airport elevation and the actual DEM elevation? All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re: [Flightgear-devel] screen shots lights
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 look great, but I find it disturbing that the lights float so > high above the runway (especially when they come flying through the > window during the takeoff roll) -- could it have to do with a > disparity between the published airport elevation and the actual DEM > elevation? 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 ... We can definitely improve on what we have, but there's no perfect solution. If you turn off the zbuffering altogether then lights will show through the backs of hills and mountains. If you use zbuffering, then you have zbuffering issues. You can't really use glPolygonOffset() because these aren't really polygons. You could fiddle with nudging the near/far clip planes, but there's no way that would ever be portable between different video cards and platforms. Runways are about the worst case scenario for things like lighting and mip-mapping. Regards, Curt. -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re: [Flightgear-devel] screen shots lights
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 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 FlightGear have ssg do further elevation adjustments at runtime? All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] screen shots lights
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 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 FlightGear have ssg do further elevation
> adjustments at runtime?
void FGTileEntry::prep_ssg_node(
{
if ( gnd_lights_transform ) {
..
if ( general.get_glDepthBits() > 16 ) {
sgScaleVec3( lift_vec, 10.0 + agl / 100.0 + dist / 1 );
} else {
sgScaleVec3( lift_vec, 10.0 + agl / 20.0 + dist / 5000 );
}
...
if ( rwy_lights_transform ) {
...
if ( general.get_glDepthBits() > 16 ) {
sgScaleVec3( lift_vec, 0.0 + agl / 500.0 + dist / 1 );
} else {
sgScaleVec3( lift_vec, 1.0 + agl / 20.0 + dist / 5000 );
}
if ( lightmaps_transform ) {
..
if ( general.get_glDepthBits() > 16 ) {
sgScaleVec3( lift_vec, 0.0 + agl1 / 2000.0 + dist1 / 1 );
} else {
sgScaleVec3( lift_vec, 0.0 + agl1 / 20.0 + dist1 / 5000 );
}
...
}
HTH
Norman
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re: [Flightgear-devel] screen shots lights
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 FlightGear have ssg do further elevation > adjustments at runtime? 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 lights (and ground cover lights) is in tileentry.cxx:prep_ssg_node() Regards, Curt. -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re: [Flightgear-devel] screen shots lights
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 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 FlightGear have ssg do further elevation > adjustments at runtime? Yes it does. It is based on the agl data. Look at about line 834 in tileentry.cxx. Note that because Yasim reports AGL at wheel level the lights are actually lower there. It seems to me that the 0.5 could be made lower (maybe a property to adjust it in some cases). To see the difference start up the c310, go to chase view and lower your view angle so that the ground is level. The green lights will pass over the wing level. Then do the same with c310-yasim, the green lights will be just about 0.5m off the ground. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re: [Flightgear-devel] screen shots lights
"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 light is already 0.5m > > above the runway. Does FlightGear have ssg do further elevation > > adjustments at runtime? > > 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 lights (and ground cover > lights) is in tileentry.cxx:prep_ssg_node() > Yes and in that code, subtracting 30m from the agl (and flooring it to 0) would probably work fine and look a bit better. That way the lights wouldn't start to lift until AGL exceeded 30m. Haven't got time to try it right now...the crew is waiting to leave for brunch. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re: [Flightgear-devel] screen shots lights
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 lights (and ground cover > lights) is in tileentry.cxx:prep_ssg_node() I'll do some experimentation. On the ground right now, in a C172, the runway lights are at about eye height. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re: [Flightgear-devel] screen shots lights
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) > > > > I believe the code to lift up the runway lights (and ground cover > > lights) is in tileentry.cxx:prep_ssg_node() > > I'll do some experimentation. On the ground right now, in a C172, the > runway lights are at about eye height. > 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(); --- > * SG_FEET_TO_METER - globals->get_scenery()->get_cur_elev() - 30; > if (agl < 0) agl = 0; > Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re: [Flightgear-devel] screen shots lights
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(); > --- > > * SG_FEET_TO_METER - globals->get_scenery()->get_cur_elev() - 30; > > if (agl < 0) agl = 0; 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 going to take a fair bit of work. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re: [Flightgear-devel] screen shots lights
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->get_scenery()->get_cur_elev(); > > --- > > > * SG_FEET_TO_METER - globals->get_scenery()->get_cur_elev() - 30; > > > if (agl < 0) agl = 0; > > 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 going to take a > fair bit of work. It's a very tough problem. A 24 bit depth buffer helps a lot, but a 16 bit depth buffer makes it a *really* hard problem. Curt. -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re: [Flightgear-devel] screen shots lights
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 going to take a > > fair bit of work. > > It's a very tough problem. A 24 bit depth buffer helps a lot, but a > 16 bit depth buffer makes it a *really* hard problem. Note, though, that even with 32bpp the lights are floating very high. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re: [Flightgear-devel] screen shots lights
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 air. This looks like it's going to take a > > > fair bit of work. > > > > It's a very tough problem. A 24 bit depth buffer helps a lot, but a > > 16 bit depth buffer makes it a *really* hard problem. > > Note, though, that even with 32bpp the lights are floating very high. Yes, you will see some floating. Also this will be worse in some areas because the distance for all the lights in a particular tile is calculated relative to the tile center, not the individual airport (or runway light group) centers. We might need to do that and eat the frame rate hit of the extra calculations, otherwise the lighting will always float more at some airports and less at others, and often float unacceptably high ... Curt. -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re: [Flightgear-devel] screen shots lights
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 ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] screen shots lights
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 172 a lot, which have rather low cockpits. The jets (and especially the 747) are much higher. Andy -- Andrew J. RossNextBus Information Systems Senior Software Engineer Emeryville, CA [EMAIL PROTECTED] http://www.nextbus.com "Men go crazy in conflagrations. They only get better one by one." - Sting (misquoted) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] screen shots lights
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 -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] screen shots lights
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 detailed: Can the runway lighting location be given a z-offset that is a percentage of the aircraft height above ground level, up to a certain maximum? Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] screen shots lights
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 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 going to be picture perfect anyway). Can anyone explain why I don't get the 2m effect like Andy and David? Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] screen shots lights
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 airport, where the airport is located relative to the tile center, and a few things like that. Regards, Curt. -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] screen shots lights
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 going to be picture perfect anyway). Can anyone > explain why I don't get the 2m effect like Andy and David? It's scaled to a lower height with 32bpp, but it's still obviously off. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] screen shots lights
"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 airport you are visiting, which runway at that > airport, where the airport is located relative to the tile center, and > a few things like that. > 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. As long as the aircraft position isn't greater than 30m higher than wherever the lights are centered, then they'll stay at 0.5 meters. That's good for almost all airports. The lights are about twice as high though when the YASim fdm is used. This seems weird...thought I knew why before...but now I'm not sure. Start up the c310 in each FDM at KSFO, put the parking brake on, go to chase view, and adjust the eye level close to the ground and look at the lighting height as compared to the aircraft image. They are higher under YASim. Started building current cvs on my old voodoo3 machine, but I ran into a snag. Probably later in the week I can finish and test runway lighting on that. However, when firing up a build on the Voodoo3 machine from July (that had the original runway lighting) it looked fine, or the same, height-wise. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] screen shots lights
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 component until you are >30m AGL, but there is also a distance component that this doesn't account for. > As long as the aircraft position isn't greater than 30m higher than > wherever the lights are centered, then they'll stay at 0.5 meters. > That's good for almost all airports. Actually the distance used is current height above the ground, not height above the center of the tile. > The lights are about twice as high though when the YASim fdm is > used. This seems weird...thought I knew why before...but now I'm > not sure. Start up the c310 in each FDM at KSFO, put the parking > brake on, go to chase view, and adjust the eye level close to the > ground and look at the lighting height as compared to the aircraft > image. They are higher under YASim. Starting at the default airport (KSFO) at the default runway (28L) I'm not seeing this. Yasim pitches the C172 model a little more nose up when sitting on the ground, but the lights cut through the model at almost exactly the same height. With the C310, JSBSim sits the model a bit lower, so the wheels are slightly submerged, so in this case, the lights are actually higher relative to the aircraft than with the yasim C310 ... my observations anyway ... I don't see a difference in light height between FDM's ... they do position the aircraft 3d model a bit differently though, maybe that's what you are seeing? Regards, Curt. -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] screen shots lights
"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 distance component... > > As long as the aircraft position isn't greater than 30m higher than > > wherever the lights are centered, then they'll stay at 0.5 meters. > > That's good for almost all airports. > > Actually the distance used is current height above the ground, not > height above the center of the tile. Right, but the "AGL translation" based on the aircraft altitude, so that if aircraft is at a high spot on the airport the lights rise uniformly. Isn't that correct? That is what "got corrected" by the patch. No matter what runway you are on, the lights are always the same distance off the ground with the patch. > almost exactly the same height. With the C310, JSBSim sits the model > a bit lower, so the wheels are slightly submerged, so in this case, > the lights are actually higher relative to the aircraft than with the > yasim C310 ... my observations anyway ... I don't see a difference > in light height between FDM's ... they do position the aircraft 3d > model a bit differently though, maybe that's what you are seeing? Doh! Sorry about that, you are correct. And under YASim the c310 wheels are even hovering a bit above the ground, exagerating the effect. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] screen shots lights
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 not sure what you mean by distance component... 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. > > > As long as the aircraft position isn't greater than 30m higher than > > > wherever the lights are centered, then they'll stay at 0.5 meters. > > > That's good for almost all airports. > > > > Actually the distance used is current height above the ground, not > > height above the center of the tile. > > Right, but the "AGL translation" based on the aircraft altitude, so that > if aircraft is at a high spot on the airport the lights rise > uniformly. Isn't that correct? We are using the AGL altitude, i.e. the distance above the ground, so if you taxi from a low spot to a high spot, your AGL hasn't changed. Most likely you are seeing a change in "dist". > That is what "got corrected" by the patch. No matter what runway > you are on, the lights are always the same distance off the ground > with the patch. 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 reshuffling of the runway light section of the scene graph ... Curt. -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] screen shots lights
"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? > > Right, but the "AGL translation" based on the aircraft altitude, so that > > if aircraft is at a high spot on the airport the lights rise > > uniformly. Isn't that correct? > > We are using the AGL altitude, i.e. the distance above the ground, so > if you taxi from a low spot to a high spot, your AGL hasn't changed. > Most likely you are seeing a change in "dist". Hmmm...yeah I realized that was the case 10 minutes after I sent the message...sigh. > > That is what "got corrected" by the patch. No matter what runway > > you are on, the lights are always the same distance off the ground > > with the patch. > > 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. > I'll have to look at the code more closely. The last time I followed it through I was looking into that agl related viewer bug...something is there that I don't remember or understand. BTW can someone give me a starting position where the lights are unusually high? Still haven't been able to reproduce this. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] screen shots lights
"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 reshuffling of the runway light section of > the scene graph ... > Curt, 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 problem finding an aircraft position that shows the lights being screwy.When I get a build on the Voodoo machine I'll see what I get, and play around with some ideas on that and the gforce2 before making any more half baked suggestions. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] screen shots lights
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 > problem finding an aircraft position that shows the lights being > screwy. When I get a build on the Voodoo machine I'll see what I > get, and play around with some ideas on that and the gforce2 before > making any more half baked suggestions. The biggest problem comes when something is far away but at a low angle (i.e. the lights at the other end of the runway). All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] screen shots lights
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, knowing what is happening, I now have no > > problem finding an aircraft position that shows the lights being > > screwy. When I get a build on the Voodoo machine I'll see what I > > get, and play around with some ideas on that and the gforce2 before > > making any more half baked suggestions. > > The biggest problem comes when something is far away but at a low > angle (i.e. the lights at the other end of the runway). 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? 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 a bit further. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] screen shots lights
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 happening, I now have no > > problem finding an aircraft position that shows the lights being > > screwy. When I get a build on the Voodoo machine I'll see what I > > get, and play around with some ideas on that and the gforce2 before > > making any more half baked suggestions. > > The biggest problem comes when something is far away but at a low > angle (i.e. the lights at the other end of the runway). And that's the worst case scenario for drawing things that are close together at a distance. Mipmapping also goes to h-e-double-hockey-sticks in those circumstances. Runways (and roads in a driving sim) are about the worst case scenario for every component of them you'd want to draw, and every way you can think of to draw them. Curt. -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] screen shots lights
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 > a bit further. 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 ... Curt. -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] screen shots lights
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], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] screen shots lights
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 single block (up or down) so any slope you are seeing must reflect the underlying slope of the terrain. Curt. -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] screen shots lights
"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 boundry bug...it needs to be looked into it > > a bit further. > > 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 ... 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. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] screen shots lights
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 section of XF86Config4, just add DefaultColorDepth 16 I generally use 16bpp so that I can get decent framerates at 1600x1200 with my GeForce2Go. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] screen shots lights
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 16bpp for testing > purposes. Inside the Screen section of XF86Config4, just add > > DefaultColorDepth 16 > > I generally use 16bpp so that I can get decent framerates at > 1600x1200 with my GeForce2Go. No kidding? I didn't realize that scaled the depth buffer bpp as well. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] screen shots lights
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 buffer with 32bpp if you want (well, on some cards -- I'm sure there are all sorts of crazy hardware dependencies here). I believe that glut is the code that automatically picks the depth buffer precision to match the color buffers. Andy -- Andrew J. RossNextBus Information Systems Senior Software Engineer Emeryville, CA [EMAIL PROTECTED] http://www.nextbus.com "Men go crazy in conflagrations. They only get better one by one." - Sting (misquoted) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] screen shots lights
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], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] screen shots lights
"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 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? Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] screen shots lights
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 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. Curt. -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] screen shots lights
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 GeForce card over the 16bpp for testing > purposes. Inside the Screen section of XF86Config4, just add > > DefaultColorDepth 16 > > I generally use 16bpp so that I can get decent framerates at > 1600x1200 with my GeForce2Go. > > > All the best, > > > David I'd probably `startx -- -depth 16` instead, unless I wanted 16 as the default. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] screen shots lights
"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 no :-) Been plugging in values and testing with unexpected results
(recompiling alot) and probably forgot to do a make that time (sigh).
Anyway, here's a patch that seems to improve things quite a bit at 16bpp.
Also, the shift at tile boundry is gone. Note that I have only checked about
4 airports with this patch so let me know how it works for you.
The diff patch is below. The full file is at:
http://www.spiderbark.com/fgfs/tileentry-rwylightspatch.tar.gz
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/Scenery/tileentry.cxx 29 Oct 2002 19:44:04 - 1.10
+++ src/Scenery/tileentry.cxx 30 Oct 2002 20:45:34 -
@@ -892,7 +892,8 @@
agl = globals->get_current_view()->getAltitudeASL_ft()
* SG_FEET_TO_METER - globals->get_scenery()->get_cur_elev()
- 30.0;
-if ( agl < 30.0 ) {
+// make sure we're at or above 0 so we don't burry the lights
+if ( agl < 0 ) {
agl = 0.0;
}
@@ -901,18 +902,31 @@
// is what we want to calculate the distance of
sgVec3 to;
sgCopyVec3( to, sgTrans );
-double dist = sgLengthVec3( to );
-if ( general.get_glDepthBits() > 16 ) {
-sgScaleVec3( lift_vec, 0.0 + agl / 500.0 + dist / 1 );
-} else {
-sgScaleVec3( lift_vec, 1.0 + agl / 20.0 + dist / 5000 );
+ // we fudge the distance (dist) by 15000 meters to that the distance
+ // component of the lifting function doesn't phase in unless the
airport is
+ // more than 15000m from the scenery center
+double dist = 0;
+ dist = sgLengthVec3( to ) - 15000;
+// make sure we're at or above zero
+if (dist < 0) {
+dist = 0.0;
}
-sgVec3 lt_trans;
-sgCopyVec3( lt_trans, sgTrans );
+ sgVec3 lt_trans;
+ sgCopyVec3( lt_trans, sgTrans );
-sgAddVec3( lt_trans, lift_vec );
+// skip this step if both the distance and agl are > 1
+// see above where the values are fudged down to allow correct display
+// when aircraft is "at" the airport.
+if (dist > 1 || agl > 1) {
+if ( general.get_glDepthBits() > 16 ) {
+sgScaleVec3( lift_vec, 0.0 + agl / 500.0 + dist / 1 );
+} else {
+sgScaleVec3( lift_vec, 1.0 + agl / 20.0 + dist / 5000 );
+}
+sgAddVec3( lt_trans, lift_vec );
+}
rwy_lights_transform->setTransform( lt_trans );
// select which set of lights based on sun angle
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] screen shots lights
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 jumping when > > crossing a tile boundary. > Curt, It finally occured to me that we might not actually need a distance component for lifting the runway lights. I can't see any difference from the air (even at lower altitudes) with or without the distance component at 16bpp. Maybe we should revise that patch to just elimiate that? Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] screen shots lights
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 see if you still see a jumping when > > > crossing a tile boundary. > > > > Curt, > > It finally occured to me that we might not actually need a distance component > for lifting the runway lights. I can't see any difference from the air (even > at lower altitudes) with or without the distance component at 16bpp. > > Maybe we should revise that patch to just elimiate that? 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. Regards, Curt. -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] screen shots lights
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/Scenery/tileentry.cxx 29 Oct 2002 19:44:04 - 1.10
+++ src/Scenery/tileentry.cxx 30 Oct 2002 21:59:14 -
@@ -892,7 +892,8 @@
agl = globals->get_current_view()->getAltitudeASL_ft()
* SG_FEET_TO_METER - globals->get_scenery()->get_cur_elev()
- 30.0;
-if ( agl < 30.0 ) {
+// make sure we're at or above 0 so we don't burry the lights
+if ( agl < 0 ) {
agl = 0.0;
}
@@ -901,18 +902,21 @@
// is what we want to calculate the distance of
sgVec3 to;
sgCopyVec3( to, sgTrans );
-double dist = sgLengthVec3( to );
-
-if ( general.get_glDepthBits() > 16 ) {
-sgScaleVec3( lift_vec, 0.0 + agl / 500.0 + dist / 1 );
-} else {
-sgScaleVec3( lift_vec, 1.0 + agl / 20.0 + dist / 5000 );
-}
sgVec3 lt_trans;
sgCopyVec3( lt_trans, sgTrans );
-sgAddVec3( lt_trans, lift_vec );
+// skip this step if both the agl is < 1
+// see above where the values are fudged down to allow correct display
+// when aircraft is "at" the airport.
+if ( agl > 1) {
+if ( general.get_glDepthBits() > 16 ) {
+sgScaleVec3( lift_vec, 0.0 + agl / 500.0 );
+} else {
+sgScaleVec3( lift_vec, 1.0 + agl / 20.0 );
+}
+sgAddVec3( lt_trans, lift_vec );
+}
rwy_lights_transform->setTransform( lt_trans );
// select which set of lights based on sun angle
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] screen shots lights
"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) {
instead of:
if (agl < 30.0) {
Note that the 30m is subtracted in the previous line of code, and doing it again
(essentially) on line 899 makes the fudge 60m and creates a "jump" in the
lights when you hit 60m altitude.
Best,
Jim
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] screen shots lights
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 PROTECTED]> said:
> "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) {
>
> instead of:
>
> if (agl < 30.0) {
>
> Note that the 30m is subtracted in the previous line of code, and doing it
again
> (essentially) on line 899 makes the fudge 60m and creates a "jump" in the
> lights when you hit 60m altitude.
>
> Best,
>
> Jim
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] screen shots lights
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 what you added to cvs.
>
> Line 899 should read:
>
> if (agl < 0.0) {
>
> instead of:
>
> if (agl < 30.0) {
>
> Note that the 30m is subtracted in the previous line of code, and doing it again
> (essentially) on line 899 makes the fudge 60m and creates a "jump" in the
> lights when you hit 60m altitude.
>
> Best,
>
> Jim
>
> ___
> Flightgear-devel mailing list
> [EMAIL PROTECTED]
> http://mail.flightgear.org/mailman/listinfo/flightgear-devel
--
Curtis Olson IVLab / HumanFIRST Program FlightGear Project
Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED]
Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
