[Flightgear-devel] Re: lighting
[glowing c172] * David Megginson -- Sunday 21 July 2002 16:31: > For reasons unknown, the effect is different depending on whether > you're inside or outside the plane. To spread even more confusion: The same day I noticed the glowing c172, all fog was gone for me and my outdated tdfx V3. This happens for all FDMs and models except the UFO and both yasim's and uiuc's 747! m. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: lighting
* Curtis L. Olson -- Monday 22 July 2002 14:24: > Melchior FRANZ writes: > > To spread even more confusion: The same day I noticed the glowing > > c172, all fog was gone for me and my outdated tdfx V3. This happens > > for all FDMs and models except the UFO and both yasim's and uiuc's > > 747! > > Do we know what day that was, or what major things were changed that > day? This could be some weird opengl state management problem > introduced by one of our modules ... I don't know exactly the date, but it must have been between the 28th and the 30th of june, because I reported back then: | Re: 3d Panel problem | Date: Sun, 30 Jun 2002 10:16:39 +0200 | From: Melchior FRANZ <[EMAIL PROTECTED]> | | * Andy Ross -- Friday 28 June 2002 21:47: | > But the Voodoo cards have thinner depth buffers, and | > I'm using a pretty large offset value to begin with. Let me tune a | > little and see how much smaller I can make it. | | So that is why fgfs doesn't work right any more on my Voodoo3. :-( | | I don't see any fog/haze now. [...] ... and the c172 started to glow the same day! I could track down the very patch that broke it, if necessary. I only have a slooow net connection, though, and I'd rather get along without that pain. :-] m. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: lighting
* Melchior FRANZ -- Monday 22 July 2002 15:32: > I don't know exactly the date, but it must have been between the 28th > and the 30th of june, because I reported back then: > > | Re: 3d Panel problem > | Date: Sun, 30 Jun 2002 10:16:39 +0200 > | From: Melchior FRANZ <[EMAIL PROTECTED]> > | > | * Andy Ross -- Friday 28 June 2002 21:47: > | > But the Voodoo cards have thinner depth buffers, and [...] ... and given that Andy posted this on the 28th, the suspicious changes could be these: | CVS: FlightGear/src/Cockpit panel.cxx,1.72,1.73 panel.hxx,1.41,1.42 | Date: Fri, 28 Jun 2002 07:17:44 -0500 | From: David Megginson <[EMAIL PROTECTED]> | Log Message: 3D panel support from Andy Ross m. ?? ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: lighting
* Andy Ross -- Monday 22 July 2002 18:56: > I'm fuzzy on what the exact problem is, though. Could you post a > screenshot? Just look at http://www.flightgear.org/images/farm.jpg ;-) m. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: lighting
* Curtis L. Olson -- Monday 22 July 2002 20:00: > If you go to src/Model/model.cxx, line #248 and comment out the > "Load panels" section of code, the C172 becomes shaded again and > the objects no longer glow at night. Unfortunately, it doesn't fix my fog problem. m. :-( ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: lighting
* Curtis L. Olson -- Monday 22 July 2002 22:07: > Melchior FRANZ writes: > > Unfortunately, it doesn't fix my fog problem. > > You could look through src/Model/*.cxx and find the place[s] that > reset the clip planes and comment those out to see if your fog comes > back. OK, thanks. I'll try. :-) m. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: lighting
* Melchior FRANZ -- Monday 22 July 2002 22:25: > * Curtis L. Olson -- Monday 22 July 2002 22:07: > > You could look through src/Model/*.cxx and find the place[s] that > > reset the clip planes and comment those out to see if your fog comes > > back. > > OK, thanks. I'll try. :-) ... tried, but failed. m. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: lighting
Melchior FRANZ writes: > [glowing c172] > * David Megginson -- Sunday 21 July 2002 16:31: > > For reasons unknown, the effect is different depending on whether > > you're inside or outside the plane. > > To spread even more confusion: The same day I noticed the glowing > c172, all fog was gone for me and my outdated tdfx V3. This happens > for all FDMs and models except the UFO and both yasim's and uiuc's > 747! Do we know what day that was, or what major things were changed that day? This could be some weird opengl state management problem introduced by one of our modules ... I hope not because these can be among the toughest problems to debug, but it would be good to know when this was introduced. I don't think any GeForce users are having fog problems though. 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] Re: lighting
Curtis L. Olson writes: > Melchior FRANZ writes: > > [glowing c172] > > * David Megginson -- Sunday 21 July 2002 16:31: > > > For reasons unknown, the effect is different depending on whether > > > you're inside or outside the plane. > > > > To spread even more confusion: The same day I noticed the glowing > > c172, all fog was gone for me and my outdated tdfx V3. This happens > > for all FDMs and models except the UFO and both yasim's and uiuc's > > 747! > > Do we know what day that was, or what major things were changed that > day? This could be some weird opengl state management problem > introduced by one of our modules ... I hope not because these can be > among the toughest problems to debug, but it would be good to know > when this was introduced. I don't think any GeForce users are having > fog problems though. Some more thoughts ... Could anyone pull an earlier version of the C172 3d model out of CVS to see if the problem was a change in the 3d model or a change in the source code? The 3d aircraft drawing code changes the near/far clip planes which could account for why you have lost your fog. I seem to remember this as a being a bug in the mesa/3dfx driver. (i.e. the fog tables are calculated for a specific near/far clip and if you change the clip planes, the fog tables aren't updated and you get weird results.) This isn't a big deal if you nudge the clip planes a bit, but could be a very big deal if they are changed radically. We could be looking at two separate problems here ... 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] Re: lighting
Melchior FRANZ wrote: > ... and given that Andy posted this on the 28th, the suspicious > changes could be these: > > | Log Message: 3D panel support from Andy Ross Could be. These changes moved the panel rendering into the main scene graph. If the panel code changes any OpenGL lighting state without setting it back, then this could cause symptoms like this. We just need to find out what's wrong and where it's being set. I'm fuzzy on what the exact problem is, though. Could you post a screenshot? 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] Re: lighting
The problem appears when we are in an outside view, not when the panel obsure half the screen. So I can be wrong but I wouldn't search there first. Cheers, -Fred >Messsage du 22/07/2002 18:56 >De : <[EMAIL PROTECTED]> >A : <[EMAIL PROTECTED]> >Copie à : >Objet : Re: [Flightgear-devel] Re: lighting > > Melchior FRANZ wrote: > > ... and given that Andy posted this on the 28th, the suspicious > > changes could be these: > > > > | Log Message: 3D panel support from Andy Ross > > Could be. These changes moved the panel rendering into the main scene > graph. If the panel code changes any OpenGL lighting state without > setting it back, then this could cause symptoms like this. We just > need to find out what's wrong and where it's being set. > > I'm fuzzy on what the exact problem is, though. Could you post a > screenshot? > > 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 > ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: lighting
Andy Ross writes: > Melchior FRANZ wrote: > > ... and given that Andy posted this on the 28th, the suspicious > > changes could be these: > > > > | Log Message: 3D panel support from Andy Ross > > Could be. These changes moved the panel rendering into the main scene > graph. If the panel code changes any OpenGL lighting state without > setting it back, then this could cause symptoms like this. We just > need to find out what's wrong and where it's being set. When you say moved panel rendering into the main scene graph, do you mean that you ssg-ified the entire panel so it is automatically drawn in the main ssgCullAndDraw() along with everything else, or do you mean the panel rendering code get's executed as a call back from some ssg node, or do you mean something else? > I'm fuzzy on what the exact problem is, though. Could you post a > screenshot? With the latest cvs code, look at an external view of the C172 at night ... it should be bright white ... 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] Re: lighting
Andy Ross writes: > Melchior FRANZ wrote: > > ... and given that Andy posted this on the 28th, the suspicious > > changes could be these: > > > > | Log Message: 3D panel support from Andy Ross > > Could be. These changes moved the panel rendering into the main scene > graph. If the panel code changes any OpenGL lighting state without > setting it back, then this could cause symptoms like this. We just > need to find out what's wrong and where it's being set. > > I'm fuzzy on what the exact problem is, though. Could you post a > screenshot? Ok, that was definitely helpful. If you go to src/Model/model.cxx, line #248 and comment out the "Load panels" section of code, the C172 becomes shaded again and the objects no longer glow at night. So something about the panel drawing is messing up the opengl state. Is there stuff in there that happens via callbacks, or is it all done in "pure" ssg? 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] Re: lighting
Curtis L. Olson wrote: > When you say moved panel rendering into the main scene graph, do you > mean [...] or do you mean the panel rendering code get's executed as > a call back from some ssg node [...] ? I mean that one. :) There's a tiny "FGPanelNode" ssgLeaf class that wraps an FGPanel object. It sets up the matrix stack appropriately and then calls the panel renderer as normal. Does anyone know off the top of their heads if the panel code changes the OpenGL lighting or material state? If it does, then this will be a really simple fix. 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] Re: lighting
Curtis L. Olson writes:
>
>Ok, that was definitely helpful. If you go to src/Model/model.cxx,
>line #248 and comment out the "Load panels" section of code, the C172
>becomes shaded again and the objects no longer glow at night.
Good one !
Looks like we need something like
void
FGPanel::draw()
{
glPushAttrib( GL_ENABLE_BIT | GL_POLYGON_BIT | GL_COLOR_BUFFER_BIT |
GL_LIGHTING_BIT ) ;
.
glPopAttrib();
}
Not sure if I got them all
Norman
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: lighting
Andy Ross writes: > Does anyone know off the top of their heads if the panel code changes > the OpenGL lighting or material state? If it does, then this will be > a really simple fix. Yes, it does -- it was designed to work outside of the SSG scene graph. 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] Re: lighting
Curtis L. Olson writes: > Ok, that was definitely helpful. If you go to src/Model/model.cxx, > line #248 and comment out the "Load panels" section of code, the C172 > becomes shaded again and the objects no longer glow at night. The funny thing is that this happens even when no panel is visible. 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] Re: lighting
David Megginson writes:
> Curtis L. Olson writes:
>
> > Ok, that was definitely helpful. If you go to src/Model/model.cxx,
> > line #248 and comment out the "Load panels" section of code, the C172
> > becomes shaded again and the objects no longer glow at night.
>
> The funny thing is that this happens even when no panel is visible.
I just committed a fix to save/restore state before drawing the '3d'
panel.
I should point out a little opengl background for those that care:
Querying the current opengl state is really bad because opengl can
pipeline commands and is a 'single' state engine. To properly answer
a query, the driver must flush the pipeline and then answer the
query. This can be very disruptive to performance, especially if done
many times per frame.
Just the act of changing opengl state (i.e. different color mode,
blend mode, changing lighting, fog, clip planes, etc.) can have an
impact on performance ... especially on systems that implement more of
the opengl pipeline in hardware. I will say that modern cards/systems
seem to be have much more optimized state changers that systems from a
a few years ago.
Even so, once you through a zillion objects into your scene each with
different textures, etc. you can imagine a zillion state changes are
needed per rendered frame. This will impact performance on any
system.
So, there are two rules of thumb when writing opengl programs. 1)
Minimize your state changes 2) never query for the current value of an
opengl state.
ssg has built in state management which does a really nice job of
minimizing state changes. It keeps track of the more common states
for you in software and effeciently checks if something needs to be
changed when ever a new ssgSimpleState is applied.
If we could do all our state management in plib/ssg, that would be
ideal. Unfortunately: the real world creeps in once in a while and we
may need to change state variables not managed by plib. So we need to
do some of our own state management which means we need to be really
careful not to confuse ssg's lazy state changer.
This means a) we need to reset any state we change when we are done,
or b) force plib/ssg to completely reset the state. Usually a) is
more efficient than b)
But, remember the 2nd rule of thumb above, "*NEVER* query for the
current opengl state." So now what? The "state" could be anything
and we need to set it back after we change it. Enter glPushAttrib() /
glPopAttrib()
There are 23 attrib bits that opengl defines for use with
gl{Push,Pop}Attrib(). Each attribute bit covers several related
opengl state variables. (See the red book for more info.)
If we plan to change a lighting related state variable and a color
related state variable in our routine we can first do:
glPushAttrib( GL_COLOR_BUFFER_BIT GL_LIGHTING_BIT );
This pushes those related state variables onto the stack. We don't
care what they are, we aren't querying their value, but we are saving
them.
Then the routine can proceed to do whatever it needs to do.
Finally at the end we do:
glPopAttrib();
So there you go, we saved and restored the opengl state so we didn't
confuse plib/ssg or leave some weird state value set that screws up
some other rendering portion of the code. We hopefully have minimized
any needed state changes. And we managed to do it all without
querying for a specific state value and thus disrupting the pipeline.
Again all this is said with apologies to those that know more about
this than I do. :-)
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] Re: lighting
David Megginson writes: > Curtis L. Olson writes: > > > Ok, that was definitely helpful. If you go to src/Model/model.cxx, > > line #248 and comment out the "Load panels" section of code, the C172 > > becomes shaded again and the objects no longer glow at night. > > The funny thing is that this happens even when no panel is visible. Are you still seeing this sort of weirdness with my most recent patch? 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] Re: lighting
Norman Vine writes:
> Curtis L. Olson writes:
> >
> >Ok, that was definitely helpful. If you go to src/Model/model.cxx,
> >line #248 and comment out the "Load panels" section of code, the C172
> >becomes shaded again and the objects no longer glow at night.
>
> Good one !
>
> Looks like we need something like
>
> void
> FGPanel::draw()
> {
> glPushAttrib( GL_ENABLE_BIT | GL_POLYGON_BIT | GL_COLOR_BUFFER_BIT |
> GL_LIGHTING_BIT ) ;
> .
> glPopAttrib();
> }
>
> Not sure if I got them all
I added a couple more, just to be safe, but that pretty much did it I
think.
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] Re: lighting
Ahhh, rectangular livestock! Must make them easy to stack for shipment, eh? :) g. On Mon, 22 Jul 2002, Melchior FRANZ wrote: > * Andy Ross -- Monday 22 July 2002 18:56: > > I'm fuzzy on what the exact problem is, though. Could you post a > > screenshot? > > Just look at http://www.flightgear.org/images/farm.jpg ;-) > > m. > > > > ___ > Flightgear-devel mailing list > [EMAIL PROTECTED] > http://mail.flightgear.org/mailman/listinfo/flightgear-devel > ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: lighting
Gene Buckle writes: > Ahhh, rectangular livestock! Must make them easy to stack for shipment, > eh? :) > > g. > > > On Mon, 22 Jul 2002, Melchior FRANZ wrote: > > > * Andy Ross -- Monday 22 July 2002 18:56: > > > I'm fuzzy on what the exact problem is, though. Could you post a > > > screenshot? > > > > Just look at http://www.flightgear.org/images/farm.jpg ;-) Either that, or David does some side consulting for Gateway... 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] Re: lighting
Curtis L. Olson writes: > > Ahhh, rectangular livestock! Must make them easy to stack for shipment, > > eh? :) > Either that, or David does some side consulting for Gateway... Nah -- I'm promoting Monsanto's new genetically-modified cows. 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] Re: lighting
Melchior FRANZ writes: > * Curtis L. Olson -- Monday 22 July 2002 20:00: > > If you go to src/Model/model.cxx, line #248 and comment out the > > "Load panels" section of code, the C172 becomes shaded again and > > the objects no longer glow at night. > > Unfortunately, it doesn't fix my fog problem. I kind of guessed that may have been a separate issue. I think this is likely a side effect of changing the near/far clip planes in the middle of rendering a frame. I don't think the mesa/3dfx drivers handle that well or at all. You could look through src/Model/*.cxx and find the place[s] that reset the clip planes and comment those out to see if your fog comes back. 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] Re: lighting
From: "Curtis L. Olson" <[EMAIL PROTECTED]> > David Megginson writes: > > Curtis L. Olson writes: > > > > > Ok, that was definitely helpful. If you go to src/Model/model.cxx, > > > line #248 and comment out the "Load panels" section of code, the C172 > > > becomes shaded again and the objects no longer glow at night. > > > > The funny thing is that this happens even when no panel is visible. > > I just committed a fix to save/restore state before drawing the '3d' > panel. Yes, no more chrismas trees at night ... Cheers, -Fred ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: lighting
Frederic Bouvier writes: > From: "Curtis L. Olson" <[EMAIL PROTECTED]> > > David Megginson writes: > > > Curtis L. Olson writes: > > > > > > > Ok, that was definitely helpful. If you go to src/Model/model.cxx, > > > > line #248 and comment out the "Load panels" section of code, the C172 > > > > becomes shaded again and the objects no longer glow at night. > > > > > > The funny thing is that this happens even when no panel is visible. > > > > I just committed a fix to save/restore state before drawing the '3d' > > panel. > > Yes, no more chrismas trees at night ... I do very much want to thank everyone who participated in quickly tracking down and nailing this problem. Opengl state management problems can be a *huge* bear to find and debug (for many of the same reasons that goto's are usually bad.) It is quite a relief to have found and fixed this one so quickly, but it never could have been done without everyone pitching in. Open-source in action. :-) Thanks! 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] Re: lighting
Melchior FRANZ writes: > * Melchior FRANZ -- Monday 22 July 2002 22:25: > > * Curtis L. Olson -- Monday 22 July 2002 22:07: > > > You could look through src/Model/*.cxx and find the place[s] that > > > reset the clip planes and comment those out to see if your fog comes > > > back. > > > > OK, thanks. I'll try. :-) > > ... tried, but failed. You might also grep through other portions of the code to see if you can find other clip plane changes and try eliminating those as well. 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] Re: lighting
On Sun, 21 Jul 2002 18:01:01 +0200, Melchior FRANZ <[EMAIL PROTECTED]> wrote in message <[EMAIL PROTECTED]>: > [glowing c172] > * David Megginson -- Sunday 21 July 2002 16:31: > > For reasons unknown, the effect is different depending on whether > > you're inside or outside the plane. > > To spread even more confusion: The same day I noticed the glowing > c172, all fog was gone for me and my outdated tdfx V3. This happens > for all FDMs and models except the UFO and both yasim's and uiuc's > 747! ..uhmmm, both UFO's (We still have both the new and old UFO?) and both the YaSim and UIUC jumbos hide in the fog too? Foggy today. ;-) -- ..med vennlig hilsen = with Kind Regards from Arnt... ;-) ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: lighting
"Curtis L. Olson" <[EMAIL PROTECTED]> said: > I do very much want to thank everyone who participated in quickly > tracking down and nailing this problem. Opengl state management > problems can be a *huge* bear to find and debug (for many of the same > reasons that goto's are usually bad.) It is quite a relief to have > found and fixed this one so quickly, but it never could have been done > without everyone pitching in. Open-source in action. :-) > It's even nicer when it something gets fixed while you're away on vacation :-) Just before I left I posted a quiet query about this problem and had eliminated the in the model differences possibility. Even thought about the textures...for a minute. But sitting on the beach this last week, my mind wandered "off topic" and onto flight gear and I made a mental note to try turning off the new panel node when i got back (just a hunch...not really understanding why :-)). And wha'd'ya know...it's been fixed! BTW a texture glitch that was in the 3D AI is now gone as well. Very cool! Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
