FlightGear Newsletter March 2014
|
Development news
TerraGear developers looking for your help
The TerraGear maintainers are looking for volunteers to help with development on the next world scenery project. If you've ever wondered how a full 3D model of earth can be generated from raw data, now is your chance. See the plan at World Scenery 3.0 roadmap. In addition, as part of working on an experimental TerraGear scenery build server, we're currently looking for people able to offer hosting for testing purposes.
FGPlot goes OOP
kuifje09 has finished porting his original FGPlot work (originally using PUI/XML dialogs) to use just Canvas now. In addition, the FGPlot code base has now been heavily refactored and modularized, introducing additional classes and separate files for each modules. In addition, FGPlot has now been sufficiently generalised to be also usable from other Nasal scripts. We are currently in the process of reviewing everything to hopefully ensure that this can be committed in time for the upcoming 3.2 release.
To learn more, continue reading at the forum topic 
Installing TerraGear in 10 seconds on Linux
As part of working on a long-standing feature request, namely having a central shared TerraGear scenery build server, saiarcot895 has created Linux packages for Debian/Ubuntu (deb/ppa) to install precompiled TerraGear binaries. This now greatly simplifies installing TerraGear, because people no longer need to manually set up a complete Linux build environment and all SimGear/TerraGear dependencies. Everything is now done in an automated fashion.
Next, we're hoping to use this to install TerraGear on a public server for which people can ask for remote shell access (SSH). People interested in exploring this, should be getting in touch via the forum or the wiki.
Obviously, users will still need to be familiar with TerraGear, but they may benefit from reduced bandwidth restrictions and/or more horsepower in comparison to running TerraGear locally (e.g. one user offered to contribute hosting on a 32gb RAM and 8-core server). So this could be a great opportunity for people to run scripted/unattended jobs, without having to go through the hassle of downloading/building/installing and configuring TerraGear. But so far, being familiar with TerraGear and Linux is going to be a prerequisite still.
Once that is working, we'll investigate making the setup reproducible by using TurnKeyLinux. Once we have a working TKL distro, we can install a full TG setup in just a few minutes by downloading an ISO file and installing it in a VM (VMWare/VirtualBox). This would basically allow people to easily download/install TerraGear locally, either installed next to their OS, or as a virtual machine.
The long term idea is to hook up TerraGear GUI to it, so that the GUI front-end talks to TerraGear across SSH.
This is currently still a use-case for which TG wasn't designed for, and the TG developers mentioned already on the forums that there may be some roadblocks ahead, so everything here is still highly experimental. But ultimately we hope to provide a front-end to a Linux-based TerraGear VM, either by reusing TerraGear GUI or by coming up with a custom web-based front-end (please get in touch if you can help with this!).
If you're interested in helping or learning more, please get in touch via the forum or via TerraGear scenery build server.
Modified JSBSim search paths
AndersG has changed the search paths for JSBSim engines, propellers and systems in FlightGear to make it possible to have engines, propeller and system files shared by several aircraft stored in one place instead of keeping copies below each aircraft directory.
The change adds $FG_ROOT/Aircraft/Generic/JSBSim/{Engines,Systems} to the JSBSim engine, propeller and system search paths.
JSBSim searches <aircraft_dir>/Engines and <aircraft_dir>/Systems for the requested files before looking in the shared directories. This is consistent with how JSBSim works as a standalone program and should not cause any existing aircraft to load a different file than before.
Reset & Reinit
James started switching over the reset system to use the new code. The following changes will happen, in order:
- places that only need to re-position will use the new ‘reposition' command, which is a simplified version of the current reset (and will become even simpler over time, but for now the goal is maximum compatibility). This means the 'select airport' and 'position in air' dialogs, principally.
- the reset command will be switched to use the new logic, which is slightly slower than the current logic, but much more complete. It's very close to shutting down the simulator and re-starting; in particular Nasal is restarted, and it should be possible in the near future to toggle between Rembrandt and the classic renderer. (The only UI-path that triggers a reset its the actual menu command / key-shortcut - If anyone knows of some strange way we trigger a reset, please do let James know)
- the "save / restore initial state" logic in globals will be removed, since it will no longer ever be used
- Many properties which are flagged as 'preserved' or 'userarchive' need to be audited for correctness in the new system. This will be an iterative process, but James will try to address issues as quickly as possible. Unfortunately each time a fix in preferences.xml is made, testers will need to delete their auto-save file. This is the price of living on the bleeding edge :)
James is not expecting any build failures since the code is already in Git, but he would ask that any bug-reports are only made /after/ wiping your autosave XML file.
Continue reading at Reset & re-init...
Built-in httpd updated
While working on the new radio/ATIS implementation, Torsten rediscovered the internal httpd (aka webserver) to browse the property tree. It's much easier to have multiple browser windows open and point to various locations in the property tree than to reopen the internal property browser and navigate to the locations after each sim restart.
After a while, Torsten got disappointed by the functionality and the look&feel of the http property-browser, so he had a look at the code to see if it could be improved, he quickly realized, that the implementation was simple but not scalable, so he looked for something allready available on the GPL market.
And he found Mongoose as a well maintained, feature rich and yet simple implementation of a web server and started to embed that into FlightGear.
What is ready so far and pushed to next is:
- A single threaded httpd running in the main loop (should probably get its own thread soon)
- Running as a replacement for the old httpd
- Serving $FG_ROOT/Docs as the document root
- Serving the uri /props/ as a replacement for the old property browser (improved functionality, improved l&f, styling via css)
- Serving the uri /run.cgi as a replacement for the old interface to run fg_commands
- Serving the uri /json/ to return selected properties as JSON (read-only so far)
All this has a lot of potential. With the JSON interface extended to being able to write properties, the CGI interface of Mongoose turned on, the webserver running stable in it's own thread, It should be possible to run e.g. PHP with jQuery or dojo.
If you want to test the new functions, go to:
- http://localhost:<httpd-port>/ for $FG_ROOT/Docs
- http://localhost:<httpd-port>/props/ for the internal property browser
- http://localhost:<httpd-port>/json/some/property/name/or/path for the internal property browser
- http://localhost:<httpd-port>/run.cgi?value=pause to pause/unpause the simulation
Please mind the trailing slash for /props/ and /json/ (no, it's not bug-free yet.)
Torsten has pushed a litte quick-and-dirty example to fgdata. If you have a recent build from git/next, start FlightGear with --httpd=8080 and point your browser at http://localhost:8080/gui/radio.html You need to be online to see the goodies as the jQuery js is loaded from code.jquery.com and not (yet) pushed to fgdata. The updates every five seconds and does not write back to FlightGear yet.
If you can't run the latest codebase, check this screenshot
New built-in moving map
When starting FlightGear with the internal web server enabled (--httpd=8080), a new moving map application is accessible for those with a working internet connection and state-of-the-art web browser. http://localhost:8080/gui/map opens an interactive map covering the entire world, enriched with FlightGear navigation data and live weather information. An aircraft symbol is showing the current position of the simulated FlightGear aircraft, also indicating its heading and altitude. The position information is sent through a websocket in real-time without the need for polling the FlightGear web server. The update rate of the map is currently throttled to 1Hz but refresh frequencies up to 20Hz have been successfully tested. The map can follow the aircraft's position or may be panned freely around the world, still tracking the planes position on the map.
Three base layers currently exist: OpenStreetMap, Mapquest road and Mapquest satellite. Overlays for the FlightGear navdata, precipitation and sea level pressure isobares from openweather.org may be added in any combination. The level of detail for the navigation data varies with the zoom level. To keep the load on the FlightGear instance low, Navigation data will only be displayed up to a radius of 250NM around the maps center. In detailed zoom levels, all airports (including runways), navigation aids, localizer courses of the displayed area will show up after a short delay. A click on a marker brings up a popup with detailed information about the item like name, frequency, runway length etc.
Several modern web techniques power all this: There is Leaflet, "Open-Source JavaScript Library for Mobile-Friendly Interactive Maps". There is jQuery, "a fast, small, and feature-rich JavaScript library". On the server side lives mongoose, "The easiest to use web server on the planet". Data flows as JSON, "The Fat-Free Alternative to XML". A lot of HTML5 and CSS3 is also involved. The map has been tested on Safari on OSX and iOS. Chrome on Android, OSX and Linux. Firefox on OSX and Linux. It runs on workstations with huge screens, laptop computers with small screens, tablets, smartphones and even an old iPod with iOS 6.
Cloud Shadows (by Thorsten)
Thorsten implemented an improved shadow finder on the Nasal side, better shape on the GLSL side... and started teaching the other effects to respect cloud shadows:
|
In a way, I appreciate the conceptual simplicity of deferred rendering where this can simply be done in pixel postprocessing. If it would just run faster... but anyway, now I got buildings to go out of light properly. nd the cloud shadows now project. Well - sort of - not exactly following terrain and season, just based on mean, but it's good enough if you don't go looking for deviations.
For those interested, here's some details to the technique and why it's implemented the way it is: I've read up a bit on shadow generation techniques in the literature, and clouds appear to be tricky. Shadow volume techniques are out because they don't work for semi-transparent texture stacks, so it's got to be shadow maps. Generating a shadow map on the fly requires a shadow camera pass over clouds. I know from prior experience optimizing cloud rendering performance by means of a z-buffer filling first pass that any second pass over clouds is prohibitively expensive - any attempt to pass over clouds a second time drove me below 10 fps for even moderately clouded scenes. If I were to speculate, I'd say that this is the reason clouds in Rembrandt don't cast any shadows in spite of Rembrandt being easily able to include clouds in the shadow camera pass. There are other disadvantages to this approach, for instance a cloud texture could be fairly opaque (i.e. zero alpha) but we still might not want to render a shadow since the cloud is too high and diffraction would erase it, or because the cloud is translucent white and does in fact not cast a shadow, we may want to draw different depth of shadow etc. So I believe a cloud shadow map needs to be generated procedurally from meta-information supplied by the weather system rather than in the rendering pipeline, since only the weather system knows what a cloud is and whether we want to draw a shadow or not. There are still two different ways this could be done:
In the event, I've chosen the second approach, since evaluating 'simple' functions on the GPU is in my experience (a lot) faster than looking up a large texture (my rule of thumb is that a texture lookup is worth about 10 exp() functions or ~100 simple functions such as smoothstep()). Moreover, texture units are limited to 8, and the model ubershader already uses all available texture units, so there's some merit to not passing a texture. The current code then passes 40 uniform position data points of clouds with shadow strength and depth encoded in the position information, allowing to draw 20 distinct cloud shadows. The weather system registers a shadow candidate every time a cloud which would cast a shadow is generated (currently that's Cu and Congestus type clouds) and a subroutine of the weather system selects which of these candidates should be drawn by the shader based on the current view position (and fov if the flag is on). The shadows are projected in a rudimentary way, but not exactly, i.e. the projection does not account for season and for terrain elevation - that's the price of framerate-friendliness, but one really has to go look hard to see the projection errors. So, I believe this technique has pros and cons over an on the fly generation by a camera pass, but framerate friendliness certainly is a big pro here. As indicated above, I will gradually deal with proper shadows in all special-purpose shadows and also register different types of clouds for shadow candidates in the weather system. I'm not sure whether this can easily be generalized to the way Basic Weather handles clouds, and one point of discussion may be down to which quality level this feature should be supported, so there's plenty to be discussed.— Thorsten
|
|
Aerotowing Support
Since a few days we have a Nasal-script (Nasal/towing/hitch.nas) that provides two features:
- winch and aerotowing support for JSBSim-aircraft (glider and towplane)
- visible tow and winch ropes for YASim- and JSBSim-planes
The functions in hitch.nas are very similar to the YASim-routine "/FDM/YASim/Hitch.cpp" and hence aerotowing is fully compatible with the YASim functionality. This means that YASim-gliders could be towed by JSBSim-aircraft and vice versa.
Setup instructions with copy and paste examples are given in the first paragraph in hitch.nas and at User:D-NXKT.
This routine is only active for gliders/towplanes and doesn't influence other aircrafts. Visible ropes for YASim-aircraft will work out of the box without any modification in the aircraft-files.
The SGS233 is an example for a JSBSim-glider, Bocian is one for a YASim-plane. In case you want to test other YASim-gliders: If you don't see the towrope at the expected position ... this is rather a wrong hook-setting in the aircraft-file than a bug in my routine. Btw. this explains, why some gliders are very hard to tow ... the hook is mounted far behind the c.g. !
Special thanks go to the developer of YASim/Hitch.cpp and Klaus Kerner, who was the first providing a visible rope and towing capability for a JSBSim-glider (DG101g). A lot of their work is incorporated in this new routine.
Getting involved as a programmer
Unfortunately, most of the active FG developers are currently very overstretched in terms of the areas that they have ownership of, which is affecting how much can actually be done. Fundamentally we need more core devs.
If you are interested in contributing as a core developer, please see Howto:Start core development.
If you interested in other developing, i.e. not C++ but Nasal scripting and/or XML, there are some articles listed at Category:Popular Community Requests that have been suggested, but not fully or partially implemented, and are "mentored efforts". That means that the community is looking for a hand in implementing them -- help from you -- but will also have more experienced developers willing to help you, for example by having tailored tutorials or even code snippets written for you. As mentioned in each page, please get in touch if you would like to help with one of those projects. In comparison to C/C++, Nasal is simpler and easier to learn quickly. It also doesn't require recompiling, which means that you can test and develop changes with a standard FlightGear release, i.e. off of the main download page. As long as you can run FlightGear, you can also run Nasal code and contribute. Many tutorials covering a wide range of projects are listed at Nasal, so if you know a programming/scripting language already, or would like to try something new, go ahead: read, write, try and get involved! When it comes to Nasal scripting, playing around with different tutorials and code snippets is more important than being an experienced coder.
Of course, you're also free to work on whatever you want -- FlightGear as a community-driven doesn't tell people what to do, but welcomes any contributions from anybody, as long as they have acceptable quality and are free to be licensed under the GNU GPL. So if you have something you would like to contribute back to FlightGear, please get in touch! (Preferably using Gitorious for larger merge requests, and the forums or (core-) developer's mailing list to inform the developers of what you want to contribute back.) Changes contributed 6-8 weeks before a release will usually appear in the next release, so your changes can be spread across the world.
YASim looking for a new maintainer
|
|
There are some pending merge requests to add some Yasim features, but we have an issue that since none of the current C++ developers own, or are experts in Yasim, we're reluctant to be the person who merges such changes, and potentially introduces subtle regressions.
Obviously this is chicken-and-egg, since no one can become expert enough in the code to become a maintainer :) So, I'm more than happy to apply patches *providing* I can be convinced they are sane+reasonable from a pure code perspective (happy to help with that, too, if people are new to C++), and providing we have some assurance that a representative sample of yasim aircraft are unchanged or improved by the patch. Suggestions for that means in practice, are most welcome! Otherwise I worry, given the nature of the solver, we'll keep optimising the solver for some aircraft, and making other existing aircraft worse - until someone tests them, and announced that they're no longer working.[1]— James Turner
|
|
|
|
I am still broadly happy to answer questions if posed (as long as I remember enough to come up with a meaningful answer). Just cc: me if you do, because my
latencies here are measured in weeks. Bugs can always be fixed. What YASim needs is a maintainer, not really expertise per se. The latter comes from the former.[2]— Andy Ross
|
|
New software tools and projects
Bash Completion
A new Bash completion script is now available for the fgfs-command. You just have to install the completion script as explained here.
New feature??? Yes, you are right! Bash completion has existed for Flightgear since 2005 (a time where this feature has been really rare!), but not been updated since 2008.
The new release now supports auto-completion for all options from "fgfs --help --verbose", as well as airport codes, aircraft names, parking positions, runways, carrier names, scenarios, navaids, and some more.
If you have questions or comments regarding that script, please post them to this forum thread .
In the hangar
New aircraft
Airbus A310
The Airbus A310 is a medium- to long-range twin-engined wide-body jet airliner that was developed and manufactured by Airbus. Released in 1983, it was the second aircraft to enter production by Airbus Industries.[3]
This new package contains models of the A310-204, A310-222, A310-308 and A310-324 in alpha phase:
- The models are quite detailed with working, retractable gears, working flaps/slats/... (4 points)
- The FDM is a basic aeromatic approach with accurate input data (1 point)
- The systems are in "engines always on” state right now (0 points)
- The cockpit is a modified version of Pierre Duvals A300-600ST flightdeck. It was fitted to the A310 but some of the instruments need to be adopted to the A310. (3 points)
The aircraft comes with a detailed paintkit in .svg/inkscape file format and is shipped with 13 shared (=usable with all 4 models) liveries.
If interested, you can find a link to the download and some status updates in the forum . Any contribution or help, especially for the systems and FDM is highly welcome!
Vespa Scooter for FlightGear
By LesterBoffo
Really not a new aircraft per se, but its flight model borrows from YAsim prop drive aircraft. Some years back I had made a scooter model for Flying Model Simulator, the RC model training simulator. This is the 3D model with some improvements of the basic 3D and additional animations. In use it operates much like a modern 'Twist and Go' CVT transmissioned scooter. You apply throttle and it accelerates, apply brakes, ( both wheels are braked.) using the joystick button 0 or trigger button..) or the period key, (.) for rear and comma (,) for front brakes. Using the rear brake is handy because it applies less braking force and can be used as a 'trailing brake' through corners. My future plans include re-editing the FDM and adding some nasal so this bike has a 4 speed gearbox.
I've presented this model for a multiplayer event of a Scooter tour of the Isle of Man's famous motorcycle Time Trial Race Course. I prepared some 3D scenery files to be used in the new 2.0 scenery for the UK/Europe areas, with it's improved roads.
There will be a couple other bikes made for FlightGear, although I don't think they will be done in time for the MP event.
I've been approached by Detlef Faber, who offer to adapt his walker figure to use with this scooter. So the user/pilot will have the ability do first person excursions from the bike after parking it. It will also have improved rider animations. I'm also providing the aero-winch tow functions from the FlightGear YAsim glider FDM's on this bike, because it tends to get stuck fast in rough terrain, much like the conifer forest terrain tiles. This is a 'feature' of the YAsim wheel modeling that I like, because it models rough ground and you can make trips off the pavement on some kinds of terrain without having it get stuck.
Scenery corner
Airports
Flyingfisch has been working on several of the airports in northeast Ohio. See this forum post for more details.
New tree textures
With the new world scenery and procedural terrain texturing techniques, FlightGear's visuals have progressed to a point that trees were the least realistic element in the scene. This of course can be fixed. Thanks to work by forum user Zbyszek (deciduous trees) and ThorstenR (coniferous trees), we now have new hires tree textures for the regional texturing scheme (for legacy support, global texturing still uses the old trees), making the visual quality of the trees now on par with the rest of the scene:
Screenshot of the month
Flying by Denali, Alaska, in tricky weather
Aircraft reviews
Piper PA-22
| This section contains a review. Please note that statements made here are (mostly based on) a single person's opinion. |
The Piper PA-22 is a classic post-World War II aircraft. Produced from 1950-1964, it competed with other light GA aircraft of the day, including the Cessna 150. Its popular appeal lay in its ruggedness, spacious cabin, and, for the time, impressive speed.
Let's see how the FlightGear version compares.
The FlightGear version of the plane includes an autostart option as well as a tutorial to step you through the process. The takeoff is smooth and steady, only minimal rudder is needed to keep the aircraft lined up with the runway. We rotate at about 55 MPH, accelerate to about 85 MPH, and climb. The climb rate is decent, and pretty soon we reach our cruising altitude of 1000 feet.
After leaning out the mixture a bit, pulling the throttle back to three quarters, I decide to turn on autopilot. There is a tutorial to step you through the use of the autopilot, which is quite simple. Since the autopilot only takes care of roll, we reach up to the ceiling to adjust the vertical trim. Clicking it will cause it to rotate in one direction, middle clicking will rotate it in the other direction.
Now that the plane is flying in a hands-off configuration, we can look around. Since the day I took off on was pretty warm, I decided to open the window for a little breeze. This is easily done by clicking on it. The vents on all four windows also open and close when clicked. If it's dark out you can click the dome light behind you to light up the cockpit. Red-tinted instrument lights are also available.
A little experimentation will show you that it is pretty hard to stall this aircraft. What happens instead is the aircraft mushes with full elevator, and the plane just falls from the sky. You still have control and dipping the nose down a bit and increasing power should get you flying normally again.
We head back to the airport at about 110 MPH to test out the landing characteristics. As we approach the airport, we slow down to about 90 MPH and lower the flaps fully. Our over-the-fence speed is about 85 MPH, and raising the nose slightly and cutting power over the runway sets us gently on the ground.
The flight isn't over yet though. A little judicial movement on the rudder pedals makes sure we don't turn off the runway. In this regard, a stitch in time saves nine, and small movements as soon as you see a little lateral movement saves having to make large embarrassing ones a second later. Be careful with the brakes, as this plane has a tendency to dip a wing if applied too roughly.
The flight dynamics seem pretty realistic, the model is excellent (it even has four liveries and a paintkit), and the 3D cockpit is superb. One thing I would suggest is having it remember your preference whether to show or hide the wheel pants, but apart from that I don't see anything lacking.
-- Flyingfisch (talk) 20:54, 13 March 2014 (UTC)
Wiki updates
Translators required
|
The FlightGear Wiki still needs help for translating it into various languages. If you are interested in making the FlightGear Wiki multi-language then start at Help:Translate. |
|
Das FlightGear Wiki benötigt immer noch Hilfe bei der Übersetzung in verschiedene Sprachen. Wenn Du Interesse daran hast, das FlightGear Wiki Mehrsprachig zu machen, dann fang doch mit Help:Übersetzen an. |
|
De FlightGear Wiki kan nog steed hulp gebruiken bij het vertalen van artikelen. Als je interesse hebt om de wiki meertalig te maken, raden we je aan om een kijkje te nemen bij Help:Vertalen. |
|
La FlightGear wiki todavía necesita ayuda para traducirla a varios lenguajes. Si estás interesado en hacer la FlightGear wiki multilingüe, entonces comienza en Help:Traducir. |
Community news
Virtual airlines
In the heart of Europe formed a group of four states that publicly act like one. This group is called Visegrad four. As the community FlightGear still a few pilots from the four countries, we decided to establish a virtual airline called Visegrad 4 Airlines. Although we are still in the beginning, already operates some routes, both domestic and international. The backbone of our fleet should consist of a Boeing 707, both for passenger transport and freight transport. Our callsign starts at V4A, according to which we can safely make out, as well as under its own livery ...
More information can be found on our Google+ page
FlightGear events
Hang gliding simulator
FlightGear was used to power a hang gliding simulator, presented on March 8th/9th in Bremen at the Rad+Outdoor / Passion 2014 convention, hall 4B, booth 60.
The pilot sees the simulation through an Oculus Rift head mounted display. Input is controlled by a joystick that is mounted upside down to catch user input. The whole simulator runs out of the box with proper command line/config options in FlightGear.
See the forum thread for some details.
And finally ...
Contributing
One of the regular thoughts expressed on the FlightGear forums is "I'd like to contribute but I don't know how to program, and I don't have the time". Unfortunately, there is a common mis-conception that contributing requires programming and lots of free time. In fact, there are a huge range of ways to contribute to the project without needing to write code or spending days working on something.
For ideas on starting to contribute to FlightGear, you may want to check out: Volunteer.
To learn more about how the project works, please see this short essay written by Thorsten, for a more detailed article see How the FlightGear project works.
References
|