Re: [Flightgear-devel] [OT] Angry rant: the end of david@megginson.com
Matt I am all for warming up to Windows developers, or any from anywhere for that matter, or any end user (in fact and ordinary end user with basic experience can shed a lot of interesting light onto many applications). But I have indeed asked many times why people run certain pieces of software and I took Outlook Express as an example of what I have been told first hand. Cannot see how this argument is actually *nix developers versus people who develop on Windows, its not at all, or indeed anything to do with taking swipes at end users. Do you still think that is the case? Yes. Let's go back to the email which started all this: QUOTE using Outlook to read e-mail is like licking public toilets; using Outlook with a virus checker is like taking antibiotics and then licking public toilets (it might work, but it's hardly optimal). Please, people, if you have a choice, don't read e-mail with Outlook, or at least, don't read the flightgear lists with that program. I know that some of you are forced to use Outlook at work, but there's no excuse for using it at home or school UNQUOTE The use of Outlook is compared to licking public toilets, and to avoid any possible doubt, it is made clear that it applies to people using Outlook to read flightgear lists. There is apparently no excuse for doing this . Regarding your own comment - Have you ever heard of stereotyping, a device typically used to reinforce prejudice? Yes I have walked people through changing defaults in Outloook Express and many other similar tasks, probably rather more than you might imagine, but that's no excuse for extending any presumptions from those experiences to an entire population of users. It appears that the arguments put up by those of us who have been belittled by the toilet-licking analogy have fallen on completely deaf ears. Even now, I haven't seen a single acknowledgement that Outlook Express can be set up and used safely, and other messages defending the use of Outlook have been similarly ignored. Presumably those of us who continue to infect the flightgear lists by our use of these dispicable tools do so with continued disapproval. I have made a positive decision over the years to use Windows over a Unix environment (even though I continue to maintain a working Linux system). It shouldn't be necessary for me to have to defend this choice, for any reason, let alone stereotyping and historically-(mis)informed prejudice. You can choose to ignore the negative impact of all this on the potential Windows developer base if you wish, but I personally feel it is not good for the future or image of FlightGear for it to continue. It gives the impresssion, intentional or otherwise, that FlightGear is a *nix dominated, anti-Windows clique. I've had an offlist reply to an earlier posting, presumably on the assumption that the discussion was not relevant to the list. I beg to differ - it *is* important that a project which claims to welcome cross-platform and multiplatform development demonstrates respect for whichever platform potential developers may choose, including the safe use of the tools associated with that platform assisted by the application of common sense (as with any platform). Mally PS. I'm getting bogged down with the amount of effort I'm having to put into dealing with this important issue, so I'm not intending to to make any further reply. Please do not assume that this implies acceptance of any points subsequently raised. --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.512 / Virus Database: 309 - Release Date: 20/08/03 ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] [OT] Angry rant: the end of david@megginson.com
To all concerned May we please put this thread to rest and allow FGFS to return to soaring above petty OS bigotry Thanks Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] new scenery for w130n30 using 1 arcsec data
i regenerated the scenery for w130n30 using the 1 arcsec data available from http://edcwww.cr.usgs.gov/pub/data/srtm/United_States_1arcsec/1arcsec/ a lot of details show up now (like the hills of san francisco which i am painfully aware they exist since i live there and walk almost every day to the top of nob hill from the bart). you can see a couple of comparison pictures at http://caliban.lbl.gov/fgfs/ the pictures on the left were taken with the new scenery, the ones on the right with the old. i also made the new scenery available for download from http://caliban.lbl.gov/fgfs/w130n30/ i need to figure out how to put the buildings back (do i just copy the objects from the old directories?). hope somebody finds this useful. --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
[Flightgear-devel] Re: new scenery for w130n30 using 1 arcsec data
Alex Romosan [EMAIL PROTECTED] writes: i need to figure out how to put the buildings back (do i just copy the objects from the old directories?). nevermind. i figured it out. seemed to have lost the sutro tower though. undoubtedly because it's under the hills somewhere (and most of the buildings are low now). how do i change the height where the building is positioned? --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
RE: [Flightgear-devel] [OT] Angry rant: the end of david@megginson.com
On Wed, 2003-08-27 at 16:54, Norman Vine wrote: To all concerned May we please put this thread to rest and allow FGFS to return to soaring above petty OS bigotry Yes! No one cares about which OS you're using (I really do not!). Or applications, please take David's contention based on what he just went through. Someone asked about how to start coding in FlightGear, anyone actually help him yet? Thanks Matt ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: data/Lightingambient, 1.6, 1.7
Erik Hofman [EMAIL PROTECTED] said: Take a look at this screenshot. The shaded part of the aircraft (and buildings but thats hard to see) is much too bright. It's almost like it is about four our earlier (and very foggy): http://www.a1.nl/~ehofman/fgfs/download/f104-dawn.jpg What I'm trying to do now is get every lighting state to a completely sunny day with almost unlimited visibility. From there the state should be adjusted based on visibility, number of cloud layers and cloud types. That would be much easier to start with. Well just don't throw the cockpit out, that's part of the scene too. That particular time of day, the light changes really fast, possibly much faster than we're doing it. Here's a couple of screenshots from that other simulator. Their lighting seems pretty good, btw: http://www.microsoft.com/games/flightsimulator/img/screens1/ss4.jpg http://www.microsoft.com/games/flightsimulator/img/screens1/ss15.jpg It looks like, given the position of the sun, your screenshot is too dark overall. The sun is actually well above the horizon and probably a degree or two higher than the first msfs example, but ours is still quite a bit darker. In general all times of day appear too dark on my display now. Making the lighting brighter would provide more contrast against the ambient levels as well. In any case I'm open to suggestions on how we can do better lighting of the cockpit. With the lower ambient light levels the cockpit always appears way too dark except when the sun is directly behind. Lighting and shading is tricky because of the way that the human iris and brain adjusts for different levels. Late day photographs always appear to have darker shaded sides than realistic, unless the photographer has taken care to slightly overexpose the image. For this reason, matching to photographs won't give you a more realistic appearance, but a more photograph like appearance. True ambient light levels are due to reflections of light off other surfaces, but ambient lighting in opengl is useful for lightening the dark side so that it appears more like the real thing. At dawn the dark side of buildings contrasts to the bright sunlit sides, but you can still actually see the color of the buildings quite clearly. If you are standing with the sun in your eyes however, the shaded sides will appear very dark at the same time of day. But representing this effect on a screen is quite complex. Consider that facing the sun, the dark side of the building will appear to get lighter if the human viewer focuses on the dark areas, or blocks the sun itself with a hand or visor, or the sun temporarily falls behind a pillar in the aircraft. That is why I took the approach of setting the ambient lighting high enough to make dark sides (and the cockpit) visible, while leaving enough contrast in there to give the terrain some depth. The values probably could be tweaked, especially with the recent changes in lighting, but inevitably we'll be looking at tradeoffs. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] 3dmodel - jsbsim gear question
I was wondering about one issue while messing with the UNDERCARRIAGE section of my 717 model: the dxf drawings from Boeing show the nose gear at a slightly higher ground level than the main gear. Thus, when the real aircraft is on ground, the fwd part of the fuselage will have less ground clearance than the rear part. I used those 3-view dxf drawings in blender to model the 3d model for my 717. My question is: do I have to rotate the model in blender so that both nose and main gear are on the same level, or will jsbsim place the 3d model inside fgfs such that both nose and main gear will have ground contact ? Of course given the correct numbers in the UNDERCARRIAGE section (ie. shorter z-axis lenghts for the nose gear compared to main gear (my model's origin is the a/c nose)) Is my description clear enough to understand what I'm asking ? Regards, Manuel ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: new scenery for w130n30 using 1 arcsec data
Have a look in 942066.stg file the last figure is the altitude.It is currently set to zero. Cheers Innis Alex Romosan writes: i need to figure out how to put the buildings back (do i just copy the objects from the old directories?). nevermind. i figured it out. seemed to have lost the sutro tower though. undoubtedly because it's under the hills somewhere (and most of the buildings are low now). how do i change the height where the building is positioned? --alex-- _ Hotmail is now available on Australian mobile phones. Go to http://ninemsn.com.au/mobilecentral/signup.asp ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Cirrus clouds a bit solid from on top
Hello All, I just noticed that the cirrus cloud layer now looks very solid when you're above them. It looks as though there's no alpha-blending there at all. Although the blending is ok from below there also now seems to be a distinct 'roof' shape to the cloud layer when veiwed from below - a bit like being in an old ridge tent:) LeeE ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] 3dmodel - jsbsim gear question
On Thursday 28 August 2003 02:37, Manuel Bessler wrote: I was wondering about one issue while messing with the UNDERCARRIAGE section of my 717 model: the dxf drawings from Boeing show the nose gear at a slightly higher ground level than the main gear. Thus, when the real aircraft is on ground, the fwd part of the fuselage will have less ground clearance than the rear part. I used those 3-view dxf drawings in blender to model the 3d model for my 717. My question is: do I have to rotate the model in blender so that both nose and main gear are on the same level, or will jsbsim place the 3d model inside fgfs such that both nose and main gear will have ground contact ? Of course given the correct numbers in the UNDERCARRIAGE section (ie. shorter z-axis lenghts for the nose gear compared to main gear (my model's origin is the a/c nose)) Is my description clear enough to understand what I'm asking ? Regards, Manuel I'm not very familiar with JSBSim so I don't know if it includes a gear compression factor. This could be important when you set the gear up because it might assume, or you might have to tell it, whether the gear z-axis is a loaded or unloaded figure. When I started animating u/c suspension I found that it's easier if you model the gear at it's unloaded extension i.e. it's position when the a/c is in the air and there's no weight on it. If you're not going to animate the suspension then you should model the gear in it's loaded position other wise it'll stick through the ground while it's landed. LeeE ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] [OT] Angry rant: the end of david@megginson.com
On Wednesday 27 August 2003 7:54 pm, Norman Vine wrote: To all concerned May we please put this thread to rest and allow FGFS to return to soaring above petty OS bigotry Thanks Norman Amen to that ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: Static copy of TerraGear for Linux
On Wed, 27 Aug 2003 15:49:03 -0500, Ryan Larson [EMAIL PROTECTED] wrote: Anyone have a static copy of terragear for linux? I tried building one, but with no luck. Somehow it seems impossible to statically link to GL, GLU and GLUT. The configure scripts chokes on it. Running just ./configure finds everything that's needed (believe me, it took me almost a day to have everything OK to compile TerraGear from cvs; all is there). But when I run: CFLAGS=-static -static-libgcc -L/usr/X11R6/lib LDFLAGS=-static -L/usr/X11R6/lib ./configure it stops with: checking for glNewList in -lGLcore... no checking for glNewList in -lGL... no checking for glNewList in -lMesaGL... no checking for gluLookAt in -lGLU... no checking for gluLookAt in -lMesaGLU... no checking for glutGetModifiers in -lglut... no checking for glutGameModeString in -lglut... no Unable to find the necessary OpenGL or GLUT libraries. (It did the same BTW w/o the -L's and w/o -static-libgcc. I only added those, just in case) Normally, I have no problem creating a static binary (for example (sometimes) for my GF, who runs a different Linux distro and had limitted space), but I can't get this working. BTW This is on a MDK9.1 Linux installation. I got all the sourcecode (TerraGear and mandatory libs) from CVS at August 23. Anyway, no luck in building static binaries for Terragear. Anybody has an idea? ( I really hope I'm not missing something trivial :-) It's late around here). --Ivo [hmm, this mail got bounced at first. Finally I changed my e-mail acount which is subscribed to this list :-) so it should get through now] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] [OT] Angry rant: the end of david@megginson.com
John Check [EMAIL PROTECTED] said: On Wednesday 27 August 2003 7:54 pm, Norman Vine wrote: To all concerned May we please put this thread to rest and allow FGFS to return to soaring above petty OS bigotry Thanks Norman Amen to that Ah...blessed silence :-) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] 3dmodel - jsbsim gear question
My question is: do I have to rotate the model in blender so that both nose and main gear are on the same level, or will jsbsim place the 3d model inside fgfs such that both nose and main gear will have ground contact ? Of course given the correct numbers in the UNDERCARRIAGE section (ie. shorter z-axis lenghts for the nose gear compared to main gear (my model's origin is the a/c nose)) Make your 3D model normally - i.e. do not rotate it to account for the aircraft at-rest attitude in your 3D model. Yes, JSBSim will model gear height and compression and should accurately place the model. This reminds me - I still haven't coded the geometric reference point ... ducks But really, I so intend to do it. I've just been busier than I could even begin to say. My head is spinning most of the time. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] [OT] Outlook comments
I have been wondering whether the Outlook autorun feature could conveniently be used to assist Windows users who would like to use FlightGear. They sign up for the mailing list [EMAIL PROTECTED] as usual and their start of subscription mail message has a PIF attachment that autoinstalls FlightGear. Thereafter, whenever we have a version upgrade, the announcement is copied to that mailing list ... together with a PIF autorun attachment that will apply the upgrade without user intervention. Convenient, no ? From: Norman Vine [EMAIL PROTECTED] May we please put this thread to rest and allow FGFS to return to soaring above petty OS bigotry Seconded. FWIW, the discussion is not about OS bigotry. Anybody can run Outlook (with WINE) on Linux and run most Linux mail readers on Windows. With the former, a default Outlook will behave just as badly on Linux, and, with the latter, most casual users will have trouble with attachments. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: new scenery for w130n30 using 1 arcsec data
Alex Romosan wrote: Alex Romosan [EMAIL PROTECTED] writes: i need to figure out how to put the buildings back (do i just copy the objects from the old directories?). nevermind. i figured it out. seemed to have lost the sutro tower though. undoubtedly because it's under the hills somewhere (and most of the buildings are low now). how do i change the height where the building is positioned? It looks a lot better, and the polygon count is not so huge. To correct building height, get this file : http://perso.wanadoo.fr/frbouvi/flightsim/942066.stg and put it in w123n37. Or use fgsd. Download would be easier if there was a tarball ;-) -Fred ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Any Volunteers?
Erik Hofman wrote: Frederic Bouvier wrote: You are now done preparing the elevation data. To build scenery, TerraGear needs only the files and directories under the work/DEM-30/; if you are tight for space, you can delete all of your working files under data/ now, before going any further (if you have a lot of space, it doesn't hurt to keep them around). That's all ? or do you want us to generate the scenery ? I have the whole w020n90 dem done now. Curtis need the resulting *.arr.gz and *.fit.gz files. They should probably be generated by ArrayFit or Terra, but I haven't found a manual for that. Is there somebody willing to collect the data ? -Fred ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] [OT] Outlook comments
I see - you get one final ill-conceived dig in, and _then_ agree the subject should be dropped? Can anyone else agreeing the subject should be dropped please do so silently. thanks Mally - Original Message - From: Alex Perry [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, August 28, 2003 5:22 AM Subject: RE: [Flightgear-devel] [OT] Outlook comments I have been wondering whether the Outlook autorun feature could conveniently be used to assist Windows users who would like to use FlightGear. They sign up for the mailing list [EMAIL PROTECTED] as usual and their start of subscription mail message has a PIF attachment that autoinstalls FlightGear. Thereafter, whenever we have a version upgrade, the announcement is copied to that mailing list ... together with a PIF autorun attachment that will apply the upgrade without user intervention. Convenient, no ? From: Norman Vine [EMAIL PROTECTED] May we please put this thread to rest and allow FGFS to return to soaring above petty OS bigotry Seconded. FWIW, the discussion is not about OS bigotry. Anybody can run Outlook (with WINE) on Linux and run most Linux mail readers on Windows. With the former, a default Outlook will behave just as badly on Linux, and, with the latter, most casual users will have trouble with attachments. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.512 / Virus Database: 309 - Release Date: 19/08/03 ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: data/Lightingambient, 1.6, 1.7
Jim Wilson wrote: Erik Hofman [EMAIL PROTECTED] said: What I'm trying to do now is get every lighting state to a completely sunny day with almost unlimited visibility. From there the state should be adjusted based on visibility, number of cloud layers and cloud types. That would be much easier to start with. Well just don't throw the cockpit out, that's part of the scene too. That particular time of day, the light changes really fast, possibly much faster than we're doing it. Here's a couple of screenshots from that other simulator. Their lighting seems pretty good, btw: http://www.microsoft.com/games/flightsimulator/img/screens1/ss4.jpg http://www.microsoft.com/games/flightsimulator/img/screens1/ss15.jpg I can overwhelm you with pictures of other simulators that show this isn't the right lighting for these situations... That is why I took the approach of setting the ambient lighting high enough to make dark sides (and the cockpit) visible, while leaving enough contrast in there to give the terrain some depth. The values probably could be tweaked, especially with the recent changes in lighting, but inevitably we'll be looking at tradeoffs. Okay, lets add two other situations that might change ambient lighting: 1. Is the sun visible 2. view dependent settings (e.g. cockpit view). The point stands, I wan to start from the situation where: a. We are in the open terrain. b. It is a clear sky and there is almost unlimited visibility. This means high contrast (low ambient) high specular and modest diffuse). Then we could change everything else relative to that. Changing the lighting to match the cockpit appearance and losing realism for the outside view doesn't help for that. We need a fixed starting point and go from there. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Any Volunteers?
On Thu, 28 Aug 2003, Frederic Bouvier wrote: Erik Hofman wrote: Curtis need the resulting *.arr.gz and *.fit.gz files. They should probably be generated by ArrayFit or Terra, but I haven't found a manual for that. Is there somebody willing to collect the data ? I have *.arr.gz files for the whole planet now. If someone wants to let me know how I should go about running arrayfit or terrafit on this lot then I'll get it processed. -- Jon Stockill [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Any Volunteers?
Jon Stockill wrote: On Thu, 28 Aug 2003, Frederic Bouvier wrote: Erik Hofman wrote: Curtis need the resulting *.arr.gz and *.fit.gz files. They should probably be generated by ArrayFit or Terra, but I haven't found a manual for that. Is there somebody willing to collect the data ? I have *.arr.gz files for the whole planet now. If someone wants to let me know how I should go about running arrayfit or terrafit on this lot then I'll get it processed. It would be nice if somebody could step up (Curtis?) to get this data into the next scenery build. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Any Volunteers?
On Thu, 28 Aug 2003, Erik Hofman wrote: It would be nice if somebody could step up (Curtis?) to get this data into the next scenery build. Well I'm just clearing some disk space at the moment, unless someone says otherwise I'll just run: arrayfit --minnodes=50 --maxnodes=600 --maxerror=50 --input=$file on all the .arr data as terra doesn't seem to want to compile. -- Jon Stockill [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Any Volunteers?
Jon Stockill writes: On Thu, 28 Aug 2003, Erik Hofman wrote: It would be nice if somebody could step up (Curtis?) to get this data into the next scenery build. Well I'm just clearing some disk space at the moment, unless someone says otherwise I'll just run: arrayfit --minnodes=50 --maxnodes=600 --maxerror=50 --input=$file on all the .arr data as terra doesn't seem to want to compile. Jon What errors are you getting from the Terra build ?? What OS are you running ? AFAICT we want to use the Python script which if caled with no arguments should print some help i.e. $ python src/Prep/TerraFit/terrafit.py Usage: src/Prep/TerraFit/terrafit.py -h | --help -m | --minnodes 50 -x | --maxnodes 600 -e | --maxerror 50 -f | --factor 0.03 -v | --version [file] | [path to walk] Algorithm will produce at least 50 fitted nodes, but no more than 600. Within that range, the algorithm will stop if the maximum elevation error for any remaining point drops below 50 meters. Increasing the maxnodes value and/or decreasing maxerror will produce a better surface approximation. The input file must be a .arr.gz file such as that produced by demchop or hgtchop utils. NOTE : If a directory is input all .arr files in directory will be processed recursively. The output file(s) is called .fit.gz and is simply a list of from the resulting fitted surface nodes. The user of the .fit file will need to retriangulate the surface. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Any Volunteers?
On Thu, 28 Aug 2003, Norman Vine wrote: What errors are you getting from the Terra build ?? After tweaking the Makefile to use the right compiler and flags, and point to glut running make gives: g++ -I/usr/X11R6/include -O2 -g -DSAFETY -DIOSTREAMH -c terra.cc In file included from Geom.h:24, from Heap.h:4, from GreedyInsert.h:4, from terra.h:4, from terra.cc:1: Vec2.h:43: ISO C++ forbids declaration of `ostream' with no type Vec2.h:43: `ostream' is neither function nor member function; cannot be declared friend Vec2.h:43: syntax error before `' token What OS are you running ? Slackware Linux current, which uses gcc 3.2.3. Is that the source of the problem? AFAICT we want to use the Python script which if caled with no arguments should print some help i.e. $ python src/Prep/TerraFit/terrafit.py AIUI this is just a script which drives terra though, not a standalone solution? Usage: src/Prep/TerraFit/terrafit.py -h | --help -m | --minnodes 50 -x | --maxnodes 600 -e | --maxerror 50 -f | --factor 0.03 -v | --version [file] | [path to walk] Algorithm will produce at least 50 fitted nodes, but no more than 600. Within that range, the algorithm will stop if the maximum elevation error for any remaining point drops below 50 meters. Are these sensible values, or should we be pushing maxnodes up, and maxerror down (and if so, how far) - I'm guessing that fitting a better surface will take longer, I'm not particularly worried about this, as long as we get a good result for the finished scenery - also more points=more triangles, and we need to ensure we have scenery that's going to be usable on a wide range of hardware. -- Jon Stockill [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Any Volunteers?
Jon Stockill writes: On Thu, 28 Aug 2003, Erik Hofman wrote: It would be nice if somebody could step up (Curtis?) to get this data into the next scenery build. Well I'm just clearing some disk space at the moment, unless someone says otherwise I'll just run: arrayfit --minnodes=50 --maxnodes=600 --maxerror=50 --input=$file on all the .arr data as terra doesn't seem to want to compile. Actually you will want to run terrafit.py ... it will recurse through the specified directory and produce .fit files for any .arr files it finds. Curt. -- Curtis Olson HumanFIRST Program FlightGear Project Twin Citiescurt 'at' me.umn.edu curt 'at' flightgear.org 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] Any Volunteers?
On Thu, 28 Aug 2003, Norman Vine wrote: This is a recnt change, perhaps you need to do a CVS up Yup, that sorted it - looks like I was running quite an old cvs snapshot, I think I downloaded it when there were some problems with the cvs server. A fresh checkout compiled much easier, with no fiddling required to get terra to build. aside Ah now we are leaving science and getting into art :-) /aside Oh dear - I never was much of an artist :-) The factor value is the only one which is required to be as above it sets the scaling for vertical scale vs horizontal scale of the input data OK AFAIK these values are the ones that Curt was using as I just copied them from his 'C' driver program for the arrayfit process Yes - the values shown by both progs when run without parameters are the same. FWIW I would decrease the maxerror considerably perhaps to 2 at least to 5 as AFAICT Terra will always insert nodes ordered by 'max error' and will always quit when maxnodes is reached. As to what to use for maxnodes, I am not sure. Right, I've got: terrafit.py -f 0.03 -m 50 -x 1200 -e 2 $work/DEM-30 I'll see what that creates, and tweak it as necessary. I wouldn't worry to much about run time as Terra is 'remarkably' quick. i.e using Terra even when driven with a Python script should be substantially more then an order of magnitude quicker then using arrayfit It's worth getting Terra running before starting the global decimation :-) Well it's running with the settings as above, I'll see what it spits out. -- Jon Stockill [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Any Volunteers?
On Thu, 28 Aug 2003, Curtis L. Olson wrote: Actually you will want to run terrafit.py ... it will recurse through the specified directory and produce .fit files for any .arr files it finds. I'd already overcome that problem with a combination of for and find to make arrayfit process it all, but terrafit.py seems like a much nicer solution :-) -- Jon Stockill [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] AutoTrim ?
I was sitting in my car waiting for a doctors appointment watching the departures from KHYA fly overhead and saw these poor souls and was thinking it was odd they still had the gear down http://www.capecodonline.com/cctimes/repairpreceded28.htm Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Any Volunteers?
On Thu, 28 Aug 2003, Jon Stockill wrote: Well it's running with the settings as above, I'll see what it spits out. I've noticed a little bit of weirdness already: 1621 pts/2S 0:01 python /usr/local/bin/terrafit.py -m 50 -x 1200 -e 2 -f 0.03 work/DEM-30/ 1714 pts/2R 0:00 terra -e 50.00 -n 50 -p 600 -h 0.03 -o work/DEM-30/e000n00/e000n06/2955316.obj obj work/DEM-30/e0 It looks like none of the parameters aren't being passed through to terra properly. -- Jon Stockill [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] 3dmodel - jsbsim gear question
On Thu, Aug 28, 2003 at 03:03:40AM +0100, Lee Elliott wrote: I'm not very familiar with JSBSim so I don't know if it includes a gear compression factor. This could be important when you set the gear up because it might assume, or you might have to tell it, whether the gear z-axis is a loaded or unloaded figure. When I started animating u/c suspension I found that it's easier if you model the gear at it's unloaded extension i.e. it's position when the a/c is in the air and there's no weight on it. If you're not going to animate the suspension then you should model the gear in it's loaded position other wise it'll stick through the ground while it's landed. I'm not gonna animate suspension at the moment. i guess the dxfs i used are set up for the a/c sitting static on-ground. I was wondering about how jsbsim determines where to put the 3d model. All i can see in the config is the geometric refences of the different a/c parts like engines, gear, c.g., pilot eye pos'n,... but nothing referencing that coord-system with ground, except thru the gear pos'ns Two ways i can imagine jsbsim doing this: (imagine the gear, all with different lenghts) 1. it takes the AC_GEAR from UNDERCARRIAGE that would hit the ground first if the aircraft would be dropped down on the runway vertically. 2. it does 1. but for all three, but rotating/translating the 3d model so that all 3 gear of the 3d model will be on the ground like the real world (given that the 3d model and the fdm gear definitions correspond) Regards, Manuel ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] [OT] Outlook comments
Alex Perry writes: I have been wondering whether the Outlook autorun feature could conveniently be used to assist Windows users who would like to use FlightGear. They sign up for the mailing list [EMAIL PROTECTED] as usual and their start of subscription mail message has a PIF attachment that autoinstalls FlightGear. Thereafter, whenever we have a version upgrade, the announcement is copied to that mailing list ... together with a PIF autorun attachment that will apply the upgrade without user intervention. Convenient, no ? Hehe, Several years ago when the windows email virus/worm stuff started to become popular, I saw a similar proposal (that actually sounded quite plausible) for installing linux on the person's machine via this outlook email hole. Fortunately, it appears that the linux people that are sharp enough to pull this off have more useful/ethical things to do. But I suppose that would be one way to fight the market share wars. :-) Curt. -- Curtis Olson HumanFIRST Program FlightGear Project Twin Citiescurt 'at' me.umn.edu curt 'at' flightgear.org 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] Any Volunteers?
Jon Stockill writes: The factor value is the only one which is required to be as above it sets the scaling for vertical scale vs horizontal scale of the input data As far as I can tell the factor value is only used by xterra to scale the visualization. It's not used at all by terra (so we could probalby drop it safely.) Curt. -- Curtis Olson HumanFIRST Program FlightGear Project Twin Citiescurt 'at' me.umn.edu curt 'at' flightgear.org 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] Any Volunteers?
Erik Hofman writes: It would be nice if somebody could step up (Curtis?) to get this data into the next scenery build. My brain is full, I was just hoping someone else could coordinate this until one of my nuerons becomes free. Curt. -- Curtis Olson HumanFIRST Program FlightGear Project Twin Citiescurt 'at' me.umn.edu curt 'at' flightgear.org 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] Any Volunteers?
On Thu, 28 Aug 2003, Curtis L. Olson wrote: Erik Hofman writes: It would be nice if somebody could step up (Curtis?) to get this data into the next scenery build. My brain is full, I was just hoping someone else could coordinate this until one of my nuerons becomes free. I'm happy to do the complete scenery build - just let me know what you want including, and tell me where to upload it. -- Jon Stockill [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Any Volunteers?
Jon Stockill writes: On Thu, 28 Aug 2003, Curtis L. Olson wrote: Erik Hofman writes: It would be nice if somebody could step up (Curtis?) to get this data into the next scenery build. My brain is full, I was just hoping someone else could coordinate this until one of my nuerons becomes free. I'm happy to do the complete scenery build - just let me know what you want including, and tell me where to upload it. Well, I'm working through the process of a world scenery build trying to identify and fix issues as I go. Erik thought it would be nice to slip the new GLOBE 30arcsec terrain data in there, but that was just more than I had brain capacity for at the moment. It still is, but if someone wants to generate and collect the .arr.gz and .fit.gz files for this data set and put them someplace where I can drop them into my build tree, then I could probably handle doing that. If others want to build scenery, that is great, the more testers, debuggers, data collectors, idea generators, bug fixers, code writers, etc. the better. But I don't have time at the moment to offer a lot of direction. Best regards, Curt. -- Curtis Olson HumanFIRST Program FlightGear Project Twin Citiescurt 'at' me.umn.edu curt 'at' flightgear.org 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] Any Volunteers?
Jon Stockill writes:
On Thu, 28 Aug 2003, Jon Stockill wrote:
Well it's running with the settings as above, I'll see what it spits out.
I've noticed a little bit of weirdness already:
1621 pts/2S 0:01 python /usr/local/bin/terrafit.py -m 50 -x 1200
-e 2 -f 0.03 work/DEM-30/
1714 pts/2R 0:00 terra -e 50.00 -n 50 -p 600 -h 0.03 -o
work/DEM-30/e000n00/e000n06/2955316.obj obj work/DEM-30/e0
It looks like none of the parameters aren't being passed through to terra
properly.
Arghh.. I never really tested this and what I had is just wrong.. :-(
What was I thinking !!
HTH
Norman
$ cvs diff -u terrafit.py
Index: terrafit.py
===
RCS file: /var/cvs/TerraGear-0.0/TerraGear/src/Prep/TerraFit/terrafit.py,v
retrieving revision 1.4
diff -u -r1.4 terrafit.py
--- terrafit.py 19 Aug 2003 02:27:08 - 1.4
+++ terrafit.py 28 Aug 2003 13:55:09 -
@@ -209,9 +209,9 @@
sys.stderr.write('%s version %s\n' % (sys.argv[0],VERSION,))
sys.exit(0)
if o in ('--minnodes','-m'): minnodes = string.atoi(v)
-if o == ('--maxnodes','-x'): maxnodes = string.atoi(v)
-if o == ('--maxerror','-e'): maxerror = string.atof(v)
-if o == ('--factor','-f'): factor = string.atof(v)
+if o in ('--maxnodes','-x'): maxnodes = string.atoi(v)
+if o in ('--maxerror','-e'): maxerror = string.atof(v)
+if o in ('--factor','-f'): factor = string.atof(v)
if len(args) == 0 and len(opts) == 0:
usage()
sys.exit(1)
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Any Volunteers?
On Thu, 28 Aug 2003, Curtis L. Olson wrote: more than I had brain capacity for at the moment. It still is, but if someone wants to generate and collect the .arr.gz and .fit.gz files for this data set and put them someplace where I can drop them into my build tree, then I could probably handle doing that. I'll have all that once terrafit finishes running. If others want to build scenery, that is great, the more testers, debuggers, data collectors, idea generators, bug fixers, code writers, etc. the better. But I don't have time at the moment to offer a lot of direction. Not a problem. I'm not really a programmer - I'm a sysadmin, but I'm happy to contribute to data collection, and I'm sure there's more data sets we can pull out of the vmap0 data. -- Jon Stockill [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Any Volunteers?
Curtis L. Olson writes: The factor value is the only one which is required to be as above it sets the scaling for vertical scale vs horizontal scale of the input data As far as I can tell the factor value is only used by xterra to scale the visualization. It's not used at all by terra (so we could probalby drop it safely.) Yes, I think that is correct Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Any Volunteers?
Curtis L. Olson writes:
Jon Stockill writes:
On Thu, 28 Aug 2003, Curtis L. Olson wrote:
Actually you will want to run terrafit.py ... it will recurse through
the specified directory and produce .fit files for any .arr files it
finds.
I'd already overcome that problem with a combination of for and find
to make arrayfit process it all, but terrafit.py seems like a much nicer
solution :-)
I don't know enough python to pull this off (and don't have time to
investigate it right now anyway) but it would be handy perhaps to make
terrafit.py check if the .fit file is newer than the .arr file and
if so skip it (kind of like the make utility.)
Hmm.. this is easy enough todo
Note this patch includes my earlier fix for paramater passing
HTH
Norman
$ cvs diff -u terrafit.py
Index: terrafit.py
===
RCS file: /var/cvs/TerraGear-0.0/TerraGear/src/Prep/TerraFit/terrafit.py,v
retrieving revision 1.4
diff -u -r1.4 terrafit.py
--- terrafit.py 19 Aug 2003 02:27:08 - 1.4
+++ terrafit.py 28 Aug 2003 14:16:56 -
@@ -106,6 +106,18 @@
raise IOError, (2, 'No such file or directory: ' + fname)
return
+# need to do this twice to get basename 'XXX.arr.gz'
+basename,ext = os.path.splitext(fname)
+basename,ext = os.path.splitext(basename)
+gzName = basename+.fit.gz
+
+try:
+if path.getmtime(gzName) path.getmtime(fname):
+print Skipping: %s is newer then %s%(gzName,fname)
+return
+except:
+pass
+
gzin = GzipFile(fname, 'rb')
data = gzin.readline()
@@ -130,17 +142,12 @@
max_z = max(max_z,max(data[i]))
min_z = min(min_z,min(data[i]))
-# need to do this twice to get basename 'XXX.arr.gz'
-basename,ext = os.path.splitext(fname)
-basename,ext = os.path.splitext(basename)
-
pgmName = basename+'.pgm'
pre_terra(pgmName, data, span_x, span_y, max_z, min_z)
objName = basename+'.obj'
npts = run_terra(thresh, minnodes, count, factor, objName, pgmName)
-gzName = basename+.fit.gz
post_terra(objName, gzName, step_x, step_y, min_x, min_y, min_z)
if CLEAN_TEMP_FILES:
@@ -209,9 +216,9 @@
sys.stderr.write('%s version %s\n' % (sys.argv[0],VERSION,))
sys.exit(0)
if o in ('--minnodes','-m'): minnodes = string.atoi(v)
-if o == ('--maxnodes','-x'): maxnodes = string.atoi(v)
-if o == ('--maxerror','-e'): maxerror = string.atof(v)
-if o == ('--factor','-f'): factor = string.atof(v)
+if o in ('--maxnodes','-x'): maxnodes = string.atoi(v)
+if o in ('--maxerror','-e'): maxerror = string.atof(v)
+if o in ('--factor','-f'): factor = string.atof(v)
if len(args) == 0 and len(opts) == 0:
usage()
sys.exit(1)
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: data/Lightingambient, 1.6, 1.7
Erik Hofman [EMAIL PROTECTED] said: I can overwhelm you with pictures of other simulators that show this isn't the right lighting for these situations... There is no right unless you can simulate the eye/brain, which you cannot. The eye is going to make it brighter than it really is at dawn. Those MSFS shots look good, even if they aren't correct (not good enough to get me to waste $50 on the program though ;-)). Okay, lets add two other situations that might change ambient lighting: 1. Is the sun visible 2. view dependent settings (e.g. cockpit view). The point stands, I wan to start from the situation where: a. We are in the open terrain. b. It is a clear sky and there is almost unlimited visibility. Are you saying that the lighting would then be adjustable based on view? You didn't infer that earlier. If so, I'll sit tight. This means high contrast (low ambient) high specular and modest diffuse). Then we could change everything else relative to that. Changing the lighting to match the cockpit appearance and losing realism for the outside view doesn't help for that. From my point of view, visability inside the cockpit is most important in a flight simulator. Messing with ambient lighting for the entire scene may not the best approach. It certainly doesn't address night illumintation. Again, if anyone has any suggestions on addressing cockpit lighting, I'd be very grateful. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Any Volunteers?
Norman Vine wrote: Curtis L. Olson writes: I don't know enough python to pull this off (and don't have time to investigate it right now anyway) but it would be handy perhaps to make terrafit.py check if the .fit file is newer than the .arr file and if so skip it (kind of like the make utility.) Hmm.. this is easy enough todo Note this patch includes my earlier fix for paramater passing I've put it in CVS. Thanks! Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Any Volunteers?
From: Curtis L. Olson [mailto:[EMAIL PROTECTED] Jon Stockill writes: On Thu, 28 Aug 2003, Curtis L. Olson wrote: Actually you will want to run terrafit.py ... it will recurse through the specified directory and produce .fit files for any .arr files it finds. I'd already overcome that problem with a combination of for and find to make arrayfit process it all, but terrafit.py seems like a much nicer solution :-) I don't know enough python to pull this off (and don't have time to investigate it right now anyway) but it would be handy perhaps to make terrafit.py check if the .fit file is newer than the .arr file and if so skip it (kind of like the make utility.) Then you could restart a long run (that died or was killed for any reason) and not have to redo a lot of work. Curt. Or could it actually use make? Richard ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Any Volunteers?
Richard Bytheway writes: Or could it actually use make? maybe but see http://www.scons.org/ Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] AutoTrim ?
Jim Wilson writes: When the 1900 first came out it was _so_ much nicer than anything else flying out of this part of Maine. You see them in the air all day long now down around the cape and the vineyard. If there is a problem, it isn't obvious or we'd be probably be hearing talk of a grounding...one would hope. Not to take away from the seriousness of this, but to angle the discussion back towards flightgear. Has anyone thought about building a B1900 model for flightgear? It would be nice to have a really well done twin turbo (3d model, flight model, engine model, prop model, cockpit, sounds, animations, etc.) and I think this would be a great candidate. Regards, Curt. -- Curtis Olson HumanFIRST Program FlightGear Project Twin Citiescurt 'at' me.umn.edu curt 'at' flightgear.org 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] AutoTrim ?
Norman Vine [EMAIL PROTECTED] said: I was sitting in my car waiting for a doctors appointment watching the departures from KHYA fly overhead and saw these poor souls and was thinking it was odd they still had the gear down http://www.capecodonline.com/cctimes/repairpreceded28.htm Did you see the dive? It was just Sunday that I left the area down there, quite a shock, when I read the news the other night. When the 1900 first came out it was _so_ much nicer than anything else flying out of this part of Maine. You see them in the air all day long now down around the cape and the vineyard. If there is a problem, it isn't obvious or we'd be probably be hearing talk of a grounding...one would hope. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] AutoTrim ?
Curtis L. Olson [EMAIL PROTECTED] said: Jim Wilson writes: When the 1900 first came out it was _so_ much nicer than anything else flying out of this part of Maine. You see them in the air all day long now down around the cape and the vineyard. If there is a problem, it isn't obvious or we'd be probably be hearing talk of a grounding...one would hope. Not to take away from the seriousness of this, but to angle the discussion back towards flightgear. Has anyone thought about building a B1900 model for flightgear? It would be nice to have a really well done twin turbo (3d model, flight model, engine model, prop model, cockpit, sounds, animations, etc.) and I think this would be a great candidate. Oh yes! It's a beautiful aircraft visually and is certainly a standard in recent years. I'm just kind of thinking I should finish some of my other projects first :-). But...if someone is intetrested in configuring an FDM (which takes some time to do right) I'll start a 3D model. I really can't take on both right now. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] B1900
Has anyone thought about building a B1900 model for flightgear? It would be nice to have a really well done twin turbo (3d model, flight model, engine model, prop model, cockpit, sounds, animations, etc.) and I think this would be a great candidate. In order to accurately model a turboprop we'll need a new turboprop engine module. Right now we can fake it in JSBSim by using a turbine which puts out less thrust as speed increases (see the OV-10). We can also fake it by connecting a prop to a turbine (see the Fokker 50). These work fine for now, but real turboprops need automatic fuel control and prop angle control, which don't yet exist in FG. Most turboprops operate in one of two modes, CONSTANT SPEED and NORMAL (which are actually called different names by different manufacturers). In CONSTANT SPEED mode the engine turns at a constant high rpm ( ~ 98%-100% ), and the power lever controls prop pitch. In this case the fuel controller increases fuel flow automatically to maintain rpm. This mode is used for takeoff, landing, or aerobatics, where instant power response is desired. In NORMAL mode the power lever controls both rpm and prop angle. The fuel controller and prop controller automatically make the optimum adjustments. This mode is used for cruise. All this is a level of complexity far above the current turbine and propeller models, and it may be best to have a seperate turboprop model which takes care of the turbine, fuel control, prop control and prop. In the mean time the fakes work pretty well. -- David Culp [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] AutoTrim ?
Curtis L. Olson wrote: Has anyone thought about building a B1900 model for flightgear? It would be nice to have a really well done twin turbo (3d model, flight model, engine model, prop model, cockpit, sounds, animations, etc.) and I think this would be a great candidate. What's wrong with the Fokker 50? Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] AutoTrim ?
Erik Hofman writes: Curtis L. Olson wrote: Has anyone thought about building a B1900 model for flightgear? It would be nice to have a really well done twin turbo (3d model, flight model, engine model, prop model, cockpit, sounds, animations, etc.) and I think this would be a great candidate. What's wrong with the Fokker 50? How's it doing lately, it wasn't very far along the last time I looked at it. Regards, Curt. -- Curtis Olson HumanFIRST Program FlightGear Project Twin Citiescurt 'at' me.umn.edu curt 'at' flightgear.org 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] AutoTrim ?
Erik Hofman writes: Curtis L. Olson wrote: Has anyone thought about building a B1900 model for flightgear? It would be nice to have a really well done twin turbo (3d model, flight model, engine model, prop model, cockpit, sounds, animations, etc.) and I think this would be a great candidate. What's wrong with the Fokker 50? I should have said, Yes! let's do both. :-) Curt. -- Curtis Olson HumanFIRST Program FlightGear Project Twin Citiescurt 'at' me.umn.edu curt 'at' flightgear.org 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] AutoTrim ?
Curtis L. Olson wrote: Erik Hofman writes: Curtis L. Olson wrote: Has anyone thought about building a B1900 model for flightgear? It would be nice to have a really well done twin turbo (3d model, flight model, engine model, prop model, cockpit, sounds, animations, etc.) and I think this would be a great candidate. What's wrong with the Fokker 50? How's it doing lately, it wasn't very far along the last time I looked at it. The B1900 is still nowhere :-) There is a FDM (needs tweaking) and a 3D model with animations. I do have some audio somewhere, and since it has a glass cockpit it can reuse much of Jim's 747 cockpit. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] AutoTrim ?
Erik Hofman [EMAIL PROTECTED] said: Curtis L. Olson wrote: Has anyone thought about building a B1900 model for flightgear? It would be nice to have a really well done twin turbo (3d model, flight model, engine model, prop model, cockpit, sounds, animations, etc.) and I think this would be a great candidate. What's wrong with the Fokker 50? Erik That is a twin turbo and so is the OV10. The B1900 is a lot different otherwise, a class we really don't have represented (light turbo). Better looking too. ::: duck ::: :-) Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] AutoTrim ?
Curtis L. Olson [EMAIL PROTECTED] said: Erik Hofman writes: Curtis L. Olson wrote: Has anyone thought about building a B1900 model for flightgear? It would be nice to have a really well done twin turbo (3d model, flight model, engine model, prop model, cockpit, sounds, animations, etc.) and I think this would be a great candidate. What's wrong with the Fokker 50? I should have said, Yes! let's do both. :-) Yes, the Fokker 50 is a very nice aircraft, even if a little uncomely in the nose area. ;-) Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] AutoTrim ?
Jim Wilson wrote: Erik Hofman said: What's wrong with the Fokker 50? That is a twin turbo and so is the OV10. The B1900 is a lot different otherwise, a class we really don't have represented (light turbo). Better looking too. ::: duck ::: :-) Did you ever have the honor to see one fly? Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] AutoTrim ?
Erik Hofman [EMAIL PROTECTED] said: Jim Wilson wrote: Erik Hofman said: What's wrong with the Fokker 50? That is a twin turbo and so is the OV10. The B1900 is a lot different otherwise, a class we really don't have represented (light turbo). Better looking too. ::: duck ::: :-) Did you ever have the honor to see one fly? It is possible during one of several layovers in Keflavic. But I can't swear to it. I remember seeing some twins about that size, but didn't know what they were. The truth is I've been crazy about aircraft since I was five years old and think they are _all_ really neat in their own way. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Squared Terrain Textures any ideas how toimprove/change that?
Hello, In Flightgear the Terrain is looking like a carpet with squared textures this looks IMO relative unnatural. Like in this Screenshot: http://www.flightgear.org/images/crop-variety.jpg Now i want to ask what solutions are available to change this, any ideas? For example when i take a look at screenshots of other flight simulations like the Game Flying Fortress 2 the terrain looks relative natural, because you can't see hard edges, borders, shapes or lines. The changeover from one terrain type to another is fluxionary, that makes the terrain look very natural. Do you have any ideas how they made this? And how hard whould it be to implement something similar into flightgear? Here are some example screenshot of Flying Fortess 2 for comparisson: http://www.cdmag.com/articles/027/189/shot2.html http://www.cdmag.com/articles/025/071/shot1.html http://www.cdmag.com/articles/025/071/shot5.html Best Regards, Oliver C. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] 3dmodel - jsbsim gear question
On Thursday 28 August 2003 14:16, Manuel Bessler wrote: On Thu, Aug 28, 2003 at 03:03:40AM +0100, Lee Elliott wrote: I'm not very familiar with JSBSim so I don't know if it includes a gear compression factor. This could be important when you set the gear up because it might assume, or you might have to tell it, whether the gear z-axis is a loaded or unloaded figure. When I started animating u/c suspension I found that it's easier if you model the gear at it's unloaded extension i.e. it's position when the a/c is in the air and there's no weight on it. If you're not going to animate the suspension then you should model the gear in it's loaded position other wise it'll stick through the ground while it's landed. I'm not gonna animate suspension at the moment. i guess the dxfs i used are set up for the a/c sitting static on-ground. I was wondering about how jsbsim determines where to put the 3d model. All i can see in the config is the geometric refences of the different a/c parts like engines, gear, c.g., pilot eye pos'n,... but nothing referencing that coord-system with ground, except thru the gear pos'ns Two ways i can imagine jsbsim doing this: (imagine the gear, all with different lenghts) 1. it takes the AC_GEAR from UNDERCARRIAGE that would hit the ground first if the aircraft would be dropped down on the runway vertically. 2. it does 1. but for all three, but rotating/translating the 3d model so that all 3 gear of the 3d model will be on the ground like the real world (given that the 3d model and the fdm gear definitions correspond) Regards, Manuel Try it and see what happens:) I'm not trying to be flippant but that's often the quickest way of finding out and you're not going to break anything - either it'll work or it won't. If it works then you may have to fine tune it but that's normal, in my experience. LeeE ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Squared Terrain Textures any ideas how toimprove/change that?
My apologies, I can't answer this. Somehow it doesn't appear that the Flying Fortress screenshots look any more natural than ours. The shots seem to have a sort of oil painting look to them. Not to say that we couldn't improve ground detail! Can you tell us more about what we are looking at? Is shot #2 just a texture (with static shadows) or is it 3D models/scene with shadows that move with the time of day. How much total area is covered with that level of detail? The sky is fairly unremarkable compared to ours. But the ground lighting is really neat. I wonder if we could somehow come up with a scheme to mirror a grey alpha shadow version of the cloud textures just above the ground polys to get something similar. Best, Jim [EMAIL PROTECTED] said: In Flightgear the Terrain is looking like a carpet with squared textures this looks IMO relative unnatural. Like in this Screenshot: http://www.flightgear.org/images/crop-variety.jpg Now i want to ask what solutions are available to change this, any ideas? For example when i take a look at screenshots of other flight simulations like the Game Flying Fortress 2 the terrain looks relative natural, because you can't see hard edges, borders, shapes or lines. The changeover from one terrain type to another is fluxionary, that makes the terrain look very natural. Do you have any ideas how they made this? And how hard whould it be to implement something similar into flightgear? Here are some example screenshot of Flying Fortess 2 for comparisson: http://www.cdmag.com/articles/027/189/shot2.html http://www.cdmag.com/articles/025/071/shot1.html http://www.cdmag.com/articles/025/071/shot5.html ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Code Walkthrough
Hello, I have decided to try something simpler than attacking the problem of the plane flipping over, so I thaught I would try adding functionality to quickly change the latitude/longitude and optionally altitude. I realize all of these things are simple to change through the property browser, but it may be a bit more user friendly to change them from a menue. I have that basic functionality working but I would like to send the contents of the altitude box to a function that would determine whether the box is empty or not. If the box is blank, then the intent is that the plane would be warped to that lat/lon at ground level for that lat/lon. It appears that if the above were possable, then I would have to write a command and put it in fg_commands in the Main source dir, is this correct? By the way, thank you Jim for answering my previous posting. The next feature that I think would be nice is the ability to change aircraft while the program is running, if that is possable. Would either of these simple features warrent including in the Flightgear distro? John Pitz ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: new scenery for w130n30 using 1 arcsec data
Frederic Bouvier [EMAIL PROTECTED] writes: It looks a lot better, and the polygon count is not so huge. To correct building height, get this file : http://perso.wanadoo.fr/frbouvi/flightsim/942066.stg and put it in w123n37. Or use fgsd. thanks. i copied the file and the buildings are positioned as they should be. Download would be easier if there was a tarball ;-) this is a link to the actual directory where fgfs keeps the scenery. just use 'wget -r' to get the whole directory recursively. btw, i am in the process regenerating the scenery using the same 1 arcsec data for w080n40. hopefully canadian data will also be included. --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
Re: [Flightgear-devel] Squared Terrain Textures any ideas how toimprove/change that?
Am Donnerstag, 28. August 2003 21:34 schrieb Jim Wilson: My apologies, I can't answer this. Somehow it doesn't appear that the Flying Fortress screenshots look any more natural than ours. The shots seem to have a sort of oil painting look to them. It is the shape of the textures that look more natural. In flighgear you have allways squares, in FF2 you have random shapes build of very small textures. I have the full version of FF2 and took a closer look on the ground detail of the game today. My conclusion is the following: They use very small squares of textures (about 4m * 4m large) and create one big one (100m*50m) of them but with a random shape. For example they have a 4m*4m cornfield texture, then they glue 20-30 of them togehter and create a large cornfeld. The large cornfeld now has a random shape it is not a square with 90 degree angles like in flightgear. After that they create another big field, also made of small textures but with another color or terrain (darker corn field, forrest, plaines or something else). Then they glue the two large cornfelds together. But on the place where the large cornfelds are glued together the edge they use a third terrain texture like a hedge/covey and put it on top of the edge. This third texture could also be a street or country road. I try to descibe it with ASCII charactes: Let's assume our first corn field texture is X (where X is the small 4m*4m texture) and our second one ( a wheat texture) is O then it looks something like this: XXOOO X OO XXXOOO XXO XOO Now they put on top of the edges a third texture like a street H with loos trees W (the 4. texture) : XXHOOO XH HWOO XXXHOOO XXWHO XWHOO After that the terrain looks natural because it's hard to find the hard syntethic looking edges between different kindes of textures which are typical for computer games. In flightgeare we have one large texture for a typical terrain type and it is in most cases especially on flat land a square with 90 degree angles: - - - - - The large texture may be for itself look ok or photorealisitc, but that doesn't look natural when you glue them together. And it looks even worse when the shape is a square with 90 degree angles that looks blocky. For creating the large corn fields in FF2 they make a lot of use of Mip Mapping for that to keep the framerate high. But i don't know on what principals they create those different shapes and different sizes of the large cornfields (and other fields). I agree with the oil painting, i don't know what's responsible for that (maybe they use bump mapping for that) but it is not the thing i wanted to show (explain) or have in flightgear. I only meant the randomly shaped landscape. Not to say that we couldn't improve ground detail! Can you tell us more about what we are looking at? Is shot #2 just a texture (with static shadows) or is it 3D models/scene with shadows that move with the time of day. How much total area is covered with that level of detail? You can see the shadows of the hedges or trees only when you fly very close over the ground. I assume they put a grey alpha texture next to the small hedge or tree textures just in time when you fly close over them to get this effect. So it is probably created only once in the moment when you get closer to the ground and so it is probably a kind of semi-static shadow. Keep in mind that you are flying, so I don't think they recalulate their position based on the sun position in every frame. But maybe they change the postition every 30 minutes, that shouldn't stand out. The sky is fairly unremarkable compared to ours. But the ground lighting is really neat. I wonder if we could somehow come up with a scheme to mirror a grey alpha shadow version of the cloud textures just above the ground polys to get something similar. I like that idea, maybe it is worth to try that. Best Regards, Oliver C. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
