RE: [Flightgear-devel] lighting at KOAK
Curtis L. Olson [EMAIL PROTECTED] said: I made some changes to the lighting code (in cvs). See if this improves the reliability of airport lighting in the area. This made a big difference. KSQL and KHAF work fine now, but it's still dark at KOAK. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] lighting at KOAK
Jim Wilson writes: Curtis L. Olson [EMAIL PROTECTED] said: I made some changes to the lighting code (in cvs). See if this improves the reliability of airport lighting in the area. This made a big difference. KSQL and KHAF work fine now, but it's still dark at KOAK. Are you making sure your in line with a runway (otherwise they can be really hard to see.) 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] lighting at KOAK
On Monday 21 October 2002 03:13 pm, Curtis L. Olson wrote: I made some changes to the lighting code (in cvs). See if this improves the reliability of airport lighting in the area. Still nothing at KOAK. The fade-in/fade-out code seems to be much improved. Wm -- William L. Riley [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] lighting at KOAK
Curtis L. Olson [EMAIL PROTECTED] said: Jim Wilson writes: Curtis L. Olson [EMAIL PROTECTED] said: I made some changes to the lighting code (in cvs). See if this improves the reliability of airport lighting in the area. This made a big difference. KSQL and KHAF work fine now, but it's still dark at KOAK. Are you making sure your in line with a runway (otherwise they can be really hard to see.) Yes. I'm having no problem seeing all the other fields in the area that I know of. Been using magic carpet to check them out quickly. KOAK has no lights. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] lighting at KOAK
Jim Wilson writes: Yes. I'm having no problem seeing all the other fields in the area that I know of. Been using magic carpet to check them out quickly. KOAK has no lights. Strange ... you could use simgear/io/decode_binobj KOAK.btg.gz to see if it actually contains any runway lights ... 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] lighting at KOAK
Curtis L. Olson [EMAIL PROTECTED] said: Jim Wilson writes: Yes. I'm having no problem seeing all the other fields in the area that I know of. Been using magic carpet to check them out quickly. KOAK has no lights. Strange ... you could use simgear/io/decode_binobj KOAK.btg.gz to see if it actually contains any runway lights ... Not sure what to be looking for, but here's a list of comments dumped from the KOAK.btg.gz file: # FGFS Scenery # Version 6 # gbs -2687402.09000 -4279936.40317 3878054.00110 11196.79 # vertex list # vertex normal list # texture coordinate list # geometry groups # usemtl RWY_WHITE_MEDIUM_LIGHTS # usemtl RWY_YELLOW_MEDIUM_LIGHTS # usemtl RWY_WHITE_MEDIUM_LIGHTS # usemtl RWY_YELLOW_MEDIUM_LIGHTS # usemtl RWY_VASI_LIGHTS # usemtl RWY_VASI_LIGHTS # usemtl RWY_GREEN_LIGHTS # usemtl RWY_RED_LIGHTS # usemtl RWY_WHITE_LIGHTS # usemtl RWY_WHITE_MEDIUM_LIGHTS # usemtl RWY_YELLOW_MEDIUM_LIGHTS # usemtl RWY_WHITE_MEDIUM_LIGHTS # usemtl RWY_YELLOW_MEDIUM_LIGHTS # usemtl RWY_VASI_LIGHTS # usemtl RWY_VASI_LIGHTS # usemtl RWY_WHITE_MEDIUM_LIGHTS # usemtl RWY_YELLOW_MEDIUM_LIGHTS # usemtl RWY_WHITE_MEDIUM_LIGHTS # usemtl RWY_YELLOW_MEDIUM_LIGHTS # usemtl RWY_WHITE_MEDIUM_LIGHTS # usemtl RWY_RED_MEDIUM_LIGHTS # usemtl RWY_WHITE_MEDIUM_LIGHTS # usemtl RWY_RED_MEDIUM_LIGHTS # usemtl RWY_WHITE_LIGHTS # usemtl RWY_REIL_LIGHTS # usemtl RWY_REIL_LIGHTS # usemtl RWY_GREEN_LIGHTS # usemtl RWY_RED_LIGHTS # usemtl RWY_WHITE_LIGHTS # usemtl RWY_SEQUENCED_LIGHTS # usemtl RWY_GREEN_LIGHTS # usemtl RWY_RED_LIGHTS # usemtl RWY_WHITE_LIGHTS # usemtl RWY_GREEN_MEDIUM_LIGHTS # usemtl RWY_RED_MEDIUM_LIGHTS # usemtl RWY_GREEN_MEDIUM_LIGHTS # usemtl RWY_RED_MEDIUM_LIGHTS # usemtl RWY_WHITE_MEDIUM_LIGHTS # usemtl RWY_YELLOW_MEDIUM_LIGHTS # usemtl RWY_WHITE_MEDIUM_LIGHTS # usemtl RWY_YELLOW_MEDIUM_LIGHTS # usemtl pc_R # usemtl pc_L # usemtl pc_9c # usemtl pc_2l # usemtl pc_7r # usemtl pc_rest # usemtl pa_L # usemtl pa_R # usemtl pa_9c # usemtl pa_2l # usemtl pa_7r # usemtl pa_rest # usemtl pa_11 # usemtl pa_2l # usemtl pa_9r # usemtl pa_rest # usemtl pa_1l # usemtl pa_5r # usemtl pa_3l # usemtl pa_3r # usemtl pa_rest # usemtl pa_taxiway # usemtl Grass # usemtl Grass ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] lighting at KOAK
Jim Wilson writes: Not sure what to be looking for, but here's a list of comments dumped from the KOAK.btg.gz file: That's the sort of stuff you want to see. I could send you a KOAK.btg.gz generated here. That would tell you if it's an issue with how the KOAK file is generated or something on the rendering end. Curt. # FGFS Scenery # Version 6 # gbs -2687402.09000 -4279936.40317 3878054.00110 11196.79 # vertex list # vertex normal list # texture coordinate list # geometry groups # usemtl RWY_WHITE_MEDIUM_LIGHTS # usemtl RWY_YELLOW_MEDIUM_LIGHTS # usemtl RWY_WHITE_MEDIUM_LIGHTS # usemtl RWY_YELLOW_MEDIUM_LIGHTS # usemtl RWY_VASI_LIGHTS # usemtl RWY_VASI_LIGHTS # usemtl RWY_GREEN_LIGHTS # usemtl RWY_RED_LIGHTS # usemtl RWY_WHITE_LIGHTS # usemtl RWY_WHITE_MEDIUM_LIGHTS # usemtl RWY_YELLOW_MEDIUM_LIGHTS # usemtl RWY_WHITE_MEDIUM_LIGHTS # usemtl RWY_YELLOW_MEDIUM_LIGHTS # usemtl RWY_VASI_LIGHTS # usemtl RWY_VASI_LIGHTS # usemtl RWY_WHITE_MEDIUM_LIGHTS # usemtl RWY_YELLOW_MEDIUM_LIGHTS # usemtl RWY_WHITE_MEDIUM_LIGHTS # usemtl RWY_YELLOW_MEDIUM_LIGHTS # usemtl RWY_WHITE_MEDIUM_LIGHTS # usemtl RWY_RED_MEDIUM_LIGHTS # usemtl RWY_WHITE_MEDIUM_LIGHTS # usemtl RWY_RED_MEDIUM_LIGHTS # usemtl RWY_WHITE_LIGHTS # usemtl RWY_REIL_LIGHTS # usemtl RWY_REIL_LIGHTS # usemtl RWY_GREEN_LIGHTS # usemtl RWY_RED_LIGHTS # usemtl RWY_WHITE_LIGHTS # usemtl RWY_SEQUENCED_LIGHTS # usemtl RWY_GREEN_LIGHTS # usemtl RWY_RED_LIGHTS # usemtl RWY_WHITE_LIGHTS # usemtl RWY_GREEN_MEDIUM_LIGHTS # usemtl RWY_RED_MEDIUM_LIGHTS # usemtl RWY_GREEN_MEDIUM_LIGHTS # usemtl RWY_RED_MEDIUM_LIGHTS # usemtl RWY_WHITE_MEDIUM_LIGHTS # usemtl RWY_YELLOW_MEDIUM_LIGHTS # usemtl RWY_WHITE_MEDIUM_LIGHTS # usemtl RWY_YELLOW_MEDIUM_LIGHTS # usemtl pc_R # usemtl pc_L # usemtl pc_9c # usemtl pc_2l # usemtl pc_7r # usemtl pc_rest # usemtl pa_L # usemtl pa_R # usemtl pa_9c # usemtl pa_2l # usemtl pa_7r # usemtl pa_rest # usemtl pa_11 # usemtl pa_2l # usemtl pa_9r # usemtl pa_rest # usemtl pa_1l # usemtl pa_5r # usemtl pa_3l # usemtl pa_3r # usemtl pa_rest # usemtl pa_taxiway # usemtl Grass # usemtl Grass ___ 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
RE: [Flightgear-devel] lighting at KOAK
riley@uranium ~/src/SimGear/simgear/io ./decode_binobj /images/fgfsbase/Scenery/w130n30/w123n37/KOAK.btg.gz | grep -i light # usemtl RWY_WHITE_MEDIUM_LIGHTS # usemtl RWY_YELLOW_MEDIUM_LIGHTS # usemtl RWY_WHITE_MEDIUM_LIGHTS # usemtl RWY_YELLOW_MEDIUM_LIGHTS # usemtl RWY_VASI_LIGHTS # usemtl RWY_VASI_LIGHTS # usemtl RWY_GREEN_LIGHTS # usemtl RWY_RED_LIGHTS # usemtl RWY_WHITE_LIGHTS # usemtl RWY_WHITE_MEDIUM_LIGHTS # usemtl RWY_YELLOW_MEDIUM_LIGHTS # usemtl RWY_WHITE_MEDIUM_LIGHTS # usemtl RWY_YELLOW_MEDIUM_LIGHTS # usemtl RWY_VASI_LIGHTS # usemtl RWY_VASI_LIGHTS # usemtl RWY_WHITE_MEDIUM_LIGHTS # usemtl RWY_YELLOW_MEDIUM_LIGHTS # usemtl RWY_WHITE_MEDIUM_LIGHTS # usemtl RWY_YELLOW_MEDIUM_LIGHTS # usemtl RWY_WHITE_MEDIUM_LIGHTS # usemtl RWY_RED_MEDIUM_LIGHTS # usemtl RWY_WHITE_MEDIUM_LIGHTS # usemtl RWY_RED_MEDIUM_LIGHTS # usemtl RWY_WHITE_LIGHTS # usemtl RWY_REIL_LIGHTS # usemtl RWY_REIL_LIGHTS # usemtl RWY_GREEN_LIGHTS # usemtl RWY_RED_LIGHTS # usemtl RWY_WHITE_LIGHTS # usemtl RWY_SEQUENCED_LIGHTS # usemtl RWY_GREEN_LIGHTS # usemtl RWY_RED_LIGHTS # usemtl RWY_WHITE_LIGHTS # usemtl RWY_GREEN_MEDIUM_LIGHTS # usemtl RWY_RED_MEDIUM_LIGHTS # usemtl RWY_GREEN_MEDIUM_LIGHTS # usemtl RWY_RED_MEDIUM_LIGHTS # usemtl RWY_WHITE_MEDIUM_LIGHTS # usemtl RWY_YELLOW_MEDIUM_LIGHTS # usemtl RWY_WHITE_MEDIUM_LIGHTS # usemtl RWY_YELLOW_MEDIUM_LIGHTS It appears there is lighting info there. That is on the base CVS scenery. I have flown all around KOAK using magic carpet and it is totally dark. The little two runway airport close by KOAK (SE I think) is happily flashing away. *shrug* Wm Original Message: - From: Curtis L. Olson [EMAIL PROTECTED] Date: Mon, 21 Oct 2002 20:44:53 -0500 To: [EMAIL PROTECTED] Subject: RE: [Flightgear-devel] lighting at KOAK Jim Wilson writes: Yes. I'm having no problem seeing all the other fields in the area that I know of. Been using magic carpet to check them out quickly. KOAK has no lights. Strange ... you could use simgear/io/decode_binobj KOAK.btg.gz to see if it actually contains any runway lights ... 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 mail2web - Check your email from the web at http://mail2web.com/ . ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] lighting
Frederic Bouvier writes: Wait... the tower-hexa only glow on certain faces and not on others. It's going strangers... Did you apply colour materials to some of the surfaces in Blender before you exported your model? 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] lighting
Lighting in opengl is not only specified by an abient and a diffuse component, but also by an emission and a specular. These four components are added together before rendering a primitive. Emission ( which I think is enabled on the C172) is a color component independet of any ambient or diffuse light setting. That's why it glows or shines even at night. I am pretty sure that when you remove that component the C172 will look ok. The specular component is the reflection of the light on the surface. You see this component only if you are looking to the surface and it's reflection hits the sun. I try do some ASCII arts to make clear: sun viewpoint \/ \ / \/ --- surface Juergen Am Sonntag, 21. Juli 2002 16:58 schrieb Frederic Bouvier: Curtis L. Olson writes: However, the C172 still stays fully illuminated all the time, even in the dead of night. Futhermore it is not shaded at all during the day relative to sun position. So, I my theory at this point is that this model must have the emmissive property set so it is always fully self illuminating? The glow (as opposed to sun illumination) is the result of a different and strange effect -- it depends on the non-textured rgb value of the surface, even though the surface is textured. Set rgb in the *.ac file to 1 1 1 (the default for many AC3D models exported from Blender) and the model glows at night; set rgb to 0 0 0 and the model is always black, even in the day time; set it to .5 .5 .5 and the model is always grey, etc. But wait, there's more ... For reasons unknown, the effect is different depending on whether you're inside or outside the plane. This is best illustrated by two screenshots of the same buildings, one from inside view and one from outside view: http://www.megginson.com/flightsim/inside-lighting.jpg http://www.megginson.com/flightsim/outside-lighting.jpg Notice that not only the plane starts to glow, but also the water tower and most of the buildings. For some reason, the rgb colour gets blended with the texture in external view (also in the two tower views) but not in cockpit view. I have just noticed that too, but models I send you yesterday are not glowing. Compare small-glass-office-building and cube-apartment. The first glow and not the second in the external (chase) view. I think your textures are rgba while mine are only rgb. Going to verify that point. Wait... the tower-hexa only glow on certain faces and not on others. It's going strangers... Cheers, -Fred ___ 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] lighting
The list seems back... Wait... the tower-hexa only glow on certain faces and not on others. It's going strangers... Did you apply colour materials to some of the surfaces in Blender before you exported your model? No, I only applied texture with the UV editor Cheers, -Fred ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re: [Flightgear-devel] lighting
Curtis L. Olson writes: Actually this is the way it is supposed to work. We GL_MODULATE the texture on top of a colored polygon and the underlying color is modulated with the texture. This way we can draw our objects in all white and have them properly shaded, then modulate that with the actual textures so the textured surfaces also appear shaded. This is not unlike using multi-texturing to achieve lighting effects, except we are using opengl's shading model rather than providing our own light mask. Here are the opening lines of c172-dpm.ac: AC3Db MATERIAL NoName rgb 1 1 1 amb 1 1 1 emis 0 0 0 spec 0 0 0 shi 72 trans 0 The rgb values are the only ones that seem to affect the model's appearance. http://www.megginson.com/flightsim/inside-lighting.jpg http://www.megginson.com/flightsim/outside-lighting.jpg Notice that not only the plane starts to glow, but also the water tower and most of the buildings. For some reason, the rgb colour gets blended with the texture in external view (also in the two tower views) but not in cockpit view. You may be seeing two different surfaces (inside vs. out) which may account for some of this??? That does not seem likely. For pilot view, I'm not in a 3D cockpit, so we're looking at the same buildings from about the same angle each time. Something changes in the OpenGL lighting state between pilot view and chase view. 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] Lighting
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
RE: [Flightgear-devel] Lighting
Curtis L. Olson writes: 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. It might be informative to dump out or use gdb to look at the the actual OpenGL state values being used i.e the ambient, emissive, specular ect in the pre and post callbacks for the 3d model If one of these is being 'tromped on' then funny things are bound to happen ! Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] lighting
From: Frederic Bouvier [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Sunday, July 21, 2002 4:58 PM Subject: Re: [Flightgear-devel] lighting From: David Megginson [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Sunday, July 21, 2002 4:31 PM Subject: re: [Flightgear-devel] lighting Curtis L. Olson writes: However, the C172 still stays fully illuminated all the time, even in the dead of night. Futhermore it is not shaded at all during the day relative to sun position. So, I my theory at this point is that this model must have the emmissive property set so it is always fully self illuminating? The glow (as opposed to sun illumination) is the result of a different and strange effect -- it depends on the non-textured rgb value of the surface, even though the surface is textured. Set rgb in the *.ac file to 1 1 1 (the default for many AC3D models exported from Blender) and the model glows at night; set rgb to 0 0 0 and the model is always black, even in the day time; set it to .5 .5 .5 and the model is always grey, etc. But wait, there's more ... For reasons unknown, the effect is different depending on whether you're inside or outside the plane. This is best illustrated by two screenshots of the same buildings, one from inside view and one from outside view: http://www.megginson.com/flightsim/inside-lighting.jpg http://www.megginson.com/flightsim/outside-lighting.jpg Notice that not only the plane starts to glow, but also the water tower and most of the buildings. For some reason, the rgb colour gets blended with the texture in external view (also in the two tower views) but not in cockpit view. I have just noticed that too, but models I send you yesterday are not glowing. Compare small-glass-office-building and cube-apartment. The first glow and not the second in the external (chase) view. I think your textures are rgba while mine are only rgb. Going to verify that point. Wait... the tower-hexa only glow on certain faces and not on others. It's going strangers... Confirmed: when the tower-hexa-2.rgb is rgba, it glows, and when it is only rgb, it don't glow anymore. Only in external views. Perhaps because in the inside view, we are looking through the window ! Cheers, -Fred ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re: [Flightgear-devel] Lighting
Frederic BOUVIER writes: 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. OK, here's how plib sets up the states in src/ssg/ssgLoadAC.cxx. In AC3D format, textures and materials are separate: each object in a model can have only one texture, but it can use a different material for each surface. Each materials is defined with a line like this near the top of the file: MATERIAL NoName rgb 1 1 1 amb 1 1 1 emis 0 0 0 spec 0 0 0 shi 72 trans 0 The static get_state function actually builds the ssgState for each part of the model. It immediately sets the specular, emissive, and shininess properties directly from the parameters in the line (but they have no apparent effect in FlightGear). Next, it enables colour material with GL_AMBIENT_AND_DIFFUSE, together with lighting and smooth shading. If there is a texture defined, it then sets GL_TEXTURE_2D. Finally, it checks the alpha value (1.0 - transparency), and if it is less than 1 *or* the texture file has an alpha channel, it disables GL_ALPHA_TEST and enables GL_BLEND. The rgb value is copied to the vertex table for each of the vertices. So what's the interaction? Frederic identified the difference between a texture with and without an alpha channel. Why does enabling GL_BLEND seem to have this effect? In any case, I also have alpha channels in the textures for a couple of the buildings, and they don't start glowing unless the C172 is visible as well. Here's a different possibility -- the C172 has one texture with an alpha channel (which would cause GL_BLEND to be enabled), and one without (which would cause GL_BLEND to be disabled). Could that be the culprit? 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] Lighting
Norman Vine writes:
Curtis L. Olson writes:
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.
It might be informative to dump out or use gdb to look at the
the actual
OpenGL state values being used
i.e the ambient, emissive, specular ect
in the pre and post callbacks for the 3d model
If one of these is being 'tromped on' then funny things are
bound to happen !
Not really sure what all it means and / or how they get there but ...
There are some 'interesting values in the file this generates
void
FGAircraftModel::init ()
{
_aircraft = new FGModelPlacement;
string path = fgGetString(/sim/model/path, Models/Geometry/glider.ac);
try {
_aircraft-init(path);
} catch (const sg_exception ex) {
SG_LOG(SG_GENERAL, SG_ALERT, Failed to load aircraft from path);
SG_LOG(SG_GENERAL, SG_ALERT, (Falling back to glider.ac.));
_aircraft-init(Models/Geometry/glider.ac);
}
_scene-addKid(_aircraft-getSceneGraph());
_selector-addKid(_aircraft-getSceneGraph());
globals-get_scenery()-get_aircraft_branch()-addKid(_selector);
#if 0
FILE *fp;
fp = fopen(model.ascii, wt);
_aircraft-getSceneGraph()-print(fp);
fclose(fp);
#endif
}
e.g.
ssgVtxTable: Name=NoName
Userdata = 0x0
Num Parents=1
ssgSimpleState: Name=NoName
Userdata = 0x0
Translucent = True
ExternalProp = 0
Don't Care = CULLFACE
Enabled = TEXTURE2D COLOR_MATERIAL BLEND LIGHTING
TexHandle= 3
TexFilename =
'/home/nhv/FlightGear/Aircraft/c172/Models/c172-01.rgb'
Shade Model = 7425
Shininess= 2.00
AlphaClamp = -0.326197
ColourMatMode= GL_AMBIENT_AND_DIFFUSE
Ambient : (-0.455241,-0.326197,0.526312,-0.455241)
Diffuse : (-0.326197,-0.468420,-0.832415,-0.326197)
Specular : (0.00,0.00,0.00,1.00)
Emission : (0.00,0.00,0.00,1.00)
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Lighting
do you mean this kind of data :
ssgSimpleState: Name=NoName
Userdata =
Translucent = False
ExternalProp = 0
Don't Care = CULLFACE
Enabled = TEXTURE2D COLOR_MATERIAL LIGHTING
TexHandle= 2
TexFilename =
'c:/flightgear/cvs/fgfsbase/Aircraft/c172/Models/c172-02.rgb'
Shade Model = 7425
Shininess= 72.00
AlphaClamp = -431602080.00
ColourMatMode= GL_AMBIENT_AND_DIFFUSE
Ambient :
(-431602080.00,-431602080.00,-431602080.00,-431602080.00)
Diffuse :
(-431602080.00,-431602080.00,-431602080.00,-431602080.00)
Specular : (0.00,0.00,0.00,1.00)
Emission : (0.00,0.00,0.00,1.00)
Shouldn't the values of color component in the range [0..1] ?
-Fred
- Original Message -
From: Norman Vine [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Monday, July 22, 2002 8:21 PM
Subject: RE: [Flightgear-devel] Lighting
Norman Vine writes:
Curtis L. Olson writes:
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.
It might be informative to dump out or use gdb to look at the
the actual
OpenGL state values being used
i.e the ambient, emissive, specular ect
in the pre and post callbacks for the 3d model
If one of these is being 'tromped on' then funny things are
bound to happen !
Not really sure what all it means and / or how they get there but ...
There are some 'interesting values in the file this generates
void
FGAircraftModel::init ()
{
_aircraft = new FGModelPlacement;
string path = fgGetString(/sim/model/path,
Models/Geometry/glider.ac);
try {
_aircraft-init(path);
} catch (const sg_exception ex) {
SG_LOG(SG_GENERAL, SG_ALERT, Failed to load aircraft from path);
SG_LOG(SG_GENERAL, SG_ALERT, (Falling back to glider.ac.));
_aircraft-init(Models/Geometry/glider.ac);
}
_scene-addKid(_aircraft-getSceneGraph());
_selector-addKid(_aircraft-getSceneGraph());
globals-get_scenery()-get_aircraft_branch()-addKid(_selector);
#if 0
FILE *fp;
fp = fopen(model.ascii, wt);
_aircraft-getSceneGraph()-print(fp);
fclose(fp);
#endif
}
e.g.
ssgVtxTable: Name=NoName
Userdata = 0x0
Num Parents=1
ssgSimpleState: Name=NoName
Userdata = 0x0
Translucent = True
ExternalProp = 0
Don't Care = CULLFACE
Enabled = TEXTURE2D COLOR_MATERIAL BLEND LIGHTING
TexHandle= 3
TexFilename =
'/home/nhv/FlightGear/Aircraft/c172/Models/c172-01.rgb'
Shade Model = 7425
Shininess= 2.00
AlphaClamp = -0.326197
ColourMatMode= GL_AMBIENT_AND_DIFFUSE
Ambient : (-0.455241,-0.326197,0.526312,-0.455241)
Diffuse : (-0.326197,-0.468420,-0.832415,-0.326197)
Specular : (0.00,0.00,0.00,1.00)
Emission : (0.00,0.00,0.00,1.00)
___
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] lighting error
I'm running latest version from CVS, I saw this error in both CVS and last release version. Richard Kis -Original Message- From: Curtis L. Olson [mailto:[EMAIL PROTECTED]] Sent: Monday, December 10, 2001 1:12 AM To: [EMAIL PROTECTED] Subject: Re: [Flightgear-devel] lighting error What version of FlightGear are you running. I believe we have fixed at least on external view lighting bug matching your description for 0.7.9 Regards, Curt. X-VM-v5-Data: ([t nil nil nil nil nil nil nil nil] [1954 Sunday 9 December 2001 15:53:08 +0100 =?iso-8859-2?Q?Richard_Ki=B9?= [EMAIL PROTECTED] nil 55 [Flightgear-devel] lighting error nil nil nil 12 nil nil (number mark N=?iso-8859-2?Q?Ri Dec 9 55/1954 thread-indent \[Flightgear-devel] lighting error\\n) nil nil] nil) Received: from seneca.me.umn.edu (seneca.me.umn.edu [128.101.142.55]) by mail.me.umn.edu (8.11.3/8.11.3) with ESMTP id fB9F9Jh32474 for [EMAIL PROTECTED]; Sun, 9 Dec 2001 09:09:19 -0600 (CST) (envelope-from [EMAIL PROTECTED]) Received: from localhost ([127.0.0.1] helo=seneca.me.umn.edu) by seneca.me.umn.edu with esmtp (Exim 3.32 #1 (Debian)) id 16D5Zt-0007SN-00; Sun, 09 Dec 2001 09:09:17 -0600 Received: from ns.nextra.sk ([195.168.1.2] helo=ns.nx.nextra.sk) by seneca.me.umn.edu with smtp (Exim 3.32 #1 (Debian)) id 16D5Yo-0007Rl-00 for [EMAIL PROTECTED]; Sun, 09 Dec 2001 09:08:10 -0600 Received: (qmail 29249 invoked from network); 9 Dec 2001 14:54:33 - Received: from unknown (HELO rk) (195.168.161.20) by smtp2.nx.nextra.sk with SMTP; 9 Dec 2001 14:54:33 - Message-ID: 001701c180c1$59200a40$14a1a8c3@rk MIME-Version: 1.0 Content-Type: multipart/alternative; boundary==_NextPart_000_0014_01C180C9.98E04160 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Errors-To: [EMAIL PROTECTED] X-BeenThere: [EMAIL PROTECTED] X-Mailman-Version: 2.0.7 Precedence: bulk Reply-To: [EMAIL PROTECTED] X-Reply-To: =?iso-8859-2?Q?Richard_Ki=B9?= [EMAIL PROTECTED] List-Help: mailto:[EMAIL PROTECTED]?subject=help List-Post: mailto:[EMAIL PROTECTED] List-Subscribe: http://mail.flightgear.org/mailman/listinfo/flightgear-devel, mailto:[EMAIL PROTECTED]?subject=subscribe List-Id: FlightGear developers discussions flightgear-devel.flightgear.org List-Unsubscribe: http://mail.flightgear.org/mailman/listinfo/flightgear-devel, mailto:[EMAIL PROTECTED]?subject=unsubscribe List-Archive: http://mail.flightgear.org/pipermail/flightgear-devel/ From: =?iso-8859-2?Q?Richard_Ki=B9?= [EMAIL PROTECTED] Sender: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: [Flightgear-devel] lighting error Date: Sun, 9 Dec 2001 15:53:08 +0100 Hello, There is a lighting error in the external (look at) viewer. Everything = is OK when pilot offset heading/pitch is zero degrees. When I try set = some heading / pitch (for example heading 180 degrees - view from the = tail), the sky is darkest on the sun site and brightest on the opposite = site. It means that calculated light source position is not equal to sun = position in case of use a pilot offset angles !=3D 0... Richard Kis -- Curtis Olson Intelligent Vehicles Lab 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 ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
