stuart_d_buchanan

Hi Guys, Mike T707 - No idea when/if we'll get to Outerra/Proland levels of polish. At one level, we're fairly close with procedural texturing and various shaders. If you look at some of the screenshots that Thorsten Renk has posted on the flightgear.org website showing off atmospheric scattering and his procedural texturing work they are quite comparable. However, our autogen and vegetation rendering isn't as advanced, and I'm not sure how to do it without hitting frame-rates massively. It's also worth pointing out that the screenshots from both Outerra and Proland have a fairly narrow scope - they are generally showing temperate forested mountains and have been tuned for rendering those specific scenes. For FG we need to be able to render a much wider geographical area (deserts, farmland, tundra), plus urban areas. We also seek to do so in such a way that someone without programming knowledge can fairly easily create an environment that matches their local area (we've got different terrain for the Caribbean for example) Finally, we're very short of graphics programmers. UR67393 - Your comments about polygon-based simulators coming to the end of their life is very interesting. As I said previously, we have put some effort into separating out the FG core simulator from the graphics - there is a component call fgviewer which implements this. It should be possible to integrate with Proland, but it all boils down to having the development resource to do so. It took about 3 years for us to completely convert from plib to OSG, which was simply a conversion from one polygon based system to another. You have enthused me to take a further look at proland . -Stuart

Hi equicom, Apologies for the delay in replying on this. If you haven't already, you might want to post your problem to the support forum at flightgear.org: http://www.flightgear.org/forums/viewforum.php?f=17 -Stuart

Yes, I think we've looked at Proland in the past. I don't think there's anything the Proland offers that we couldn't develop within our existing framework. Fundamentally it all boils down to data being written as OpenGL primitives and rendered using shaders. Regarding polygons - at the moment we don't think that we're limited by pure polygon/vertex count, provided those vertices are sensibly arranged. Modern graphics cards are very good at churning through huge numbers of polygons. What tends to be more of an issue is when the polygons are organized inefficiently, or rely too much on complex shaders. A case in point is the trees and random buildings, which generate millions of polygons, yet render quite rapidly, whereas having a much smaller number of discrete models slows things down significantly. One area that I'd like to look at if I get the chance is transformations we can do within the graphics structures to make it more efficient at loading time. However, that's quite a big project, and like more FG developer's I've got plenty of other things on my plate! -Stuart

Hi UR67393, I think the probability of FG changing to support voxels in the near future is very close to 0, and I say that as one of the FG developers responsible for some of the graphics. That said, if you wanted to work on it yourself, you are very welcome, and there has been significant work recently to separate the rendering engine from the underlying simulation.. The entire scenery toolchain is based on polygon data and would need to be re-written, plus FG uses OpenSceneGraph as it's OpenGL interface, and that would have to be modified to handle voxels. -Stuart

Hi emarkay, I haven't looked at your issues specifically as I've been on a break from FG development for the last month but have you raised the bugs through the official bug tracker (https://code.google.com/p/flightgear-bugs/)? -Stuart

jcomm: What aspect of the single-engine performance is incorrect? I'm slightly surprised, as it's the author's own RL aircraft that's modelled, though I suspect he doesn't switch off one of the engines very often! Other aircraft I'd highly recommend taking a look at are the IAR80 (Hungarian WWII prop), A-6 (particularly with our carrier support), and F-14b. -Stuart

Re: OpenGL / Frame-rates. The main reason that FG uses OpenGL rather than (say) DirectX is to provide open, cross-platform support. Unfortunately many graphics cards support DirectX better than OpenGL, hence you get better frame-rates with DirectX software rather than OpenGL. Intel integrated graphics cards are particularly bad in this respect. As an aside, I'm hopeful that OpenGL support will start to improve with the introduction of Steam for Linux. Bill - the symptoms you report sound very strange, though I'm glad you got it running eventually! There's a joystick configuration option under Help that should allow you to configure your joystic as you wish. RE: documentation - there are installation instructions on the download page, but they don't cover issues such as the 64/32 bit one mentioned (which I hadn't come across before). Obviously we should improve our installation instructions! -Stuart

mgh: I'm guessing you've got an Intel integrated graphics card, rather than a discreet Nvidia/ATI one right? Unfortunately Intel integrated graphics are very weak, and also don't have very good OpenGL support which is required by FG. You would need to disable most of the eyecandy in FlightGear, by selecting Advanced > Properties in the launcher and creating a new line with /sim/rendering/shaders/quality-level=0). That should at least allow you to start the simulator, though you may see very low framerates. -Stuart

jcomm: Out of interest, under which menu were you expecting to find it and why? You're not the only person to have difficulty finding it. I spent a bit of time trying to work out the best place for the UI within the menu system, and I'm not sure I got the right place. -Stuart

nfmz1 - going slightly off topic, but you shouldn't need to install any additional software to get your joystick working with FG 2.10.0. In fact, I'd recommend not using the Saitek software, and just configuring it through the Joystick Configuration UI within FG itself (assuming FG is detecting it correctly as a USB joystick?). I recall seeing reports from other users saying that the Saitek drivers just confused matters. If you want to do complicated bindings like having a mode selector switch, you're better of doing that natively within FG rather than any Saitek software. However, that isn't supported by the FG Joystick Configuration UI, as it's quite complicated. -Stuart

Just to clarify - what's available as of 30th January are the 2.10.0 Release Candidates. They are primarily for people wanting to test the new release. The actual release will be around the 17th February. We're not expecting much to change as FG is fairly stable, but there will be bug fixes between now and the 17th. You're welcome to download the RCs, and if you hit any problems please report them using our issue tracker (http://flightgear-bugs.googlecode.com/), or forum (http://www.flightgear.org/forums/viewforum.php?f=68&sid=609ec9b5a4c82ac32fc590fa119df4cd). However, please be prepared for some turbulence, and you may wish to wait for the final release instead. Of course, you can install the 2.10.0 RC and then later install the install the final 2.10.0 release. -Stuart

@Robert : Absolutely. That's one of the great (indirect) advantages of FG - provided someone somewhere is interested in developing it, it will continue to be supported and developed. It won't be orphaned because it didn't quite match a companies expectations. There's also no restriction on what you can do with it. There is a downside to this, which is that the developers do what interests them, and so some areas get less development than others. General usability has been one of those neglected areas, but some developers (including myself) are doing what they can to improve it there. -Stuart

Perhaps end users might not be interested in this "openness" directly, but it makes it much easier to develop add-ons and enhancements, which results in a better simulator.

Hi, I'm one of the FG developers, and have done commercial work with FG in the past, so am quite familiar with GPL issues. Basically, if you release your code under the GPL anyone receiving it is free to redistribute it for free. So, if you were (say) to create a GPL aircraft and sell it, you wouldn't be able to stop the buyer from handing it out to anyone. However, there's no requirement that your work is GPL, provided it doesn't use any GPL code itself. So you could create non-GPL aircraft or scenery and sell it as you wish. There are a couple of considerations however: 1) Most FG aircraft use the Nasal scripting language which is part of FG. You'd need to either use another (external) scripting language, or release the Nasal code under the GPL. 2) The FG formats are very open - for example there's extensive use of XML. You wouldn't be able to protect your IP through obscurity. I'm also not sure how license keys would work 3) I think the market is pretty small at present. Regarding hesitating to use the GPL license for fear of work being sold by others - I think that horse has bolted. The various offerings of FG for sale are all now using versions many years old. They have no incentive to use the latest FG given their business model. I'd also point out that FG only exists due to the GPL. -Stuart

Hi All, I'm one of the developers of FlightGear. Amongst other things I'm responsible for the Joystick configuration GUI which will be part of the upcoming release, and I hope will make life easier for everyone trying FG for the first time. Obviously I'm quite late to this thread (I don't look at the Avsim forums very often), but I thought I'd answer some of the issues that have been brought up. 1) Regarding the video of the landing and John Lennon - I'm 99% sure that's all "real", with the exception of the fade-in at the start . There's been quite a lot of work put into the water shader recently, and it now responds appropriately to the wind, with waves in the right direction, whitecaps appearing at high wind speeds and a "blueness" reflecting the sky conditions and geographical effects such as silt. 2) Someone mentioned being in the sea when starting from KSFO. Given that FG ships with KSFO as the standard airport, that sounds very much like an installation issue. FG _should_ be able to find itself and it's scenery, but if you've installed/uninstalled multiple times then it may get confused. To correct this, press the Back button from the first page of the launcher. That will allow you to locate the fgfs binary, the FG_ROOT location (The root of the FG data), and the FG_SCENERY environment variable (which should point to the Scenery subdirectory of your FG install). Further information on these variables can be found in the FlightGear Manual (which I maintain amongst other things): http://mapserver.flightgear.org/getstart/ 3) The comments about "FG being for people interested in building a flight simulator" has a lot of truth to it. It is something that we're addressing in the current release with elements such as the joystick configuration UI. The flip side is that the simulator is very "open" architecturally and functionally, so there's a huge amount of freedom for creating new stuff. For example, all the internals of the simulator are easily accessible through just about any interface you can think off - http, telnet, TCP/IP, scripting. 4) Talek - getting poor fps with a GTX 660 seems odd. That's a fairly high end desktop graphics card right? You might want to go on the Flightgear Support forum and ask for tips. Also, try using the Fair Weather scenario - there's a known issue with very overcast conditions that aren't handled well by 3D clouds in 2.8.0. They are improved in the upcoming release (2.9.0). Apologies if I've missed any significant issues/questions. Please feel free to post them below and I'll do my best to answer them. Best regards, -Stuart