Re: [Flightgear-devel] 0.7.9 release schedule
Martin Spott wrote: 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, That has been solved in the latest version. A moderate R5000/200 Mhz should work for FlightGear (given a good enough OpenGL hardware). Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] 0.7.9 release schedule
Christian Mayer wrote: 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. For source is easy, just place it in you home directory. For tardist packages: inst -r ~ this will change the root of the distribution to your home directory. Erik ___ 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: 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. One thing I know of is default support for stereo glasses. The rest is almost completely implemented in the new (PC) video hardware. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] 0.7.9 release schedule
Alex Perry wrote: 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 ... This aproach gives us a bonus level of detail: Create a treshold altitude at which all textures are removed (like F9 was pressed) to gain some extra speed (fps). Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] 0.7.9 release schedule
Alex Perry wrote: 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 Although i agree with you here, someone has to make these 3D textures. I have created some 2D textures and that was already quite difficult. While I deffinately like to have some more SGI(Irix) developers over here, if there are no 3D textures available for me to use it's likely i don't spent time in useing them :-) 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. That's the exact reason I keep pushing to get FlightGear working on Irix. I don't have a high-end machine but what works for me works also on a mult-head onyx-3000 with 1024 processors ;-) 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: This aproach gives us a bonus level of detail: Create a treshold altitude at which all textures are removed (like F9 was pressed) to gain some extra speed (fps). On some hardware :-) the video card can do all the texture calculations in parallel with everything else, so there is very little performance difference with textures off vs on. 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
Curtis L. Olson writes: On some hardware :-) the video card can do all the texture calculations in parallel with everything else, so there is very little performance difference with textures off vs on. Perhaps more usefully, we could replace entire tiles with appropriately-coloured rectangles at a certain distance. 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
David Megginson wrote: Curtis L. Olson writes: On some hardware :-) the video card can do all the texture calculations in parallel with everything else, so there is very little performance difference with textures off vs on. Perhaps more usefully, we could replace entire tiles with appropriately-coloured rectangles at a certain distance. That might even be better since you don't see that much difference anymore. But I was (and still am) under the impression that a large number of polygons (with different textures) would slow down the perfomance anyhow. 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: Curtis L. Olson wrote: Erik Hofman writes: This aproach gives us a bonus level of detail: Create a treshold altitude at which all textures are removed (like F9 was pressed) to gain some extra speed (fps). On some hardware :-) the video card can do all the texture You don't get me, I can have up to 1024 Mb texture memory :-) Ok, yes, that does make me just a tiny bit jealous. :-) 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
David Megginson writes: Curtis L. Olson writes: Getting the tile edges to match without gaps is always the challenge there. At a sufficient distance, the problem might not be noticable. What you really are talking about is an LOD scheme. From my experience, the gaps end up being very noticable and annoying, even at a far distance. You really need to have some scheme to hide the gaps ... I've lost Steve Baker's definitive work on the subject but there are things like: Make multiple versions of each tile designed to match with any possible different LOD of each neighboring tile. This leads to quite a prohibitively large amount of permutations, and also if you are matching a low lod tile against a high lod tile you can get an annoying starburst pattern in the low lod tile because a couple internal verticies have to match up with many verticies on the border. YRather than coming up with multiple versions of tiles to match all possible neighboring LOD's you could come up with transition regions and just create the necessary variety of transition sections. That makes the space requirements a little more managealbe. ou can come up with some sort of 'skirt' scheme and put skirts around your tile ... but this increases your polygon count and cuts into your fill rate budget. But on modern hardware with good polygon and fillrate throughput might not be a bad thing to try. However, in mountainous regions, ignoring edges and depending on skirts to hide gaps between different LOD's on neighboring tiles ... you have to hide some pretty big gaps so that might start to be noticable. Recently there has been a lot of work on continuous level of detail schemes. The stuff I've seen however has been great for demos and certain games, but there are serious issues in using this sort of scheme for a flight simulator that needs accurate terrain mapping. We need to cut holes for airports. We need lots of objects/buildings on top of the scenery. We need to be able to fly seamlessly across the entire world and be able to store the data for the entire world on a single computer. I'm just not convinced that a CLOD scheme is really best suited for our needs. (Something could be made to work of course, but I never jumped on the CLOD bandwagon myself.) There are a lot of approaches out there and they all have their strengths and weaknesses. Beyond that, if you are changing LOD of a tile, you have to consider what to do with all the objects on the surface of that tile. Do you let objects float or get buried, or do you let them float up and down as the underlying terrain changes ... none of these are ideal options. If you are doing some sort of combat, what happens if your opponent flies behind a hill in the distance, but your renderer has removed or simplified the hill in the distance because of the LOD scheme. Suddenly your opponent is wrongly visible. He thinks he's hiding, but you can falsely see him. Now what. You are able to shoot him down because the LOD scheme has given you an unfair advantage. It might be worse in close in combat ... if I'm hiding behind a rock or a tree that get's dropped by the opponents renderer ... anyway ... things to think about and things that have to be dealt with. Currently flightgear punts on the whole issue and does no LOD on any terrain. A certain industry flight sim guru did this as well on his flight sims ... 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
Curtis L. Olson writes: Beyond that, if you are changing LOD of a tile, you have to consider what to do with all the objects on the surface of that tile. Do you let objects float or get buried, or do you let them float up and down as the underlying terrain changes ... none of these are ideal options. I'm talking about a very coarse LOD cutoff, i.e. 500nm or more. The idea would be to allow visibility from high-altitude flight without killing the program. 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
David Megginson writes: Curtis L. Olson writes: Beyond that, if you are changing LOD of a tile, you have to consider what to do with all the objects on the surface of that tile. Do you let objects float or get buried, or do you let them float up and down as the underlying terrain changes ... none of these are ideal options. I'm talking about a very coarse LOD cutoff, i.e. 500nm or more. The idea would be to allow visibility from high-altitude flight without killing the program. Is anyone familiar with 'fade level of detail'. The idea is to smooth the transition between two levels of detail to avoid 'popping' by using transparency. As an object moves through the LOD transition 'range' you draw both the higher LOD model and the lower LOD model on top of each other, but use a transparency to blend the two. If the transparency (or alpha) is in a range of 0 - 1 where 0 is completely transparent and 1 is fully opaque, then one version of the model is drawn with alpha = a and the other version of the model is drawn with alpha = 1 - a. This might be one technique we could use to transition between a high-resolution low altitude world and a lower resolution high altitude world, and then even a really low res globe for viewing things from space. 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: 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
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] 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] 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
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] 0.7.9 release schedule
Curtis L. Olson wrote: Now - Feb 8 (this week and next) is the last chance to submit new features for the 0.7.9 version. Preferably I'd see more bug fixes than features in this time. Feb 9 - Feb 15: Everyone should be building from cvs and the trial tarballs and reporting any bugs, build problems and platform incompatibilies. Try it out on your platform and compiler and send in bug reports sooner rather than later. If you don't, and 0.7.9 has problems on your platform, don't come complaining to me afterwards. :-) This time could also be used to commit non-code changes, like textures, sound files and last tweaks for aircraft configuration files. Feb 16: Official 0.7.9 release day. BTW. Is it just me, or is the color gone from the non-texture scenery (F9) ? If i do that it's just grey-scale. Erik ___ 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 writes: Uh oh, could this have been introduced when David converted the materials file to materials.xml? I don't think it's a widely used feature. I wouldn't be opposed to completely ripping it out. These days if your video hardware doesn't have reasonable texture you need to consider investing $50 into a video card that does. It should have survived -- at least, materials.xml still contains the information. I agree that it's not much use now (and most of the colours weren't set properly anyway), but we might want to do some blending with textures in the future. 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
On Tuesday 29 January 2002 05:08 pm, you wrote: I really, really, really want to roll out the FlightGear-0.7.9 release soon. I haven't posted an official release time table yet, but I will do that in this message. John Check writes: For sure. Just make sure you guys don't commit any major breakage to CVS this week ;) LWCE/New York is this week and as per John's request, perhaps it would be a good idea to go slow on a lot of major CVS changes to keep from complicating their lives. However, John, no matter what we do, it would be wise to get the latest version running before the show starts and just stick with it, warts and all. Tracking cvs and rebuilding the binary on the booth demo machines in the middle of the show is just asking for trouble, wierd problems, and uh ... it just was working or I don't know why it just did that type moments. Get a recent version working, and then just stick with it. Right. I was just busting you guys chops. I do notice the c310 JSBsim is a little shaky sometimes. Mainly 2 things 1) Going Hypersonic - once in a while she accelerates to muti mach speeds and gets sucked into NAN land 2) Reset crashes X sometimes. Usually after smacking into something. I'll take notes and see if I can come up with conditions to reproduce either situation. So here is my proposed schedule: Now - Feb 8 (this week and next) is the last chance to submit new features for the 0.7.9 version. Preferably I'd see more bug fixes than features in this time. Feb 9 - Feb 15: Everyone should be building from cvs and the trial tarballs and reporting any bugs, build problems and platform incompatibilies. Try it out on your platform and compiler and send in bug reports sooner rather than later. If you don't, and 0.7.9 has problems on your platform, don't come complaining to me afterwards. :-) Feb 16: Official 0.7.9 release day. Does this schedule sound reasonable? My time is very limited these days, but I will do my best to stick to this timeline. If everyone agrees, I will go ahead and cast it in stone. I will do everything I can to look at and apply everyone's patch submissions in time. Also be aware that David Megginson has cvs write access so you can send reasonable stuff to him as well. Be aware that neither of us blindly commit patch submissions and we evaluate your submission to make sure it fits in the overall scheme of the project. We try to fix things as much as possible if not, and only reject patches as a last resort. This can be a lot of work depending if the patch submitters send in something that is whipped together quickly, not thought through very well, or an 'ugly' hack. And we really cringe if we see the I didn't understand what this code over here did so I removed it type patches. Regards, Curt. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
