Re: [Flightgear-devel] DC-3 model 3D file
On Wed, 30 Jan 2002, Jeff wrote: David wrote: Looks good. Are you planning to texture it? Good question. I was going to at a later date. Below is kind of my personal plan. 1. Make the DC-3 with no textures (done) 2. Make some buildings for cities with textures. 3. Make another aircraft with no textures. 4. More buildings 5. Maybe another aircraft with no textures. 6. More buildings 7. Go back and texture the aircraft. I'm happy to help out with buildings (I have a registered version of AC3D lying around from another project). Is there a any documentation anywhere on how to include the buildings I design in the scenery? Presumably it needs including in the airport files, but I've yet to work out how. -- Jon Stockill Public Key: C6BD585D [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] JSBSim retractable gear problem
Hi, I've noticed both th c310 and c182 give a problem at load time. The problem is related to the retractable landing gear because it dumpt core right after: 9: GEAR_CONTACT 0 20: GEAR_CONTACT 1 21: GEAR_CONTACT 1 22: GEAR_CONTACT 0 23: GEAR_CONTACT 0 24: GEAR_CONTACT 0 25: GEAR_CONTACT 0 26: GEAR_CONTACT 1 27: GEAR_CONTACT 1 28: GEAR_CMemory fault(coredump) A test with the c310 changing RETRACT to FIXED did actually fix the problem. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Sun and Moon reflections on water
Shadows done the traditional way with shadow volumes are pretty expensive: Two passes through the scene graph for objects and 2 passes for the shadows. I'd guess that reflections are about the same expense. But, there are many short cuts, especially for relatively static scenes like the moon or sun reflecting on the water. Regards. Mark K Vallevand Fat, dumb and happy. 2 out of 3 ain't bad. -Original Message- From: David Findlay [mailto:[EMAIL PROTECTED]] Sent: Thursday, January 31, 2002 1:13 AM To: [EMAIL PROTECTED] Subject: [Flightgear-devel] Sun and Moon reflections on water Now that would be a cool feature. Can it be done though without killing frame rate too much? Thanks, David ___ 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] Sun and Moon reflections on water
Vallevand, Mark K wrote: Shadows done the traditional way with shadow volumes are pretty expensive: Two passes through the scene graph for objects and 2 passes for the shadows. I'd guess that reflections are about the same expense. But, there are many short cuts, especially for relatively static scenes like the moon or sun reflecting on the water. 1) If you want *only* moon an sun it's very cheap. 2) If you want moon and sun and bumpmapping (there are usually waves on the water) it's more expensive (dunno how much). 3) If you want the scenery it's exactly the doubled amount of work and thus should drecrease frame rates dramatically. 4) If you want the scenery and bump mapping it's even worse. If you want 2) and 4) it might help a hot to learn how to use the vertex and pixel shaders in the new hardware. CU, Christian -- The idea is to die young as late as possible.-- Ashley Montague Whoever that is/was; (c) by Douglas Adams would have been better... ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] 0.7.9 release schedule
Martin Spott writes: To explain what Erik's talking about: You don't get an appropriate video card that you can use in an SGI for just $50. 2x 4 MByte Texture RAM to upgrade an Octane SSI to MXI cost more than $1000 - and you can't use FlightGear's textured scenerey without TRAM Well in that case you are probably then better off just taking that $1000 and buying a modern PC which for most applications will probably beat the socks off the Octane anyways. In my last job we ran a simulator using an old SGI Onyx. We could buy 3 very high end PC's every year for what we paid in yearly hardware support contract costs. And each of those 3 PC's individually would beat the socks off the onyx. I like sgi, I wish they were doing better as a company. But, unfortunately I just don't see a lot of advantage in buying their hardware these days, and there are very few applications these days that run on sgi only. There are still a few uses where sgi makes the most sense, but these are getting fewer and fewer. 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] 0.7.9 release schedule
Curtis L. Olson wrote: Martin Spott writes: To explain what Erik's talking about: You don't get an appropriate video card that you can use in an SGI for just $50. 2x 4 MByte Texture RAM to upgrade an Octane SSI to MXI cost more than $1000 - and you can't use FlightGear's textured scenerey without TRAM Well in that case you are probably then better off just taking that $1000 and buying a modern PC which for most applications will probably beat the socks off the Octane anyways. In my last job we ran a simulator using an old SGI Onyx. We could buy 3 very high end PC's every year for what we paid in yearly hardware support contract costs. And each of those 3 PC's individually would beat the socks off the onyx. I like sgi, I wish they were doing better as a company. But, unfortunately I just don't see a lot of advantage in buying their hardware these days, and there are very few applications these days that run on sgi only. There are still a few uses where sgi makes the most sense, but these are getting fewer and fewer. So you're basically saying I am wasting my time ... I doubt that the 40 people downloading FlightGear 0.7.7 each month could be conviced to use crappy PC hardware just because it's cheap. I realy don't like that attitude and prefer to leave the hardware choice to everyone who wishes to chose. Ergo, we should stick with support for old hardware or remove the line multi platfrom and state the change on the website. Then at least *I* would know what to do. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] 0.7.9 release schedule
Erik Hofman wrote: Curtis L. Olson wrote: Martin Spott writes: To explain what Erik's talking about: You don't get an appropriate video card that you can use in an SGI for just $50. 2x 4 MByte Texture RAM to upgrade an Octane SSI to MXI cost more than $1000 - and you can't use FlightGear's textured scenerey without TRAM Well in that case you are probably then better off just taking that $1000 and buying a modern PC which for most applications will probably beat the socks off the Octane anyways. In my last job we ran a simulator using an old SGI Onyx. We could buy 3 very high end PC's every year for what we paid in yearly hardware support contract costs. And each of those 3 PC's individually would beat the socks off the onyx. I like sgi, I wish they were doing better as a company. But, unfortunately I just don't see a lot of advantage in buying their hardware these days, and there are very few applications these days that run on sgi only. There are still a few uses where sgi makes the most sense, but these are getting fewer and fewer. So you're basically saying I am wasting my time ... I doubt that the 40 people downloading FlightGear 0.7.7 each month could be conviced to use crappy PC hardware just because it's cheap. I realy don't like that attitude and prefer to leave the hardware choice to everyone who wishes to chose. Ergo, we should stick with support for old hardware or remove the line multi platfrom and state the change on the website. Then at least *I* would know what to do. Well, the modern SGIs shouldn't have trouble running a recent version of FGFS. So we run on a SGI. You don't expect a software rendering 386 to give decent frame rates, do you? But we could offer a minimum recomended SGI configuration. CU, Christian PS: Is there a way to install FGFS (+SimGear + PLIB + GLUT) on a Indy w/o root privileges? I'd like to try it at the university. -- The idea is to die young as late as possible.-- Ashley Montague Whoever that is/was; (c) by Douglas Adams would have been better... ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] 0.7.9 release schedule
You don't expect a software rendering 386 to give decent frame rates, do you? Haven't tried that yet, because just the FGFS base is 50MB ... and that PC only has a 100MB HD. My 486 doesn't do very well, due to software 3D. If I come across an ISA 3D card spare, I try it ... it might be usable! ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] 0.7.9 release schedule
To explain what Erik's talking about: You don't get an appropriate video card that you can use in an SGI for just $50. 2x 4 MByte Texture RAM to upgrade an Octane SSI to MXI cost more than $1000 - and you can't use FlightGear's textured scenerey without TRAM In my last job we ran a simulator using an old SGI Onyx. We could buy 3 very high end PC's every year for what we paid in yearly hardware support contract costs. And each of those 3 PC's individually would beat the socks off the onyx. So you're basically saying I am wasting my time ... I doubt that the 40 people downloading FlightGear 0.7.7 each month could be conviced to use crappy PC hardware just because it's cheap. I realy don't like that attitude and prefer to leave the hardware choice to everyone who wishes to chose. It's also worth bearing in mind that (a) FGFS is currently not taking advantage of some SGI hardware features (b) A big benefit of SGI support is the visual hardware that is plugged in I think we should continue to support the untextured scenery for FGFS, partly because when used for IFR, people will want every ounce of performance going into the panel. On machines with 810 style chipsets, having all that texture memory floating around really hurts performance to no benefit. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] 0.7.9 release schedule
Erik, I want to clarify that I wasn't trying to speak ill of sgi or those who use sgi computers. I was just responding to Martin Spott's suggestion that it would cost $1000 to turn an Octane SSI into something that could reasonably run FlightGear. And then pointing out that for that $1000 you could buy an entire PC which would run FlightGear splendidly. SGI has it's place in the world, they do some things very well, but also at a very high price. I hope FlightGear can continue to support their platform. Back a couple years ago I got a very early version of FlightGear running on SGI. My department had tons of sgi's all over the place so it seemed like a great idea since sgi *is* *the* 3d graphics company (or at least was back then.) I was shocked then to find out that there was only one sgi machine in the entire building (out of about 30) capable of running flightgear decently. This was a $250,000 Onyx which was not for playing games. The rest of the sgi's around here either had no graphics hardware acceleration at all (i.e. Indies) or had some minimal 3d acceleration but didn't support basic things like texturing. After that, I personally stopped investing time on the sgi port because as I unfortunately discovered, I didn't have convenient access to any sgi machines that could run it. These days you can get a Voodoo2 (with two texture engines) for $10 on ebay. I certainly hope sgi isn't *still* selling machines without hardware texturing support. Any, my real point here is that I personally do not care to work very hard to support a non-textured flightgear mode simply for the sake of old sgi hardware. However, if there are other reasons as well ... supporting notebook (few of which have 3d graphics), or to still support cards with very little texture ram ... then I have no problem with continuing on with our support of a non-textured world mode. However, with respect to the current bug in coloring, someone else is going to have to volunteer to look into the problem. Regards, Curt. Erik Hofman writes: Curtis L. Olson wrote: Martin Spott writes: To explain what Erik's talking about: You don't get an appropriate video card that you can use in an SGI for just $50. 2x 4 MByte Texture RAM to upgrade an Octane SSI to MXI cost more than $1000 - and you can't use FlightGear's textured scenerey without TRAM Well in that case you are probably then better off just taking that $1000 and buying a modern PC which for most applications will probably beat the socks off the Octane anyways. In my last job we ran a simulator using an old SGI Onyx. We could buy 3 very high end PC's every year for what we paid in yearly hardware support contract costs. And each of those 3 PC's individually would beat the socks off the onyx. I like sgi, I wish they were doing better as a company. But, unfortunately I just don't see a lot of advantage in buying their hardware these days, and there are very few applications these days that run on sgi only. There are still a few uses where sgi makes the most sense, but these are getting fewer and fewer. So you're basically saying I am wasting my time ... I doubt that the 40 people downloading FlightGear 0.7.7 each month could be conviced to use crappy PC hardware just because it's cheap. I realy don't like that attitude and prefer to leave the hardware choice to everyone who wishes to chose. Ergo, we should stick with support for old hardware or remove the line multi platfrom and state the change on the website. Then at least *I* would know what to do. Erik ___ 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] 0.7.9 release schedule
Any, my real point here is that I personally do not care to work very hard to support a non-textured flightgear mode simply for the sake of old sgi hardware. However, if there are other reasons as well ... supporting notebook (few of which have 3d graphics), or to still support cards with very little texture ram ... then I have no problem with continuing on with our support of a non-textured world mode. Here's another scenario in which a non-textured world is useful: We develop IRIX software on an (old) Indy R5K and an Indigo II to run on our Onyx RE2 because the Onyx is not always available for development. It's much more productive to have a non-textured mode available on the slower machines. I agree with Curt's comments concerning SGI vs. modern PC graphics hardware, but hope that the efforts of Erik and others to keep FGFS alive on IRIX will continue. Regards, Paul Paul R. Deppe Veridian Engineering (formerly Calspan) Flight Aerospace Research Group 150 North Airport Drive Buffalo, NY 14225 (716) 631-6898 (716) 631-6990 FAX [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] 0.7.9 release schedule
Curtis L. Olson wrote: Erik, I want to clarify that I wasn't trying to speak ill of sgi or those who use sgi computers. I was just responding to Martin Spott's suggestion that it would cost $1000 to turn an Octane SSI into something that could reasonably run FlightGear. And then pointing out that for that $1000 you could buy an entire PC which would run FlightGear splendidly. Hmm, maybe I didn't understand it quite well then. Anyway, I've discovered that allmost all of the ambient and diffuse colors in the materials.xml file hive the same value for r, g an b. I guess there has gone something wrong in the conversion of the file. Does anybody have the original still laying around? I have one from FLightGear-0.7.6 which is probably too old (but usable if there are no other options). Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] 0.7.9 release schedule
Erik Hofman writes: Anyway, I've discovered that allmost all of the ambient and diffuse colors in the materials.xml file hive the same value for r, g an b. I guess there has gone something wrong in the conversion of the file. Ahhh, that actually looks like the source of the problem r = g = b = value will be a shade of grey. Looks like something did get lost in the conversion. Does anybody have the original still laying around? I have one from FLightGear-0.7.6 which is probably too old (but usable if there are no other options). The 0.7.8 base package should be on ftp.flightgear.org and should contain a fairly recent materials file. Someone should actually go through all the entries and pick appropriate non-texture colors for each material. I thought it would be intresting to taket the average of all the pixels in the texture, but never got around to seeing how well that would work. But it's something you could then automate to handle future textures or texture updates pretty easily. 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] 0.7.9 release schedule
* [EMAIL PROTECTED] (Erik Hofman) [2002.01.31 14:14]: Curtis L. Olson wrote: Erik, I want to clarify that I wasn't trying to speak ill of sgi or those who use sgi computers. I was just responding to Martin Spott's suggestion that it would cost $1000 to turn an Octane SSI into something that could reasonably run FlightGear. And then pointing out that for that $1000 you could buy an entire PC which would run FlightGear splendidly. Hmm, maybe I didn't understand it quite well then. Anyway, I've discovered that allmost all of the ambient and diffuse colors in the materials.xml file hive the same value for r, g an b. I guess there has gone something wrong in the conversion of the file. Does anybody have the original still laying around? I have one from FLightGear-0.7.6 which is probably too old (but usable if there are no other options). Erik Yes, this is definately wrong. I have a copy, but I'm not sure how old it is (prolly a couple months). I don't think it has all of the changes up to when it was removed. Anybody know how to retrieve it from the CVS Attic? Or...what are to chances of getting ViewCVS on the fgfs-base server? ;-) -- Cameron Moore [ There's no place like $HOME ] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] 0.7.9 release schedule
Erik Hofman writes: I guess there has gone something wrong in the conversion of the file. Does anybody have the original still laying around? The colours in the original were mostly not filled in either, unfortunately. When you tweak the colours around, do you get anything useful? All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] 0.7.9 release schedule
* [EMAIL PROTECTED] (David Megginson) [2002.01.31 15:32]: Cameron Moore writes: Yes, this is definately wrong. I have a copy, but I'm not sure how old it is (prolly a couple months). I don't think it has all of the changes up to when it was removed. Anybody know how to retrieve it from the CVS Attic? Or...what are to chances of getting ViewCVS on the fgfs-base server? ;-) To get the version from, say, November 30 2001, try something like cvs update -D20011130 materials Okay, I was trying to use '-r 1.11' and it wasn't working. This should get you the last version prior to the XML switch-over: cvs update -D20011227 materials That said, it's my mess, so I'll clean it up. I don't think I have the perl script I used for that conversion any more though. Well, if you find it, it looks like you were dropping the BG values and just converting everything to RRR instead of RGB. -- Cameron Moore / If a person with multiple personalities threatens \ \ suicide, is that considered a hostage situation? / ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: 0.7.9 release schedule
* Cameron Moore -- Thursday 31 January 2002 22:09: Yes, this is definately wrong. I have a copy, but I'm not sure how old it is (prolly a couple months). I don't think it has all of the changes up to when it was removed. Anybody know how to retrieve it from the CVS Attic? Or...what are to chances of getting ViewCVS on the fgfs-base server? ;-) You should still be able to get the log entries with: cvs log materials.xml after which you can look up the revision number that you are interested in, e.g. cvs up -p -r1.5 materials.xml materials.xml.1.5 m. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] 0.7.9 release schedule
Well, the modern SGIs shouldn't have trouble running a recent version of FGFS. So we run on a SGI. Yep, as long as you have lots of CPU cycles. I believe an R10k at 300 MHz is minimum, also a MaxImpact/MXI graphics subsystem with maximum TRAM should be recommended. PS: Is there a way to install FGFS (+SimGear + PLIB + GLUT) on a Indy w/o root privileges? I'd like to try it at the university. Yes, you could place the binary in your home directory and adjust 'fg-root'. That's it. But be warned: My first SGI was a 175 MHz Indigo2 MaxImpact (somewhat Indy's successor) wit 2x 1 MByte TRAM. CPU was too slow and TRAM was too little. Now I have an 195 MHz Octane SSI. CPU is still somewhat too slow and SSI has _no_ TRAM. I doubt you'll be lucky on an Indy, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: 0.7.9 release schedule
* [EMAIL PROTECTED] (Melchior FRANZ) [2002.01.31 16:24]: * Cameron Moore -- Thursday 31 January 2002 22:09: Yes, this is definately wrong. I have a copy, but I'm not sure how old it is (prolly a couple months). I don't think it has all of the changes up to when it was removed. Anybody know how to retrieve it from the CVS Attic? Or...what are to chances of getting ViewCVS on the fgfs-base server? ;-) You should still be able to get the log entries with: cvs log materials.xml cvs log materials after which you can look up the revision number that you are interested in, e.g. cvs up -p -r1.5 materials.xml materials.xml.1.5 m. That doesn't work for materials since it was deleted from the repository. The XML file is not what we're after. Thanks -- Cameron Moore [ Where do forest rangers go to get away from it all? ] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] 0.7.9 release schedule
Martin Spott wrote: From: Alex Perry [EMAIL PROTECTED] It's also worth bearing in mind that (a) FGFS is currently not taking advantage of some SGI hardware features Do you believe it might make sense to take these features into account for FlightGear ? I had the impression that by using several 'abstraction layers' like 'glut' and 'plib' there's not much room to take advantage of OpenGL specifics. That's no problem. AFAIK is our only need for GLUT to tell us the dimension of the OpenGL window that the window manager created for us. PLIB gives us a scenegraph. And PLIB should work *very* well on SGI as the author has a very strong SGI background (and SSG was strongly inspired by performer). PLIB also let's us call our own OpenGL calls (that's e.g. the way we draw our sky) and only need a few informations from us which aren't limiting us in any way. Oh, and we can allways inherit classes from PLIB to have out very custom OpenGL calls. So no trouble here. But *I* think it's not worth the hazle. CU, Christian -- The idea is to die young as late as possible.-- Ashley Montague Whoever that is/was; (c) by Douglas Adams would have been better... ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] DC-3 model 3D file
Jon wrote: I'm happy to help out with buildings (I have a registered version of AC3D lying around from another project). Is there a any documentation anywhere on how to include the buildings I design in the scenery? Presumably it needs including in the airport files, but I've yet to work out how. Well, with my version 0.7.8 of FlightGear, the instruction in the FlightGear_FAQ.html has a few bugs. So I just add my models to the file Scenery/w08n40/w076n45. Thats the example in the FAQ ( I hope). Then I edit the file 1712601.stg as below. OBJECT_BASE 1712601.btg OBJECT CYRO.btg OBJECT_STATIC rr-hanger-od_v2.ac -75.73100 45.40 57 0 OBJECT_STATIC rr-hanger-od_v1.ac -75.73100 45.4005 57 0 OBJECT_STATIC wat-tower-bl_v1.ac -75.7295 45.40 57 0 OBJECT_STATIC wat-tower-wh_v1.ac -75.729 45.3999 57 0 OBJECT_STATIC wat-tower-rd_v1.ac -75.7301 45.39 57 0 OBJECT_STATIC con-tower_v1.ac -75.7302 45.40 55 0 OBJECT_STATIC rr-hanger_v1.ac -75.7290 45.4001 57 0 OBJECT_STATIC rr-hanger_v2.ac -75.7270 45.3900 70 0 OBJECT_STATIC hanger_v2.ac -75.7302 45.4003 55 0 OBJECT_STATIC rad-tower.ac -75.73203 45.4003 54 0 OBJECT_STATIC hanger2.ac -75.73403 45.4005 54 0 OBJECT_STATIC rad-tower_v2.ac -75.73210 45.4004 54 0 OBJECT_STATIC rad-tower_v3.ac -75.73220 45.4005 54 0 OBJECT_STATIC hanger3.ac -75.73403 45.4015 54 0 I can't place the models where I would like. I can only use the above example to test my models. If I had to figure out how to place models say by ERI, I wouldn't get the time to work on the models. I don't think the instruction are 100% for version 0.7.8. Later Jeff ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] 0.7.9 release schedule
David Megginson writes: Erik Hofman writes: I guess there has gone something wrong in the conversion of the file. Does anybody have the original still laying around? The colours in the original were mostly not filled in either, unfortunately. When you tweak the colours around, do you get anything useful? Some of them had been carefully tweaked at one point, but new additions probably weren't tweaked. Clearly the actual/original rgb values did not get brought over in the conversion to xml. 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] 0.7.9 release schedule
Martin Spott writes: From: Alex Perry [EMAIL PROTECTED] It's also worth bearing in mind that (a) FGFS is currently not taking advantage of some SGI hardware features Alex, what sgi hardware features are you referring to, and are these available on any of the machines our developers have access to? Do you believe it might make sense to take these features into account for FlightGear ? I had the impression that by using several 'abstraction layers' like 'glut' and 'plib' there's not much room to take advantage of OpenGL specifics. Anyways, as my insight in FlightGear's 'mechanics' is limited I easily might be wrong. For the most part glut and plib do not hinder you from using raw opengl commands. They don't necessarily provide an abstraction for the fancy new card features and opengl extensions coming out, but they don't get in the way of you writing raw opengl calls yourself. Anyway, even if someone optimizes FlightGear's use of unusual graphics hardware there will ever be the lack of CPU cycles, as even modern SGI Workstations run at moderate CPU speed. This gets pretty obvious when comparing frame rates of FlightGear running LaRCsim or JSBSim, I'm still not sure what special graphics features sgi provides (that something like a mid-hi level geforce card doesn't) that we'd be interested in. 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] 0.7.9 release schedule
On Thursday 31 January 2002 04:09 pm, you wrote: * [EMAIL PROTECTED] (Erik Hofman) [2002.01.31 14:14]: Curtis L. Olson wrote: Erik, I want to clarify that I wasn't trying to speak ill of sgi or those who use sgi computers. I was just responding to Martin Spott's suggestion that it would cost $1000 to turn an Octane SSI into something that could reasonably run FlightGear. And then pointing out that for that $1000 you could buy an entire PC which would run FlightGear splendidly. Hmm, maybe I didn't understand it quite well then. Anyway, I've discovered that allmost all of the ambient and diffuse colors in the materials.xml file hive the same value for r, g an b. I guess there has gone something wrong in the conversion of the file. Does anybody have the original still laying around? I have one from FLightGear-0.7.6 which is probably too old (but usable if there are no other options). Erik Yes, this is definately wrong. I have a copy, but I'm not sure how old it is (prolly a couple months). I don't think it has all of the changes up to when it was removed. Anybody know how to retrieve it from the CVS Attic? Or...what are to chances of getting ViewCVS on the fgfs-base server? ;-) I'll look into it next week. I'm scheduling an overhaul of that machine soon. Probably after the next release. John ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Post 0.7.9 priorities
Aside from stabilizing our current flight models, I think that the absolute top priority for 0.8 should be at least a minimal level of runway lighting. While the general scenery lighting makes night flying nice (and makes roads look great), landing at night is too hard right now. All of us (including me) have our own pet projects, but perhaps we can pull together and get this one problem out of the way once we have 0.7.9 out. Comments? Objections? All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Urgent: Network and external flight model
David, At work, I run a proprietary FDM on a Sun Workstation and feed the data to FlightGear. I use the '--fdm=external' and '--native_fdm=...' options (--native_fmd= uses the same parameters as --native). I did make some changes to Network/native_fdm.cxx to properly manage the byte-order issues, but it works like a champ. IMHO, --native_fdm= has a cleaner interface than does --native=. To see the data structure that the FDM needs to generate, look in Network/raw_fdm.hxx. Jonathan Polley p.s. I have submitted my edits. On Thursday, January 31, 2002, at 06:37 PM, David Findlay wrote: Just checking a couple of details - you can run an external flight model on a machine other than the one running FGFS right? Thanks, David ___ 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] Post 0.7.9 priorities
On Fri, 1 Feb 2002 11:44, you wrote: Aside from stabilizing our current flight models, I think that the absolute top priority for 0.8 should be at least a minimal level of runway lighting. While the general scenery lighting makes night flying nice (and makes roads look great), landing at night is too hard right now. All of us (including me) have our own pet projects, but perhaps we can pull together and get this one problem out of the way once we have 0.7.9 out. Comments? Objections? I think the other thing needed is stabilising all current features. There's lots of little annoying bugs that need to be reported and fixed. 0.7.9 should be released soon, then everyone could bug hunt that version. Then release 0.8pre1 and have everyone look for bugs in it. That way we can have a nice stable version 0.8 then go and completely stuff it with new features after that. David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Post 0.7.9 priorities
On Thursday 31 January 2002 09:02 pm, you wrote: On Fri, 1 Feb 2002 11:44, you wrote: Aside from stabilizing our current flight models, I think that the absolute top priority for 0.8 should be at least a minimal level of runway lighting. While the general scenery lighting makes night flying nice (and makes roads look great), landing at night is too hard right now. All of us (including me) have our own pet projects, but perhaps we can pull together and get this one problem out of the way once we have 0.7.9 out. Comments? Objections? I think the other thing needed is stabilising all current features. There's lots of little annoying bugs that need to be reported and fixed. 0.7.9 should be released soon, then everyone could bug hunt that version. Then release 0.8pre1 and have everyone look for bugs in it. That way we can have a nice stable version 0.8 then go and completely stuff it with new features after that. David Okay heres a bug. When flying towards the sun/moon, the body in question will jump down ~45 degrees for a frame or two. When ever this happens the time jumps ahead on the clock. Uh... ok... so the time stutters. ___ 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] LWCE notes
I'm getting a lot of positive responses in the booth to the current feature set. The pilots in the bunch are well pleased with JSBsim. That's a relief [ said Jon, not quite able to hide the slight surprise in his voice]. Any particular comments made? I would suspect perhaps a comment on gyroscopic effects and P-Factor? Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] New Screenshots?
On Fri, 1 Feb 2002 12:30, you wrote: On Thursday 31 January 2002 08:56 pm, you wrote: Anyone got any new screenshots of coming features or anything special that I could show during my talk next week? Thanks, David I can post the foils from my presentation, but I lifted a lot of those from the FGFS screenshots page. The photorealistic scenery shots with the DC3 are a crowd pleaser. Also, the fisheye lens shot of the 3 screen setup goes over big. Theres a not bad screendump with the C310 flying past KSFO on my website Okay I'll have a look at that one. Anyone got a recent shot of the NetworkOLK code in use? Thanks, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Post 0.7.9 priorities
David Findlay writes: I think the other thing needed is stabilising all current features. There's lots of little annoying bugs that need to be reported and fixed. 0.7.9 should be released soon, then everyone could bug hunt that version. Then release 0.8pre1 and have everyone look for bugs in it. That way we can have a nice stable version 0.8 then go and completely stuff it with new features after that. Yes, I agree that bug-swatting is also important. We should aim to have 0.8 build clean with -Wall (under G++), and run clean with all FPEs enabled. The latter will involve some coordination with the PLIB folks (I don't think they test with FPE's enabled). All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Post 0.7.9 priorities
John Check writes: Okay heres a bug. When flying towards the sun/moon, the body in question will jump down ~45 degrees for a frame or two. When ever this happens the time jumps ahead on the clock. Uh... ok... so the time stutters. Yes, I see the time stutter as well -- it seems to happen on tile loading. We should go back to using the SF bug tracker for these. All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Post 0.7.9 priorities
John Wojnaroski writes: Question? You mention roads. Are there features (objects) not enabled by the CVS version? TerraGear can build scenery with roads, rivers, railroads, small towns, etc. from the vmap0 CDs, but Curt hasn't included that in the official scenery distro yet. All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Post 0.7.9 priorities
On Thu, 2002-01-31 at 18:51, David Megginson wrote: David Findlay writes: I think the other thing needed is stabilising all current features. There's lots of little annoying bugs that need to be reported and fixed. 0.7.9 should be released soon, then everyone could bug hunt that version. Then release 0.8pre1 and have everyone look for bugs in it. That way we can have a nice stable version 0.8 then go and completely stuff it with new features after that. Yes, I agree that bug-swatting is also important. We should aim to have 0.8 build clean with -Wall (under G++), and run clean with all FPEs enabled. The latter will involve some coordination with the PLIB folks (I don't think they test with FPE's enabled). This would require getting them to actually work which, AFAICT, they don't with the current FG code. I'd love to hear different, however. All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel -- Tony Peden [EMAIL PROTECTED] We all know Linux is great ... it does infinite loops in 5 seconds. -- attributed to Linus Torvalds ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Post 0.7.9 priorities
On Fri, 1 Feb 2002 12:51, you wrote: David Findlay writes: I think the other thing needed is stabilising all current features. There's lots of little annoying bugs that need to be reported and fixed. 0.7.9 should be released soon, then everyone could bug hunt that version. Then release 0.8pre1 and have everyone look for bugs in it. That way we can have a nice stable version 0.8 then go and completely stuff it with new features after that. Yes, I agree that bug-swatting is also important. We should aim to have 0.8 build clean with -Wall (under G++), and run clean with all FPEs enabled. The latter will involve some coordination with the PLIB folks (I don't think they test with FPE's enabled). What is -Wall and what are FPEs? Thanks, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Post 0.7.9 priorities
On Thu, 2002-01-31 at 19:26, David Findlay wrote: On Fri, 1 Feb 2002 12:51, you wrote: David Findlay writes: I think the other thing needed is stabilising all current features. There's lots of little annoying bugs that need to be reported and fixed. 0.7.9 should be released soon, then everyone could bug hunt that version. Then release 0.8pre1 and have everyone look for bugs in it. That way we can have a nice stable version 0.8 then go and completely stuff it with new features after that. Yes, I agree that bug-swatting is also important. We should aim to have 0.8 build clean with -Wall (under G++), and run clean with all FPEs enabled. The latter will involve some coordination with the PLIB folks (I don't think they test with FPE's enabled). What is -Wall and what are FPEs? Thanks, enable all compiler warnings floating point exceptions -- if set up correctly, the CPU will flag a bad math op such as divide by zero or overflow and send your program a signal rather than simply returning NaN or inf. David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel -- Tony Peden [EMAIL PROTECTED] We all know Linux is great ... it does infinite loops in 5 seconds. -- attributed to Linus Torvalds ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] core dump with latest cvs
This is weird. Your back trace isn't showing where exactly in the options.cxx:fgSetDefaults() routine you are crashing. But, the value= shows -110.6642444 so this is clearly dying on the first fgSetDouble(): fgSetDouble(/position/longitude-deg, -110.6642444); So somehow your property manager isn't getting initialized correctly. This should happen when the FGGlobals class is created which has definitely already happened. What platform/compiler/etc. did you say you were using? Curt. Alex Romosan writes: i've just updated everything and now when i try to rung fgfs i get: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 1024 (LWP 11729)] 0x40104e48 in SGPropertyNode::getNode (this=0x0, relative_path=@0xb2b4, create=true) at props.cxx:1327 1327 if (_path_cache == 0) (gdb) where #0 0x40104e48 in SGPropertyNode::getNode (this=0x0, relative_path=@0xb2b4, create=true) at props.cxx:1327 #1 0x401059ac in SGPropertyNode::setDoubleValue (this=0x0, relative_path=@0xb2b4, value=-110.6642444) at props.cxx:1509 #2 0x08089198 in fgSetDefaults () at fg_props.hxx:328 #3 0x0806b809 in fgInitConfig (argc=2, argv=0xb6f4) at fg_init.cxx:219 #4 0x0805d9cf in mainLoop (argc=2, argv=0xb6f4) at main.cxx:1487 #5 0x08061d8a in main (argc=2, argv=0xb6f4) at main.cxx:1816 #6 0x4051a6cf in __libc_start_main () from /lib/libc.so.6 i am not sure why i get multiple threads since flightgear was configured without threads. --alex-- -- | I believe the moment is at hand when, by a paranoiac and active | | advance of the mind, it will be possible (simultaneously with | | automatism and other passive states) to systematize confusion | | and thus to help to discredit completely the world of reality. | ___ 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] Post 0.7.9 priorities
* [EMAIL PROTECTED] (David Megginson) [2002.01.31 20:56]: David Findlay writes: I think the other thing needed is stabilising all current features. There's lots of little annoying bugs that need to be reported and fixed. 0.7.9 should be released soon, then everyone could bug hunt that version. Then release 0.8pre1 and have everyone look for bugs in it. That way we can have a nice stable version 0.8 then go and completely stuff it with new features after that. Yes, I agree that bug-swatting is also important. We should aim to have 0.8 build clean with -Wall (under G++), and run clean with all FPEs enabled. The latter will involve some coordination with the PLIB folks (I don't think they test with FPE's enabled). I agree with you David M. on the narrow scope for post 0.7.9. We've accumilated a lot of features over the past year, and I think it would be wise to level off and clean up a lot of the known issues with our current codebase. I've sort of delegated myself to simply fixing warnings and tracking down bugs because it looks like I'll never have time to really learn to be a hardcore C++ programmer. :-) I do my best to keep everyone's code warning free. The major issues *I* have with FG right now are: - no runway lighting - no rivers, roads or railways (I haven't figure our IFR yet ;-) - not FPE-safe - threads are completely unsafe - the telnet and httpd property browsers don't understand indexed objects If we could tackle those problems, I think 8.0 would be a pretty impressive accomplishment. -- Cameron Moore [ Anything that's worth having is worth working for. ] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] 0.7.9 release schedule
Alex, what sgi hardware features are you referring to, and are these available on any of the machines our developers have access to? I'm still not sure what special graphics features sgi provides (that something like a mid-hi level geforce card doesn't) that we'd be interested in. I'm thinking of the video that is genlock capable, their graphics cards that can do true 3D textures, and the like. Much of this was add-ons on the earlier machines. My point of view is that those machines are physically installed in existing Sim settings, so if we want to be able to make inroads into those systems (and get to play with them) then we also have to be able to run (as best we can) on the unfeatured machines beforehand, to establish feasibility and get that access. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] 0.7.9 release schedule
Someone should actually go through all the entries and pick appropriate non-texture colors for each material. I thought it would be intresting to taket the average of all the pixels in the texture, but never got around to seeing how well that would work. But it's something you could then automate to handle future textures or texture updates pretty easily. A quick way to see how well it works is to have a script iterate through all the texture files, and have a program compute the average RGB value of all the pixels then replace all the pixels with that average and save. Then run FGFS normally and see what the scenery looks like ... ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Post 0.7.9 priorities (lights)
- Original Message -
From: David Megginson [EMAIL PROTECTED]
To: FlightGear Development [EMAIL PROTECTED]
Sent: Friday, February 01, 2002 4:44 AM
Subject: [Flightgear-devel] Post 0.7.9 priorities
Aside from stabilizing our current flight models, I think that the
absolute top priority for 0.8 should be at least a minimal level of
runway lighting. While the general scenery lighting makes night
flying nice (and makes roads look great), landing at night is too hard
right now. All of us (including me) have our own pet projects, but
perhaps we can pull together and get this one problem out of the way
once we have 0.7.9 out.
Comments? Objections?
Okey guys, I'm trying to implement runway lights but I have some
mathematical trouble:
I know 4 corners of runway in local tile coordinates O1 O2 O3 O4 {x,y,z}
And I have runway sheme of lights for example let O1 will have {100,100,100}
in FG coordinates and {0,0,0} in local lights coordinate system. All I need
to have formulas to convert this local lights coordinates to tile fg
coordinates. I know that I can construct plane by 3 points using plib sg
routine but wthat formulas?
O2O3
y
|
0--00
||
||
||
0--00--x
O1O4
so in runway coordinate system we have 6 points
{0,0,0}{100,0,0}{200,0,0},{0,50,0},{100,50,0},{200,50,0} and have simple
routine to convert it to tile coordinate system
I try many formulas but no success :((
So if some on do it we HAVE runway lights
because you simply construct it using tileentry.cxx routines
All the best,
David
--
David Megginson
[EMAIL PROTECTED]
___
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] Urgent: Network and external flight model
Guys I propose to use multicast for multiply windows visualisation Now we can only use tcp and udp but it now very usefull to have same data on multiply image generators so I propose to include in simgear multicast networking for example for fdm server we can use this option --native=socket,out,30,224.0.0.250,8139,multicast and for image generator --view-offset=LEFT --fdm=external --native=socket,in,30,224.0.0.250,8139,mul ticast --view-offset=CENTER --fdm=external --native=socket,in,30,224.0.0.250,8139,m ulticast --view-offset=RIGHT --fdm=external --native=socket,in,30,224.0.0.250,8139,mu lticast one minus in multicast data can flow in ONE direction If no objections I try to implement multicast ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
