Frederic BOUVIER writes:
> [ The lists seems to have been down last 20 hours. I apologize if it
> already appeared ] 
> 
> I discovered that only textures with an alpha channel are glowing at
> night, and only when the c172 is in the view. Try the 4th view (
> free tower view ) and the magic fdm. When the 172 is viewed, trees
> around are emitting light but when you move to clip it away, trees
> stop shining. 
> 
> I modified my tower-hexa-2.rgb texture to remove the alpha channel (
> export to bmp and reimport ) and the tower stopped glowing. 

Very interesting observation.  I can confirm this too.  The other
objects (trees/bldgs) only appear to glow when the 3d c172 is in view.
I don't know if this is a specific problem with the c172 though.  I
see the same effect with the a4 and c310.  I don't see this problem
with the dc3 or 747.

So, it seems an awful lot like an opengl state management issue
related to drawing the 3d aircraft model.

The question I am asking myself is what is different between the
a4/c310/c172 and the dc3/747 models?  Do the a4/c310/c172 do something
different from the the other two models which plib isn't accounting
for?  Is it a problem in the aircraft model drawing code?  Panel
drawing code?  A bug in plib, not reseting state correctly?

The problem only seems to happen when the 3d model is in the view.  To
me, that would point to a problem with the model, or a problem with
plib's handling of the model.  For instance if the 3d model tickles
some material or lighting feature that plib doesn't normally handle or
doesn't handle at all.  But, I would be (maybe very) surprised to find
such a bug in plib that no one else has discovered previously.

I'm going to guess that more likely, we are setting some opengl state
someplace in the code which by chance, some 3d models might cause to
be reset, and others not.  Plib has a 'lazy' state evaluator so it
only changes the states it thinks need to be changed.  If we change
state ourselves separately, then plib might not change a state when it
needs to (very bad.)

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

Reply via email to