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
[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
Re: [Flightgear-devel] not getting dynamic-objects
David Megginson wrote: Dave Perry writes: 1.When I run fgfs with the switch --prop:/sim/rendering/dynamic-objects=true per David Meggison's posting, I don't get any buildings or trees. I do get the photo real scenery. There will be no objects over the photoreal scenery because it doesn't use regular materials. The property /sim/rendering/dynamic-objects was renamed to /sim/rendering/random-objects in my last checkin, but that shouldn't matter, because true also became the default. When I had the same problem, the materials.xml file of the base package was out of date. Erik ___ 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] Enhancements to random objects
David Megginson wrote: Erik Hofman writes: Not to be picky here, but what's the deal with the lolly-pop thingy? I think it's better placed in the built-up area only if you'd ask me. It's a water tower -- in North America you typically get one in a small town (usually with the town's name in giant letters) and several in a larger city, and they are very visible from the air. Better versions are welcome. You know, I happened to drive in Germany and Belgium yesterday and saw the same objects (only they where in blank metal color) and just then I realized they were water towers! Over here in The Netherlands water towers aren't used for decades now, and instead were replaced by turbines to keep the pressure. I don't know why they choose to do so, bu I guess the brick built water towers we used to have became too expensive. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Random scenery objects now the default
Simon Fowler writes: Aside from that nitpick, dynamic objects really rock. Particularly the trees - they're far more realistic than I would have thought three polygons and a couple of textures could look ;-) Thanks. The trees are actually billboards -- each one is a single-sided quad (which plib splits into two triangles) and a 32x64 rgba texture, and plib keeps turning it to face the camera. I have to give full credit to plib for what appears to be extremely efficient billboarding code (in ssgCutout). David, if you only use the texture space within (0,0) (1,0) (0.5,1) and use a single triangle for the billboard, does it save a vertex ? That might let you use a lot more trees, even though it won't help other stuff such as buildings. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] CVS for FGFS down ?
I can ping the server, but an attempt to cvs update hangs indefinitely. ___ 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] new random ground cover objects
I think something that will need to be done is to make sure that forest textures blend in with the trees we are putting on them. That way the distinction where billboarded trees are shown, and where they aren't would be less visible. At the moment the dark conifers do not fit in with the forest texture we are using near KSFO. Anyone got any forrest textures we could use that could be better? Thanks, David ___ 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] Night lighting revisited
Norman Vine wrote: For example the a4 behaves differently then the c172 in this respect. Discover what is different and the lighting problem should be 'illuminated'. Curtis L. Olson wrote: People who understand the opengl lighting model better than I do might notice that I haven't mentioned the specular lighting compenent, which opengl supports as a way to emulate 'reflective' surfaces. If we are seeing some strange lighting effects perhaps the models have some kind of specular component that isn't getting turned off properly at night? Good catch, both of you. All of the materials in the a4-blue.ac file have a 50% specular coefficient, the c172 file has 0. While some specular probably isn't wrong for the A-4 (the Blue Angel's used glossy paint, of course), 50% is certainly way to high. It's also used for stuff like the cockpit panel, which is clearly not specular. I think perhaps the original author misunderstood what specular means -- even the lights (which are, by definition, 100% emissive) are listed at 100% specular. I changed all the specular components to zero, and things look much saner in my copy. 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: 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
[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] Lighting
[ 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. Cheers, -Fred ___ 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
[Flightgear-devel] preferences.xml
I would like to update the preferences.xml file to include comments telling folks like myself how to read/modify the file. I have commented my local version (mirrors CVS), but would like to insert it into CVS. To take a look at an earlier instrumentation, look at: http://homepage.mac.com/eq_fidget/FG_Dox/preferences_xml.html Would this be possible? Thanks, Jonathan Polley ___ 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
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
[Flightgear-devel] FlightGear make produces errors
Good day, hello, and help. When I 'make' FlightGear' I get an error: /usr/local/source/FlightGear-0.7.10/tests/test-env-map.cxx:237: undefined reference to `glutInitWindowSize' and several other glut commands. I figure that the make cannot find the headers or libraries of glut 3.7, but where is it looking? any help is appreciated and needed. __ Do You Yahoo!? Yahoo! Health - Feel better, live better http://health.yahoo.com ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: [Plib-devel] ANN: new version of the BGL loader in plib
Great! I tested the BGL loader only a bit. Most of the time it works *GREAT*. I will post some screenshots once I have time. I would be good to have some for the PLIB and FGFS websites. However, I also got some crashes. From avsim.com, get eddt2k_v2.zip. It says: FATAL: [ssgLoadBGL] Op-code out of range: 49932x. Do you know whether you can read gmax-generated BGL files? For the MDL loader, this is IMO the biggest limitation. BTW, I used the MDL loader intensively the last week or two and it works very similar to the old one, which is good news :). One of the major problems for the MDL loader was that it put every vertex into every leaf, so if you have 100 leaves with 10 vertices each (often they have even less...) you get 100 * 1000 vertices instead of 100 * 10 and often reading a 1MB MDL and writing as ssg or ase etc resulted in a 1GB file! I comitted a new function removeUnusedVertices and call it in the MDL loader, which cures the problem. I also put it into the BGL loader, although it only reduces the resulting file from 333kB to 296kB. Have a look. Any idea why it is only a small problem for BGLs? So when you load a BGL file you will see correctly piled gound layers (like asphalt on grass etc..) with no flickers anymore:) How do you do it, do you cut a hole into the lower layer? Bye bye, Wolfram. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Website updates
David Megginson writes: Erik Hofman writes: It might be usefull to rearrange the website, to let the Table of Contents show up first on the page. It would be a good idea to add the News and Project Overview sections to the table of contents then. I'd suggest that starting with screenshots is a better idea -- we don't want to waste a lot of screenspace or bandwidth, but we do want to give a first-time visitor an idea of why it's worth spending more than 3 seconds looking at FlightGear. The pictures show the current state of the project much more efficiently than text could. FWIW IMHO pictures do not belong on the main page at all !!! I am in complete agreement with Eric's suggestion that 'index.html' should be just our Logo, Table of Contents, Search Form, Counter and Credits. Norman ___ 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] 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] FlightGear can't find glut
r w writes: I try to 'make' FlightGear-0.7.10 and I get this error: /usr/local/source/FlightGear-0.7.10/tests/test-env-map.cxx:237: undefined reference to `glutInitWindowSize' -and several other similar errors- What file is FlightGear looking for and where is it looking at? Could you provide a bit more information such as what OS, platform, compiler, and a bit more of the output before and after this message to give a bit of context? 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
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] 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] 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
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] 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
[Flightgear-devel] Re: [Flightgear-users] Extracting mesh from BGL
Hi David, I just found this in the users archive: Satpac has a great freeware mesh for the whole of australia, that looks m= uch=20 better than ours. I was just wondering if there is any way to extract the= =20 mesh from the BGL files, and use it in FlightGear. Thanks, Check out the latest version of PLIB. I recently implemented the support for bgl elevation maps. By this you could convert it to all formats plib writers support. May be this helps already regards, Juergen ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: [Plib-devel] ANN: new version of the BGL loader in plib
Hi Wolfram, Am Montag, 22. Juli 2002 17:35 schrieb Wolfram Kuss: Great! I tested the BGL loader only a bit. Most of the time it works *GREAT*. I will post some screenshots once I have time. I would be good to have some for the PLIB and FGFS websites. That's nice to hear :) If Curtis likes to put them I'll do some. However, I also got some crashes. From avsim.com, get eddt2k_v2.zip. It says: FATAL: [ssgLoadBGL] Op-code out of range: 49932x. I use the same scenery for my researches. eddt2k uses a somehow compressed/encrypted file format which I can not decompress and at the moment even can not recognize. A work around for this problem is to decomplie and recomplie the bgl file. I use scdis (V2.2) and fsc of from http://www.freesc.org. For decomression you have to use the dos/windows version though. The decompression algorithm is only available to the windows version. (You can use wine if you like to stay in linux) This works with lots of bgl files, unfortunately not with all. That's because of scdis/fsc can not cope with all bgl statements. Do you know whether you can read gmax-generated BGL files? For the MDL loader, this is IMO the biggest limitation. BTW, I used the MDL loader intensively the last week or two and it works very similar to the old one, which is good news :). Sorry to say that the MDL loader is still the original version but this is one of my next tasks, promised. One of the major problems for the MDL loader was that it put every vertex into every leaf, so if you have 100 leaves with 10 vertices each (often they have even less...) you get 100 * 1000 vertices instead of 100 * 10 and often reading a 1MB MDL and writing as ssg or ase etc resulted in a 1GB file! I comitted a new function removeUnusedVertices and call it in the MDL loader, which cures the problem. I also put it into the BGL loader, although it only reduces the resulting file from 333kB to 296kB. Have a look. Any idea why it is only a small problem for BGLs? BGL files usually define a point array to which it refers later on for drawing polygons. For each polygon the MDL loader assigns the complete point array to the leaf. The BGL loader assigns only such vertices to the leaf that were used. But obviously there is still some room for improvement... So when you load a BGL file you will see correctly piled gound layers (like asphalt on grass etc..) with no flickers anymore:) How do you do it, do you cut a hole into the lower layer? Well, actually I don't cut the layers I sort them and write them from back to front while disabling the depth buffer for writing. Juergen Bye bye, Wolfram. ___ 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: 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] Website updates
Norman Vine wrote: FWIW IMHO pictures do not belong on the main page at all !!! Instead IMHO we should present a 'well organized' entry point that is viewable on one page so as to impress our visitors with our 'professionalism' FWIW - One of my favorite sites is http://www.google.com Which I believes demonstrates well that a 'minimalist' front page can be quite successful as it is the 'content served' and 'navigational ease' that is most important to a projects popularity and usefulness. Cheers Norman ___ 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
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
[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
Re: [Flightgear-devel] preferences.xml
On Monday 22 July 2002 12:13 am, Jonathan Polley wrote: I would like to update the preferences.xml file to include comments telling folks like myself how to read/modify the file. I have commented my local version (mirrors CVS), but would like to insert it into CVS. To take a look at an earlier instrumentation, look at: http://homepage.mac.com/eq_fidget/FG_Dox/preferences_xml.html Would this be possible? Thanks, Jonathan Polley I gotta get the instrument styles out of there first. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Website updates
* [EMAIL PROTECTED] (David Megginson) [2002.07.22 11:48]: Norman Vine writes: FWIW IMHO pictures do not belong on the main page at all !!! I'm not a graphics fan myself. I hate Flash pages (with an intensity that would scare many of you), I hate big logos, I hate complex layout, etc. etc. I like to make my own Web pages work well not only under lynx but on my cell phone text display. On the other hand, when I go looking at other open-source projects' home pages, what I almost always want to find is 1. a screenshot snip/ I agree with both of you. I don't like the current homepage. It's rather ugly with the 8 thumbnails spread out over the page. I do like having a 'state of our art' screenshot though. I'd suggest adding one or two thumbnails just before the ToC. If you want to see more, then go to the galleries where all other screenshots should go. A related nit I have with the current homepage snapshots is that they show things we don't currently have in FG, ie. rivers, roads, etc. I think we should stick with what is actually in CVS, not what David (or anyone) has cooked up on their home box. We should show people what they should expect to see when they download FG, not what they will see after an overnight scenery building process... -- Cameron Moore [ How do they get the deer to cross at that yellow road sign? ] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Website updates
Cameron Moore writes: * [EMAIL PROTECTED] (David Megginson) [2002.07.22 11:48]: Norman Vine writes: FWIW IMHO pictures do not belong on the main page at all !!! I'm not a graphics fan myself. I hate Flash pages (with an intensity that would scare many of you), I hate big logos, I hate complex layout, etc. etc. I like to make my own Web pages work well not only under lynx but on my cell phone text display. On the other hand, when I go looking at other open-source projects' home pages, what I almost always want to find is 1. a screenshot snip/ I agree with both of you. I don't like the current homepage. It's rather ugly with the 8 thumbnails spread out over the page. I do like having a 'state of our art' screenshot though. I'd suggest adding one or two thumbnails just before the ToC. If you want to see more, then go to the galleries where all other screenshots should go. A related nit I have with the current homepage snapshots is that they show things we don't currently have in FG, ie. rivers, roads, etc. I think we should stick with what is actually in CVS, not what David (or anyone) has cooked up on their home box. We should show people what they should expect to see when they download FG, not what they will see after an overnight scenery building process... If someone wants to work on improving the web pages, please feel free to contribute. My main constraint is that you stick to plain old html, keep it simple, clean, and fairly low bandwidth. And it would be nice if it continued to be relatively navigable by a text browser. 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
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] Website updates
What does it take to build the scenery? I have a dual Athlon 1.2 Ghz Machine with lots of disk space and a Netra T1 (Sun Box) available to build scenery. Is there a guide on how to do this somewhere?? Ryan If you are talking about buildings, see the response David Megginson made to my post: --- cut here --- WE NEED BUILDINGS! Jon S Berndt writes: Can you explain: 1) Which tools would one make these with? 2) What format should they be saved in? 3) What guidelines should be followed regarding complexity, textures, etc.? David replied: 1. Tools For Posix-based operating systems like Linux, the best two candidates are AC3D and Blender (my preference); under Windows, there are many more choices, still including Blender and (I think) AC3D. Blender is free-as-in-beer, and may be free-as-in-speech soon if they can raise $100K or so to buy out the NaN shareholders. 2. Format Plib supports a variety of 3D formats, but AC3D support seems the most solid (I export my Blender models in AC3D format). The VRML loader doesn't seem to handle textures, which is a big pain. 3. Guidelines For most buildings, I'm trying to keep the polygon count very low -- one quad for a tree, five for a basic building, 9 for a barn, and so on. I'm using mostly 64x64 SGI RGB-format textures, with 32x32 for small things like cows. Be creative -- most of the time the viewer will be pretty far away anyway. For scaling, FlightGear uses the convention that one unit = one meter. Try to keep the colours dull and the design generic (i.e. no adobe churches, cabanas, or maple sugar shacks). All the best, David --- cut here --- If you are talking about scenery other than buildings, I have even less to offer in the way of answers, but isn't that what TerraGear is for? Maybe you should visit that site? www.terragear.org? Jon smime.p7s Description: application/pkcs7-signature
Re: [Flightgear-devel] compiling error on MSVC
Thanks, Jonathan That may be a good idea (I had a project file already, but accidently deleted it during a massive cleanup). Will it build the latest cvs files (ie plib, simgear, flightgear)? Send to [EMAIL PROTECTED] Thanks, Christian At 08:47 PM 22/07/2002 -0500, you wrote: Christian, If you are interested, I can send you my MSVC project files. You will have to edit the paths to match your directory structure, but they are building just fine for me. Jonathan Polley On Monday, July 22, 2002, at 08:20 PM, Christian Stock wrote: It's been a while, but I got a bit side tracked with other things Thanks for the help on getting my FG compiled with VC6 on win xp, but I still haven't succeeded. I think I'm a bit stuck with the compiler options. Maybe someone can give me a quick rundown on the libraries and options I need to use? I have compiled plib and simgear, but flightgear won't find the plib and simgear functions in the linking process. I have included the paths to the libs in my options, so flightgear should find the libs. Should I use the /MTd option and why (I recently learned what MTd means, and it actually makes sense to my to use this, but how does this work, do I have to copy all the libs into one dir? It would just be nice to learn a bit about the options I have and how they work)? I think the standard options in the project files that come with cvs are different... Although I have a lot of coding experience, I'm a newbie when it comes to set complex projects up properly, so maybe someone on this list can give a quick rundown on whats important to know when setting things up in VC6? Cheers, Christian At 12:39 PM 10/06/2002 +0200, you wrote: Did you compile all libraries (and fgfs.exe) with the same run-time libs (LIBCMTD.LIB: /MTd compiler option)? regards georg -Original Message- From: Christian Stock [mailto:[EMAIL PROTECTED]] Sent: Montag, 10. Juni 2002 04:02 To: [EMAIL PROTECTED] Subject: Re: [Flightgear-devel] compiling error on MSVC Thanks, Fred. I have downloaded the CVS version now, and as you said this has been fixed. However, I get a lot of link errors when I compile flightgear (simgear cvs compiled fine). Do I have to be aware where to put the plib and simgear libs? Or are the incompatibilities between version, eg simgear cvs doesn't work with flightgear cvs? Cheers, Christian At 09:58 AM 9/06/2002 +0200, you wrote: This error has been fixed in CVS. MSVC6 is not able to choose between two member functions, one const and the other not const, so you have to cast the 4th argument : PropertyManager-Tie(atmosphere/p-turb-rad_sec, this,1, FGAtmosphere::GetTurbPQR); becomes: PropertyManager-Tie(atmosphere/p-turb-rad_sec, this,1, (double (FGAtmosphere::*PMF)(int) const)FGAtmosphere::GetTurbPQR); and so on for different classes in different files. Cheers, -Fred _ Frederic Bouvier Maintainer of the FlightGear Scenery Designer project http://fgsd.sourceforge.net - Original Message - From: Christian Stock [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Sunday, June 09, 2002 5:18 AM Subject: [Flightgear-devel] compiling error on MSVC I just downloaded flightgear 0.7.10 and I'm trying to get it to compile on Windoze MSVC 6.0. I got glut, plib, sim-gear compiled w/o any probs. For FG I get this error at quite a few places. error C2661: 'Tie' : no overloaded function takes 4 parameters I had a look at the Tie functions in FGPropertyManager, but couldn't work out what's wrong. Maybe I have to include a cast or so (doesn't really make sense because those functions use templates anyway)? Anyone come across this and knows how to fix it? Cheers, Christian ___ 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 ___ 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 ___ 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
