Re: [Flightgear-devel] Some thoughts and ideas (LONG)
Hi, They have mentioned FlightGear as a candidate simply for the reason that it can be modified and changed to do whatever we want it to do. No restrictions on functionality. Yes, that's the advantage of open source. BTW, I have lately heard people call Targetware and MSFS/CFS open source because you can mod it, but of course that is very different to having the program source in the open. We need at least one properly/accurately modeled aircraft that we can show off. I'm talking nice visually (high poly count) and with an accurate flight model. Regarding the visuals, the easiest way is use an existing model and convert it. We need some nice development tools. In particular a full blown scenery editor that one can use to lay down 3D objects (trees/buildings), taxiways, aprons, roads, rivers, etc. If it's done in OpenGL then you can make it WYSIWYG. I did that a long time ago, before the LinuxTag trade fair. It is in PPE (the open source modelle PrettyPolyEdit, which sits on top of the library PLIB, like FGFS does). You look at the terrain from above. Of course you can rotate and move the camera. You then simple click the mouse onto the spot you want to add the model. You then have three dials to edit the pitch rolll and yaw if possible. For example, with taildraggers converted from MSFS, they are normally horizontal and you have to rotate in pitch until all wheels are on the ground. I am not sure anyone used this apart from me. This should still work, but it uses ascii terra gear scenery. I do not know the status on that. Is there a converter? What 3D formats and apps are used? See the bottom of this page for file formats: http://plib.sourceforge.net/ssg/non_class.html In the big table, look for formats we can load. Bye bye, Wolfram. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Some thoughts and ideas (LONG)
We need some nice development tools. In particular a full blown scenery editor that one can use to lay down 3D objects (trees/buildings), taxiways, aprons, roads, rivers, etc. If it's done in OpenGL then you can make it WYSIWYG. Look at http://fgsd.sourceforge.net -Fred ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Some thoughts and ideas (LONG)
Paul Surgeon writes: On Friday, 7 November 2003 02:58, David Megginson wrote: What release is it? The 172 changed a release or two ago. 0.9.3 - The one with the nice ready to run Windows installer. It's the 172 with the 3D cockpit and nice yellow tints on the wings. :) I would run it under Linux except that last time I couldn't maximize the screen without the FPS dropping to 1. If you are running low on video ram, enlarging the window can kill your performance (due to needing to reallocate and shuffle ram.) You can try starting with the window maximized and see if that works. Regards, Curt. -- Curtis Olson HumanFIRST Program FlightGear Project Twin Citiescurt 'at' me.umn.edu curt 'at' flightgear.org Minnesota http://www.flightgear.org/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Some thoughts and ideas (LONG)
Jim Wilson writes: Recently I aquired a copy of the latest MSFS. It's the first I've bought since MS took it over from SubLogic! (No I haven't gone crazy and joined the other side. It was USED and very cheap so my rational was it would not put money directly into the pockets of the microsoft billionaires club :-)). After spending a two or three hours with it my impression is that there are two ways to value eye candy...quality and quantity. The MS has a lot more quantity because of all the bodies they threw at it. We're there, or better, with the quality. For those inteterested in the appearance of the scene and the aircraft, all they need to do is go to work and build some models. Yes, FlightGear's engine is pretty flexible and can do a lot of nice things. The biggest thing we are lacking now is content (i.e. aircraft and scenery features) that utilizes all the features that FlightGear provides. BTW I can also say now that I understand now how much of a threat the FLY! series was to the microsoft product. Too bad it failed...but it looks like FlightGear is destined to someday be a major influence in the popular arena. I have no desire to put a bunch of fine MS employees out of work, but hopefully FlightGear can be a big influence in the field and drive everyone to do better and better. Regards, Curt. -- Curtis Olson HumanFIRST Program FlightGear Project Twin Citiescurt 'at' me.umn.edu curt 'at' flightgear.org Minnesota http://www.flightgear.org/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Some thoughts and ideas (LONG)
Norman Vine writes: Paul Surgeon writes: I hope FG doesn't tie textures to every single polygon in the scenery files. (faster rendering because the calculations don't have to be done at render time but larger scenery files because of all the texture co-ords tied to the vertices) This is exactly what Flightgear does for several reasons but Don't let this discourage you because I can't think of any thing in the code that would really have to change outside of the terrain parser and the low level tile class and these would have to be changed anyway to support any change in the terrain structure. I am looking forward to seeing another mechanism for a global seamless terrain rendering on a dimpled ellipsoid :-) Sure, anyone is welcome to build an alternate scenery rendering subsystem. There are a zillion different approaches out there each with it's own strengths and weaknesses. FlightGear impliments just one approach right now. Regards, Curt. -- Curtis Olson HumanFIRST Program FlightGear Project Twin Citiescurt 'at' me.umn.edu curt 'at' flightgear.org Minnesota http://www.flightgear.org/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Some thoughts and ideas (LONG)
Curtis L. Olson writes: If you are running low on video ram, enlarging the window can kill your performance (due to needing to reallocate and shuffle ram.) You can try starting with the window maximized and see if that works. There's also a problem with the NVIDIA drivers on some systems, just generally. For example, if I start with a very small window (say, 320x240x16) and shrink it by a few pixels, that's it for hardware rendering -- we're down to a frame every 30 seconds or so; on the other hand, I can start at 1600x1200x160 and get about 18 fps. I've had that problem for a year and a half, ever since I started using a notebook with a Geforce2Go. I don't have the problem with other 3D programs like the plib demos, only with FlightGear. We must be enabling something that triggers the driver or hardware bug. All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Some thoughts and ideas (LONG)
Paul Surgeon writes: Well what do you define as eye candy? If people don't want eye candy then why do we have ground textures in FlightGear? They are just wasting framerates. I'm not taking a stand in the eye-candy-vs-simulator debate, but this particular statement is not true. Textures (and auto-placed objects like trees) are critical for simulating VFR flight, since they give you a reference point for judging altitude, distance, and ground speed. The different texture types also help a bit with pilotage, particularly the water and urban textures. I just tried this and it does go to VNE. In my experience (a few hundred hours PPL, mainly C172 and C152), the C172 is modelled very accurately. Did the OP chase the VSI? It has a several-second lag, esp when changing attitude quickly (again, this is modelled accurately), which could account for him not hitting VNE. I held a 1500 fpm decent for 3 minutes from 6000 ft at full throttle. It seems that I have an old model although I thought 0.9.3 was a recent build. How did you start FlightGear? Were you using the default 172 that comes up when you start FlightGear with no command-line options? You can end up with an old model if you use --aircraft=172r-3d All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Some thoughts and ideas (LONG)
On Friday 07 November 2003 18:23, David Megginson wrote: Paul Surgeon writes: Well what do you define as eye candy? If people don't want eye candy then why do we have ground textures in FlightGear? They are just wasting framerates. I'm not taking a stand in the eye-candy-vs-simulator debate, but this particular statement is not true. Textures (and auto-placed objects like trees) are critical for simulating VFR flight, since they give you a reference point for judging altitude, distance, and ground speed. The different texture types also help a bit with pilotage, particularly the water and urban textures. I just tried this and it does go to VNE. In my experience (a few hundred hours PPL, mainly C172 and C152), the C172 is modelled very accurately. Did the OP chase the VSI? It has a several-second lag, esp when changing attitude quickly (again, this is modelled accurately), which could account for him not hitting VNE. I held a 1500 fpm decent for 3 minutes from 6000 ft at full throttle. It seems that I have an old model although I thought 0.9.3 was a recent build. How did you start FlightGear? Were you using the default 172 that comes up when you start FlightGear with no command-line options? You can end up with an old model if you use --aircraft=172r-3d All the best, David I think an eye-candy vs. dynamics/procedureal accuracy debate is a bit pointless in the context of FlightGear. Ultimately, the trend for any simulator will be towards improvements in both areas and it's really more a question of who wants to work on what and when. I don't see FG as an 'employing' project where the developers/contributers are obliged to do particular things or meet specific targets. it's fine if people want to have wish-lists or suggest ideas but no-one is obliged to do anything. If someone wants to concentrate on dynamics or procedureal accuracy that's what they'll work on and similarly, if someone else wants to work on 'eye-candy' improvements then that's what they'll do. While FG appears, to me, to be a co-ordinated project, I wouldn't describe it as a 'managed' project, as the people doing the work haven't put themselves into a 'managed' position where they can be told what to do. It seems to me, therefore, that debating eye-candy vs. dynamic/procedureal accuracy is a waste of time, and possibly harmful because the people who want to work in the area expounded by the side that loses the debate aren't suddenly going to start working in the area expounded by the side that wins it. They're more likely to start working for a different project where they feel that what they want to work on will be welcome. I welcome all improvements to FG. LeeE ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Some thoughts and ideas (LONG)
Paul Surgeon writes I would love to have a poll on this topic to see how many people would like some eye-candy and those that don't care much about it. If no one want's any visual improvements in FlightGear then I better not waste my time. While eye candy might be nice I think the main effort would be better used to write as tight a code as we can. Can I write code?. Not a line of it. I am now getting the same frame rates in FG that I was getting in FS2K2 and that was with full AI and about 30 A/C at the airport some of which were quite detailed models. If you want to bring FG to a grinding halt try putting 30 static A/C around KSFO and see what your frame rates are.Unless KSFO is much smaller than I think it is(and I live half way around the world from KSFO)then I would think that 30 A/C would fit on one terminal finger. If you ask me if I would rather have cars moving around or a more realistic taxiway texture system including airfield signage. Or plenty of static A/C and buildings at the expense of some good aircraft panels. Then I am afraid I would pick the latter in both in both cases. If you want eyecandy them the process already exists just take any of the 3D models and put them into the scenery.You can even make your own models of anything you like and put them in your scenery.But it won't be long before you realise that at its current state of development FG will choke on the extra content. So while I am all for eyecandy I would think that energies would be but put to getting the best performance from the sim with a good level of detail. Lets do some crawling before we try the walk or run. Just my opinion Cheers Innis The Mad Aussi Paul _ Hot chart ringtones and polyphonics. Go to http://ninemsn.com.au/mobilemania/default.asp ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Some thoughts and ideas (LONG)
Well said Lee Now why didn't I think of that.LOL Cheers Innis The Mad Aussi Lee Elliott writes I think an eye-candy vs. dynamics/procedureal accuracy debate is a bit pointless in the context of FlightGear. Ultimately, the trend for any simulator will be towards improvements in both areas and it's really more a question of who wants to work on what and when. I don't see FG as an 'employing' project where the developers/contributers are obliged to do particular things or meet specific targets. it's fine if people want to have wish-lists or suggest ideas but no-one is obliged to do anything. If someone wants to concentrate on dynamics or procedureal accuracy that's what they'll work on and similarly, if someone else wants to work on 'eye-candy' improvements then that's what they'll do. While FG appears, to me, to be a co-ordinated project, I wouldn't describe it as a 'managed' project, as the people doing the work haven't put themselves into a 'managed' position where they can be told what to do. It seems to me, therefore, that debating eye-candy vs. dynamic/procedureal accuracy is a waste of time, and possibly harmful because the people who want to work in the area expounded by the side that loses the debate aren't suddenly going to start working in the area expounded by the side that wins it. They're more likely to start working for a different project where they feel that what they want to work on will be welcome. I welcome all improvements to FG. I secound that motion. LeeE _ Hot chart ringtones and polyphonics. Go to http://ninemsn.com.au/mobilemania/default.asp ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Some thoughts and ideas (LONG)
Well some areas of FG could be improved a lot with little effect on frame rates. For instance a nice big library of tileable textures and a scenery builder that knows how to build tiled scenery based on land class data. i.e. The type of thing you see in FS2002/04 where the textures seem to blend together and you can't see where one polygon starts and another stops. Fly2 also used this principle and it really looked nice and ran on my system better than FG does at the moment. That would require no changes to FG and would not impact frame rates very much unless your graphics card doesn't have enough memory for all the textures. In which case you can just carry on using default scenery. I'm planning on doing this and seeing how well it works. If it's a success I'll let you all know about it. However I do agree with you about optimizing FG. It has scenery comparable with FS98 but runs about 1000% slower. I'm sure that some of that has to do with the processing that goes into rendering the nice gauges,etc but there probably is plenty of room for tweaking the terrain rendering code amoungst other areas. I haven't noticed any scenery popping like I see in FS2002 which almost makes me wonder if there are any LOD algorithms in FG. Paul On Saturday, 8 November 2003 16:31, Innis Cunningham wrote: While eye candy might be nice I think the main effort would be better used to write as tight a code as we can. Can I write code?. Not a line of it. I am now getting the same frame rates in FG that I was getting in FS2K2 and that was with full AI and about 30 A/C at the airport some of which were quite detailed models. If you want to bring FG to a grinding halt try putting 30 static A/C around KSFO and see what your frame rates are.Unless KSFO is much smaller than I think it is(and I live half way around the world from KSFO)then I would think that 30 A/C would fit on one terminal finger. If you ask me if I would rather have cars moving around or a more realistic taxiway texture system including airfield signage. Or plenty of static A/C and buildings at the expense of some good aircraft panels. Then I am afraid I would pick the latter in both in both cases. If you want eyecandy them the process already exists just take any of the 3D models and put them into the scenery.You can even make your own models of anything you like and put them in your scenery.But it won't be long before you realise that at its current state of development FG will choke on the extra content. So while I am all for eyecandy I would think that energies would be but put to getting the best performance from the sim with a good level of detail. Lets do some crawling before we try the walk or run. Just my opinion Cheers Innis The Mad Aussi ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Some thoughts and ideas (LONG)
Paul Surgeon wrote: However I do agree with you about optimizing FG. It has scenery comparable with FS98 but runs about 1000% slower. I'm sure that some of that has to do with the processing that goes into rendering the nice gauges,etc but there probably is plenty of room for tweaking the terrain rendering code amoungst other areas. I haven't noticed any scenery popping like I see in FS2002 which almost makes me wonder if there are any LOD algorithms in FG. Nope, no *dynamic* LOD algorithm is present at the moment. It's all just a very effective irregular terrain mesh at the moment. Dynamic LOD would probably improve the framerate and (as someone mentioned a few weeks back) creating larger vertex arrays in TerraGear would probably improve framerate much because the static LOD causes a lot of CPU cycles. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Some thoughts and ideas (LONG)
Which means that as soon as someone adds a nice medium to high res elevation mesh FG is going to die. Either that or TerraGear is going to have to throw away a lot of nice detail when building the scenery. Well let's take it as it comes. Create the problem and then solve it. :) Paul On Saturday, 8 November 2003 17:08, Erik Hofman wrote: Paul Surgeon wrote: However I do agree with you about optimizing FG. It has scenery comparable with FS98 but runs about 1000% slower. I'm sure that some of that has to do with the processing that goes into rendering the nice gauges,etc but there probably is plenty of room for tweaking the terrain rendering code amoungst other areas. I haven't noticed any scenery popping like I see in FS2002 which almost makes me wonder if there are any LOD algorithms in FG. Nope, no *dynamic* LOD algorithm is present at the moment. It's all just a very effective irregular terrain mesh at the moment. Dynamic LOD would probably improve the framerate and (as someone mentioned a few weeks back) creating larger vertex arrays in TerraGear would probably improve framerate much because the static LOD causes a lot of CPU cycles. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Some thoughts and ideas (LONG)
Paul Surgeon writes: Well some areas of FG could be improved a lot with little effect on frame rates. For instance a nice big library of tileable textures and a scenery builder that knows how to build tiled scenery based on land class data. That is basically what is done now i.e. The type of thing you see in FS2002/04 where the textures seem to blend together and you can't see where one polygon starts and another stops. Fly2 also used this principle and it really looked nice and ran on my system better than FG does at the moment. That would require no changes to FG and would not impact frame rates very much unless your graphics card doesn't have enough memory for all the textures. In which case you can just carry on using default scenery. Actually FGFS is often FILL limited, cloud layers and the panel contribute a lot towards this as they are basically all overdraw I'm planning on doing this and seeing how well it works. If it's a success I'll let you all know about it. IMO the biggest improvement that could be made to the FGFS Scenery is to implement imposter objects. These could then be used for distant scenery and much of the sky. FWIW AFAIK this is the secret trick that MSFS uses to get the frame rates that it does. Cheers Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Some thoughts and ideas (LONG)
On Saturday, 8 November 2003 18:13, Norman Vine wrote: Paul Surgeon writes: For instance a nice big library of tileable textures and a scenery builder that knows how to build tiled scenery based on land class data. That is basically what is done now Yes but at the moment there is no blending of textures between different texture types (land class types) This is because there are no intermediate textures in FG yet. For instance : If you have a grass texture on the left and a dirt texture on the right there should be a texture in between that blends these two types together. A texture in between that matches the grass on the left and the dirt on the right and blends them together. For a sim that only uses two textures you would need at least 12 different versions of the intermediate texture. 1 for grass top dirt bottom 1 for dirt top grass bottom 1 for grass left dirt right 1 for dirt left grass right 4 for grass corners 4 for dirt corners Fly and MSFS do their ground textures like this. It requires large numbers of intermediate textures but it can be done and it looks very natural. For 12 different land class types you would only need 1728 intermediate textures. ;) This is what I want to do in FG once I figure out the scenery file format and how FG actually drapes the textures over the terrain. I hope FG doesn't tie textures to every single polygon in the scenery files. (faster rendering because the calculations don't have to be done at render time but larger scenery files because of all the texture co-ords tied to the vertices) Paul ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Some thoughts and ideas (LONG)
I forgot to add: There is another way of blending textures but it requires using alpha maps which would mean a change to the rendering code. It's a better way of doing it but there will be a performance penalty if an extra rendering pass needs to be done. Paul On Saturday, 8 November 2003 18:40, Paul Surgeon wrote: On Saturday, 8 November 2003 18:13, Norman Vine wrote: Paul Surgeon writes: For instance a nice big library of tileable textures and a scenery builder that knows how to build tiled scenery based on land class data. That is basically what is done now Yes but at the moment there is no blending of textures between different texture types (land class types) This is because there are no intermediate textures in FG yet. For instance : If you have a grass texture on the left and a dirt texture on the right there should be a texture in between that blends these two types together. A texture in between that matches the grass on the left and the dirt on the right and blends them together. For a sim that only uses two textures you would need at least 12 different versions of the intermediate texture. 1 for grass top dirt bottom 1 for dirt top grass bottom 1 for grass left dirt right 1 for dirt left grass right 4 for grass corners 4 for dirt corners Fly and MSFS do their ground textures like this. It requires large numbers of intermediate textures but it can be done and it looks very natural. For 12 different land class types you would only need 1728 intermediate textures. ;) This is what I want to do in FG once I figure out the scenery file format and how FG actually drapes the textures over the terrain. I hope FG doesn't tie textures to every single polygon in the scenery files. (faster rendering because the calculations don't have to be done at render time but larger scenery files because of all the texture co-ords tied to the vertices) Paul ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Some thoughts and ideas (LONG)
Paul Surgeon writes: I hope FG doesn't tie textures to every single polygon in the scenery files. (faster rendering because the calculations don't have to be done at render time but larger scenery files because of all the texture co-ords tied to the vertices) This is exactly what Flightgear does for several reasons but Don't let this discourage you because I can't think of any thing in the code that would really have to change outside of the terrain parser and the low level tile class and these would have to be changed anyway to support any change in the terrain structure. I am looking forward to seeing another mechanism for a global seamless terrain rendering on a dimpled ellipsoid :-) Cheers Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Some thoughts and ideas (LONG)
On Saturday, 8 November 2003 21:27, Norman Vine wrote: This is exactly what Flightgear does for several reasons but Don't let this discourage you because I can't think of any thing in the code that would really have to change outside of the terrain parser and the low level tile class and these would have to be changed anyway to support any change in the terrain structure. That's ok - it just makes the scenery building process a bit more complex and the scenery files a bit bigger but the big advantage is a less complex and faster rendering process. Anyway 80GB disks are cheap nowdays ... It also allows one big advantage over other sims and that is the ability to change the scale of the textures so terrain features like cliffs don't have to look stretched like they do in most other sims. Of course the scenery generator will need to be intelligent enough to handle such cases. I am looking forward to seeing another mechanism for a global seamless terrain rendering on a dimpled ellipsoid :-) I don't plan on changing the way FG does the rendering - only the way the scenery is built and the textures that are used. As long as I can specify the shape size and positions of polygons I'm good. I still have to get around to seeing how the tiling works. BTW : I've started documenting the scenery file layout. What format is prefered and where can I place/send it once I'm done? Paul ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Some thoughts and ideas (LONG)
Lee Elliott [EMAIL PROTECTED] said: snip It seems to me, therefore, that debating eye-candy vs. dynamic/procedureal accuracy is a waste of time, and possibly harmful because the people who want to work in the area expounded by the side that loses the debate aren't suddenly going to start working in the area expounded by the side that wins it. They're more likely to start working for a different project where they feel that what they want to work on will be welcome. I welcome all improvements to FG. I'll second that! Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Some thoughts and ideas (LONG)
Innis Cunningham [EMAIL PROTECTED] said: I welcome all improvements to FG. I secound that motion. Ah I was too late ;-) Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Some thoughts and ideas (LONG)
David Megginson [EMAIL PROTECTED] said: Paul Surgeon writes: 0.9.3 - The one with the nice ready to run Windows installer. It's the 172 with the 3D cockpit and nice yellow tints on the wings. :) That's pretty ancient. Our current 172 looks a fair bit better. U... that release is less than two weeks old ;-). There are a couple of 172's and they are fairly low poly models. Some work is being done in the 3D engine to improve rendering, which might be part of the complaint. Anyway, IMHO there is nothing wrong with low poly models, especially ones as well done as these. This doesn't mean that a high poly version would not be welcome as an alternative if you want to build one Paul. It'd be nice to have a full set of 3D instruments to go in it as well :-) Recently I aquired a copy of the latest MSFS. It's the first I've bought since MS took it over from SubLogic! (No I haven't gone crazy and joined the other side. It was USED and very cheap so my rational was it would not put money directly into the pockets of the microsoft billionaires club :-)). After spending a two or three hours with it my impression is that there are two ways to value eye candy...quality and quantity. The MS has a lot more quantity because of all the bodies they threw at it. We're there, or better, with the quality. For those inteterested in the appearance of the scene and the aircraft, all they need to do is go to work and build some models. BTW I can also say now that I understand now how much of a threat the FLY! series was to the microsoft product. Too bad it failed...but it looks like FlightGear is destined to someday be a major influence in the popular arena. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Some thoughts and ideas (LONG)
Jim Wilson writes: That's pretty ancient. Our current 172 looks a fair bit better. U... that release is less than two weeks old ;-). I'm losing track of release numbers, then, but the clunky 172 model with the yellow tint on wings has not been our default for a long time. Maybe he got it by specifying --aircraft=c172r-3d or something similar. All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Some thoughts and ideas (LONG)
On Friday, 7 November 2003 06:39, Nick Coleman wrote: As a counterpoint, I would like to request that this either not take priority, or that it be an option in the configure stage. I want fast framerates as the priority. For me, this is a _flight_ sim and I don't see the point of eyecandy. ( Personally, I was disappointed with FS2002 and much preferred the playability of FS98. Well what do you define as eye candy? If people don't want eye candy then why do we have ground textures in FlightGear? They are just wasting framerates. FS2002 devoted too much to eyecandy and was so obtuse in actually getting to the point where you were in the air and flying that I stopped using it. It took about five minutes of configuring various options before you could take off.) That's odd - once I had set up and saved a default flight it was just a matter of starting the sim and away I went. I disagree with this assessment. I think lower spec machines should be able to run a _flight_ sim and shouldn't be excluded just for the sake of eyecandy. I don't for a minute think that lower speced machines should be excluded but it would be nice to cater for higher end machines as well. This is where one can have low poly models and configurable options to remove eye candy just like other sims have. For instance a slider that sets the amount of 3D objects you want to be able to see from zero to max with several levels in between. I just tried this and it does go to VNE. In my experience (a few hundred hours PPL, mainly C172 and C152), the C172 is modelled very accurately. Did the OP chase the VSI? It has a several-second lag, esp when changing attitude quickly (again, this is modelled accurately), which could account for him not hitting VNE. I held a 1500 fpm decent for 3 minutes from 6000 ft at full throttle. It seems that I have an old model although I thought 0.9.3 was a recent build. I'm not trying to rain on the OP's parade; I think he has some good ideas. It's just that I would prefer to see development take priority in the fields I am interested in, naturally enough. Well my point is that I'll do the development in the eye candy department. It does not have to detract from anyone elses time. :) I would love to have a poll on this topic to see how many people would like some eye-candy and those that don't care much about it. If no one want's any visual improvements in FlightGear then I better not waste my time. Thanks for your input though - I do understand where you are coming from even if I don't quite understand your reasons. Paul ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Some thoughts and ideas (LONG)
David Megginson wrote: Jim Wilson writes: That's pretty ancient. Our current 172 looks a fair bit better. U... that release is less than two weeks old ;-). I'm losing track of release numbers, then, but the clunky 172 model with the yellow tint on wings has not been our default for a long time. Maybe he got it by specifying --aircraft=c172r-3d or something similar. It might be caused by the fact that he is probably using the configuration for slower machines which I posted last week, which is not a good test case because it also reduced the fmd update to 60 Hz. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Some thoughts and ideas (LONG)
Paul Surgeon wrote: On Friday, 7 November 2003 06:39, Nick Coleman wrote: As a counterpoint, I would like to request that this either not take priority, or that it be an option in the configure stage. I want fast framerates as the priority. For me, this is a _flight_ sim and I don't see the point of eyecandy. ( Personally, I was disappointed with FS2002 and much preferred the playability of FS98. Well what do you define as eye candy? If people don't want eye candy then why do we have ground textures in FlightGear? They are just wasting framerates. IMHO there are two kinds of eye candy. The ones that are necessary for learning (snow/rain, fog) and the once that don't add anything but nice views (dust clouds on touchdown and such). So far I've mostly concentrated on the first type by adding better textures and sunset/sunrise effects. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Some thoughts and ideas (LONG)
Bring on the eye candy :) and a good config gui to control how much candy you eat (along with everything else that a config gui should do -- joystick calibration, screen resolution, sounds and sound volume, load/save config) I personally have a problem with relying on a seperate project to create the config gui for FG, as there will always be lag from when FG releases new features until the gui catches up -- there needs to be a startup gui included that gets updated right along with each new feature -- nothing fancy, just enough to control all the features. Re: priority on fast frame rates -- I've always had a problem with the idea of frame rates faster than the display refresh speed - I've seen plenty of Quake III benchmarks that claim 150-300 fps, which technically is impressive, but as far as actual usage, seems pretty useless on a display that only updates 80 fps at best. Get FG up around 60-80 fps (on a 2ghz machine + GeForce2/64mb or better) with most if not all the eye candy options turned on, and I'll be very happy. - Original Message - From: Paul Surgeon [EMAIL PROTECTED] To: FlightGear developers discussions [EMAIL PROTECTED] Sent: Friday, November 07, 2003 4:31 AM Subject: Re: [Flightgear-devel] Some thoughts and ideas (LONG) On Friday, 7 November 2003 06:39, Nick Coleman wrote: As a counterpoint, I would like to request that this either not take priority, or that it be an option in the configure stage. I want fast framerates as the priority. For me, this is a _flight_ sim and I don't see the point of eyecandy. ( Personally, I was disappointed with FS2002 and much preferred the playability of FS98. Well what do you define as eye candy? If people don't want eye candy then why do we have ground textures in FlightGear? They are just wasting framerates. FS2002 devoted too much to eyecandy and was so obtuse in actually getting to the point where you were in the air and flying that I stopped using it. It took about five minutes of configuring various options before you could take off.) That's odd - once I had set up and saved a default flight it was just a matter of starting the sim and away I went. I disagree with this assessment. I think lower spec machines should be able to run a _flight_ sim and shouldn't be excluded just for the sake of eyecandy. I don't for a minute think that lower speced machines should be excluded but it would be nice to cater for higher end machines as well. This is where one can have low poly models and configurable options to remove eye candy just like other sims have. For instance a slider that sets the amount of 3D objects you want to be able to see from zero to max with several levels in between. I just tried this and it does go to VNE. In my experience (a few hundred hours PPL, mainly C172 and C152), the C172 is modelled very accurately. Did the OP chase the VSI? It has a several-second lag, esp when changing attitude quickly (again, this is modelled accurately), which could account for him not hitting VNE. I held a 1500 fpm decent for 3 minutes from 6000 ft at full throttle. It seems that I have an old model although I thought 0.9.3 was a recent build. I'm not trying to rain on the OP's parade; I think he has some good ideas. It's just that I would prefer to see development take priority in the fields I am interested in, naturally enough. Well my point is that I'll do the development in the eye candy department. It does not have to detract from anyone elses time. :) I would love to have a poll on this topic to see how many people would like some eye-candy and those that don't care much about it. If no one want's any visual improvements in FlightGear then I better not waste my time. Thanks for your input though - I do understand where you are coming from even if I don't quite understand your reasons. Paul ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Some thoughts and ideas (LONG)
Paul Surgeon [EMAIL PROTECTED] said: I would love to have a poll on this topic to see how many people would like some eye-candy and those that don't care much about it. If no one want's any visual improvements in FlightGear then I better not waste my time. There are several people working on this stuff and more is certainly welcome. If you keep looking I think you'll find some pretty amazing visual work already in FlightGear. Have you headed north from the default runway yet (toward downtown)? BTW if you've got talent, be it in modeling or coding, it is hard for me to imagine that you won't get an enthusiastic response from at least some of the users. There will always be a wide range of interests here and I think flightgear provides the flexibility to satisfy many. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Some thoughts and ideas (LONG)
- Original Message - From: Jim Wilson [EMAIL PROTECTED] There are several people working on this stuff and more is certainly welcome. If you keep looking I think you'll find some pretty amazing visual work already in FlightGear. Have you headed north from the default runway yet (toward downtown)? Ok -- try this idea on for size -- we've already heard mention of handling different periods of time re: aircraft capabilities, extend that idea to terrain modeling -- i.e. you could have chicago details for each decade since 1930, have the scenario system decide which specific terrain overlay to apply to a region -- I'm not suggesting that there be an intensive effort on anyones part to create a broad range of overlays, just that the ability be there so that scenario designers can select existing overlays, or create them using an overlay editor BTW if you've got talent, be it in modeling or coding, it is hard for me to imagine that you won't get an enthusiastic response from at least some of the users. There will always be a wide range of interests here and I think flightgear provides the flexibility to satisfy many. Hehehe -- what gets me is the stay out of my sandbox crowd -- would rather find ways to work together :) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Some thoughts and ideas (LONG)
Paul Surgeon writes: On Friday, 7 November 2003 06:39, Nick Coleman wrote: I disagree with this assessment. I think lower spec machines should be able to run a _flight_ sim and shouldn't be excluded just for the sake of eyecandy. I don't for a minute think that lower speced machines should be excluded but it would be nice to cater for higher end machines as well. This is where one can have low poly models and configurable options to remove eye candy just like other sims have. For instance a slider that sets the amount of 3D objects you want to be able to see from zero to max with several levels in between. I see no conflict at all between eye candy and frame rates as long as it's all user configurable. I would love to have a poll on this topic to see how many people would like some eye-candy and those that don't care much about it. Ultimately, the only votes that really count come with patches attached :-) If no one want's any visual improvements in FlightGear then I better not waste my time. Believe me, any visual improvements you make would/will be much appreciated, just as the work of Fred Bouvier, Erik Hofman, Lee Elliot, Jim Wilson and many others in the visual department has been and is much appreciated. Personally I agree with Jim's comment that the main area we suffer in currently is quantity - the single biggest eye candy improvement that could be made now that downtown LA and the Bay bridges have been/are being done would be to populate the World's (or at least the Bay area's) airports with buildings and the odd static. So far KSFO is the only one with anything. And with a .za address, you might like to dig out FALA's runways from their trench ;-)) Cheers - Dave ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Some thoughts and ideas (LONG)
On Saturday, 8 November 2003 02:08, David Luff wrote: And with a .za address, you might like to dig out FALA's runways from their trench ;-)) Haha! Not only FALA but FAJS and many others too. I found the approaches rather exciting although not very realistic. :) Paul ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Some thoughts and ideas (LONG)
Nick Coleman wrote: On Fri, 7 Nov 2003 11:46 am, [EMAIL PROTECTED] wrote: Preface == I would like to see the sim become more friendly to casual users especially on the eye candy side of things. This does not need to detract from the scientific/academic nature of FlightGear - you guys can carry on with the great work. My reason for this is that a lot of people who play with sims can also develop addons but there needs to be an incentive to get them involved and screenshots say more than a thousand words can. As a counterpoint, I would like to request that this either not take priority, or that it be an option in the configure stage. I want fast framerates as the priority. For me, this is a _flight_ sim and I don't see the point of eyecandy. ( Personally, I was disappointed with FS2002 and much preferred the playability of FS98. FS2002 devoted too much to eyecandy and was so obtuse in actually getting to the point where you were in the air and flying that I stopped using it. It took about five minutes of configuring various options before you could take off.) Yes, I agree as well! IMO we should make FG as CPU friendly as possible and should maintain the ultra-realism as a primary goal. Ground trees, super detailed objects and 3d clouds should always be optional if they eat more than 20% FPS altogether. - Matevz ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Some thoughts and ideas (LONG)
On Sat, 8 Nov 2003 09:30 am, [EMAIL PROTECTED] wrote: Message: 3 Date: Fri, 7 Nov 2003 15:31:29 -0500 From: John Barrett [EMAIL PROTECTED] Subject: Re: [Flightgear-devel] Some thoughts and ideas (LONG) To: FlightGear developers discussions [EMAIL PROTECTED] Re: priority on fast frame rates -- I've always had a problem with the idea of frame rates faster than the display refresh speed - I've seen plenty of Quake III benchmarks that claim 150-300 fps, which technically is impressive, but as far as actual usage, seems pretty useless on a display that only updates 80 fps at best. Get FG up around 60-80 fps (on a 2ghz machine + GeForce2/64mb or better) with most if not all the eye candy options turned on, and I'll be very happy. The quake engine uses framerates for its calculations, so faster is always better, even if the display can't use it. The fraggers always used to complain when someone else is jumping all around them 'cause their framerate was higher ;). As well, there is some modulo framerate that is optimal (125 from memory). I don't know how fgfs uses it, so can't comment. Sorry if my comments came out negative, I didn't mean them to be. I was just offering another viewpoint from someone who uses fgfs more for things like IFR nav practice, rather than zooming about shooting at things (not that there's anything wrong with that--Seinfeld). I totally agree that eyecandy should be able to be included, as long as it is a configurable option for those who don't want it, either in the make stage or in the startup stage. Nick ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Some thoughts and ideas (LONG)
On Saturday, 8 November 2003 01:05, Nick Coleman wrote: totally agree that eyecandy should be able to be included, as long as it is a configurable option for those who don't want it,either in the make stage or in the startup stage. What about in the menu system? Switch it off and it stays off for good without having to complicate build procedures or always having to launch with a string of I don't want that or that or that ... parameters. Paul ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Some thoughts and ideas (LONG)
Paul Surgeon wrote: On Saturday, 8 November 2003 01:05, Nick Coleman wrote: totally agree that eyecandy should be able to be included, as long as it is a configurable option for those who don't want it,either in the make stage or in the startup stage. What about in the menu system? Switch it off and it stays off for good without having to complicate build procedures or always having to launch with a string of "I don't want that or that or that ..." parameters. Paul Yes, that would be perfect. But IMO you should also be able to access *all* the possible options in menu via command line parameters as well. - Matevz ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Some thoughts and ideas (LONG)
Hi guys Intro == I've been watching the FlightGear project for the last 2-3 years and am interested in contributing to the project once I get a new video card. (TNT2 is just not cutting it) Flight Unlimited III is effectively dead and MSFS is continually dissapointing me because of the inability to get features added like proper support for vertical wind generation/modeling (themals, ridge, wave lift) Then there is the fact that I prefer using Linux and have done some C++ and OpenGL coding (terrain rendering with satellite image overlays) which was fun. I have several questions, suggestions and ideas so if you're in a hurry or the kids are screaming just hit delete. I've tried to be as brief and concise as I can be so please forgive me if I take up some of your development time. ;) Preface == I would like to see the sim become more friendly to casual users especially on the eye candy side of things. This does not need to detract from the scientific/academic nature of FlightGear - you guys can carry on with the great work. My reason for this is that a lot of people who play with sims can also develop addons but there needs to be an incentive to get them involved and screenshots say more than a thousand words can. For instance there are several very talented guys on the Avsim Flight Unlimited III forum and some of them are looking at moving onto another sim. They have mentioned FlightGear as a candidate simply for the reason that it can be modified and changed to do whatever we want it to do. No restrictions on functionality. If we can at least get them interested using some showcase material then FlightGear development can get a major boost. There are plenty such developers around in other places. Suggestions == Suggestion 1 The menu systems could do with some major enhancments. A nice menu system for picking airports and aircraft, joystick configuration and key mappings would go down well. Getting everything menu driven will help a lot. Most people hate playing in shells passing huge lists of arguments to get what they want. Suggestion 2 --- We need at least one properly/accurately modeled aircraft that we can show off. I'm talking nice visually (high poly count) and with an accurate flight model. Most people using recent commercial flightsims are running 1.5 GHz PCs with at least 64MB GeForce 4's so poly counts can be fairly high. BTW : I took the Cessna 172 for a flip and was dissapointed. The visual model is really rough - looks like it taxied into a brick wall to get into those funny shapes. At full throttle and a 1500 fpm decent it wouldn't go over 140 knots. In real life it would hit VNE very quickly. Suggestion 3 --- Some nice showcase scenery would also go down very well. A nice area with lots of trees and buildings and good ground textures. Suggestion 4 --- We need some nice development tools. In particular a full blown scenery editor that one can use to lay down 3D objects (trees/buildings), taxiways, aprons, roads, rivers, etc. If it's done in OpenGL then you can make it WYSIWYG. One way to do this is to incorporate a scenery edit mode into FlightGear like the one in FLY2. You pause the game and go into edit mode and can lay down trees and objects. Then hit unpause and fly around your creation. I personally think a seperate editor would be the answer since it won't interfere FlightGear development and one can add as many features as one likes. Questions == Question 1 Has there been any thought or development on auto generated scenery like that used in MSFS 2002/2004? i.e. Automatically generate trees and buildings based on land use data. The other alternative is to generate the 3D object positions when building the scenery packages. Flying over forests makes a world of difference when it comes to realism. Question 2 The site is a bit sparse with info about who is doing what. Has anyone writen a scenery editor yet? Question 3 What 3D formats and apps are used? I find Blender very powerful and of course it's open source and free which is great. Question 3 If I manage to get some nice high res DEM data available for a certain area how do I go about getting it built into the next release of FlightGear? Conclusion == By now you probably think that I'm an ungrateful idiot with a huge wish list. Fortunately that is not the case. Here is a list of
Re: [Flightgear-devel] Some thoughts and ideas (LONG)
On Fri, 07 Nov 2003 02:22:54 +0200 Paul Surgeon [EMAIL PROTECTED] wrote: The menu systems could do with some major enhancments. A nice menu system for picking airports and aircraft, joystick configuration and key mappings would go down well. Getting everything menu driven will help a lot. Most people hate playing in shells passing huge lists of arguments to get what they want. FG Launch Control http://sourceforge.net/projects/fgrun/ is a standalone GUI app that does some of what you describe. We need some nice development tools. In particular a full blown scenery editor that one can use to lay down 3D objects (trees/buildings), taxiways, aprons, roads, rivers, etc. If it's done in OpenGL then you can make it WYSIWYG. One way to do this is to incorporate a scenery edit mode into FlightGear like the one in FLY2. You pause the game and go into edit mode and can lay down trees and objects. Then hit unpause and fly around your creation. I personally think a seperate editor would be the answer since it won't interfere FlightGear development and one can add as many features as one likes. FG Scenery Designer http://sourceforge.net/projects/fgsd/ is another standalone app that lets you modify scenery and place objects. Cheers, Bernie ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Some thoughts and ideas (LONG)
Suggestion 2 --- We need at least one properly/accurately modeled aircraft that we can show off. I'm talking nice visually (high poly count) and with an accurate flight model. Most people using recent commercial flightsims are running 1.5 GHz PCs with at least 64MB GeForce 4's so poly counts can be fairly high. Well, I think the X-15 generally works pretty good, but I need to revisit it and finish off the things I've always meant to finish up. BTW : I took the Cessna 172 for a flip and was dissapointed. The At full throttle and a 1500 fpm decent it wouldn't go over 140 knots. In real life it would hit VNE very quickly. Interesting. Can you give more specifics of your test? This is theoretically one of our most detailed flight models. Maybe you've found a rough edge. Can you give the command line you used to start this up, and which version did you use? Thanks (and welcome)! Jon Berndt Coordinator, JSBSim Project (a Flight Dynamics Model used in FlightGear) www.jsbsim.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re: [Flightgear-devel] Some thoughts and ideas (LONG)
Paul Surgeon writes: BTW : I took the Cessna 172 for a flip and was dissapointed. The visual model is really rough - looks like it taxied into a brick wall to get into those funny shapes. What release is it? The 172 changed a release or two ago. At full throttle and a 1500 fpm decent it wouldn't go over 140 knots. In real life it would hit VNE very quickly. Is that true? I've never taken a 172 that fast in real life, but they are very draggy. In fact, when someone in a slick gets into a spiral, one of the recommended emergency procedures is to drop the gear (which will then have to be inspected before further flight). All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Some thoughts and ideas (LONG)
At full throttle and a 1500 fpm decent it wouldn't go over 140 knots. In real life it would hit VNE very quickly. Is that true? I've never taken a 172 that fast in real life, but they are very draggy. In fact, when someone in a slick gets into a spiral, one of the recommended emergency procedures is to drop the gear (which will then have to be inspected before further flight). David I just tried the default Cessna 172-3D. It climbed out at 2500 rpm (engine rpm) and when I got to 1,500 feet I pushed the nose over to a 45 degree downward pitch and accelerated quickly past the redline and was still accelerating at 155 knots when I pulled up to avoid the obstacle in front of me (a looming planet). The recent release seems to work fine in the above-questioned regard. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Some thoughts and ideas (LONG)
On Friday, 7 November 2003 02:58, David Megginson wrote: What release is it? The 172 changed a release or two ago. 0.9.3 - The one with the nice ready to run Windows installer. It's the 172 with the 3D cockpit and nice yellow tints on the wings. :) I would run it under Linux except that last time I couldn't maximize the screen without the FPS dropping to 1. Anyway it's not an issue - I haven't played around with all the models yet. Paul ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Some thoughts and ideas (LONG)
Paul Surgeon writes: 0.9.3 - The one with the nice ready to run Windows installer. It's the 172 with the 3D cockpit and nice yellow tints on the wings. :) That's pretty ancient. Our current 172 looks a fair bit better. All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re: [Flightgear-devel] Some thoughts and ideas (LONG)
On Fri, 7 Nov 2003 11:46 am, [EMAIL PROTECTED] wrote: Preface == I would like to see the sim become more friendly to casual users especially on the eye candy side of things. This does not need to detract from the scientific/academic nature of FlightGear - you guys can carry on with the great work. My reason for this is that a lot of people who play with sims can also develop addons but there needs to be an incentive to get them involved and screenshots say more than a thousand words can. As a counterpoint, I would like to request that this either not take priority, or that it be an option in the configure stage. I want fast framerates as the priority. For me, this is a _flight_ sim and I don't see the point of eyecandy. ( Personally, I was disappointed with FS2002 and much preferred the playability of FS98. FS2002 devoted too much to eyecandy and was so obtuse in actually getting to the point where you were in the air and flying that I stopped using it. It took about five minutes of configuring various options before you could take off.) We need at least one properly/accurately modeled aircraft that we can show off. I'm talking nice visually (high poly count) and with an accurate flight model. Most people using recent commercial flightsims are running 1.5 GHz PCs with at least 64MB GeForce 4's so poly counts can be fairly high. I disagree with this assessment. I think lower spec machines should be able to run a _flight_ sim and shouldn't be excluded just for the sake of eyecandy. I agree with the OP re terrain mapping. BTW : I took the Cessna 172 for a flip and was dissapointed. The visual model is really rough - looks like it taxied into a brick wall to get into those funny shapes. I don't agree with this assessment. I think it is modelled quite well. At full throttle and a 1500 fpm decent it wouldn't go over 140 knots. In real life it would hit VNE very quickly. I just tried this and it does go to VNE. In my experience (a few hundred hours PPL, mainly C172 and C152), the C172 is modelled very accurately. Did the OP chase the VSI? It has a several-second lag, esp when changing attitude quickly (again, this is modelled accurately), which could account for him not hitting VNE. I know this may be anathema to some people, but I rarely use the external view and don't really care what the plane looks like from the outside.My priorities are: 1) accurate flight model; 2) high framerate; 3) accurate panel (in the sense the instruments do what they should, and that they are all represented, not in the sense that the panel looks like the real plane's panel). For example, there is a fault in the heading bug in some panels. If the DI is not slaved to the compass, the main HSI heading bug does not rotate with the change in direction and consequently, the heading bug never reaches the top of the card. It constantly rotates against the change in direction. Try the seahawk for an example. I'm not trying to rain on the OP's parade; I think he has some good ideas. It's just that I would prefer to see development take priority in the fields I am interested in, naturally enough. Nick, offering another viewpoint. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
