FlightGear Newsletter May 2014
|
Development news
Project Rembrandt
A number of Mac users have been reporting issues related to running Project Rembrandt (deferred rendering/shadows) on Mac OSX with ATI/AMD GPUS, we are now looking for Mac users to provide feedback on running Rembrandt on Mac OSX, required information includes errors and warnings shown during startup/runtime, but also screen shots showing any issues. Please see: Project Rembrandt#Mac Issues.
Porting the Garmin GPSMap 196 to Canvas
The Garmin 196 is currently in the process of being ported to Canvas and MapStructure by F-JJTH.
Given the generic nature of Philosopher's MapStructure framework,it only took us 60 seconds to integrate with MapStructure using just 10 lines of Nasal code - it's a fully working moving map - scale is obviously still off in those screen shots, but it's a matter of setting another style (which can also be used to change color and most symbols)
![Protoyping the G196 instrument display using wikimedia/commons SVG images and the unmodified Canvas SVG parser as per [1]](/w/images/thumb/a/a9/Gpsmap196-svg-instruments.png/646px-Gpsmap196-svg-instruments.png)
Protoyping the G196 instrument display using wikimedia/commons SVG images and the unmodified Canvas SVG parser as per [1]
MapStructure layers integrated in GPSMap196 with some custom styling applied
GPSMap196 with MapStructure layers (currently exhibiting some scaling/LOD issues due to hard-coded assumptions in some of the layers)
![Protoyping the G196 instrument display using wikimedia/commons SVG images and the unmodified Canvas SVG parser as per [1]](/File:Gpsmap196-svg-instruments.png)
![F-JJTH's GPSMap196 in the process of being ported to Canvas using Philosopher's MapStructure framework for mapping (LOD/scaling not applied here, but available) - see [2]](/File:Gpsmap196-MapStructure.png)
This is exactly the reason, why we've been working towards an aircraft and GUI agnostic abstraction layer using MVC design concepts - so that reusing and integrating such stuff is really straightforward, without people having to come up with their own custom maps and layers from scratch.
|
Today, just the MapStructure framework is under 1k lines of code, and is making roughly 9k-15k lines of C++ code obsolete in FlightGear (agradar,groundradar,wxradar,map dialog), unifying the whole shebang in the process, which also ensures that more modern OSG/OpenGL can be used, i.e. better performance in the long-term.
This all has taken place in under 24 months actually (MapStructure just being 6 months old now actually) - whereas hard-coded instruments (wxradar, agradar, navdisplay,kln89 etc) are usually 5+ years old, and things like the Map dialog even older - in comparison, these were all "easier" to come up with in the first place, but obviously don't scale as well as a Canvas-based solution. Gijs NavDisplay framework is already better accessible and more feature-rich than the original ND code.
But this kind of work isn't exactly fun, it comprises lots of refactoring and is more about talking and coordinating things than actually coding stuff - because the implementation may very well just be a fraction the size of all the manifestations that are hopefully replaced over time.
— Hooray (Wed May 14). Re: scaling instruments in xml.
|
|
If you'd like to help in one way or another (no programming skills needed, Inkscape artists also needed!), please get in touch with F-JJTH or Hooray on the forum.
Also see Garmin GPSMap 196.
To learn more, please follow the forum thread
Canvas Performance
Recently, it has been two years since Canvas, our 2D rendering API, got integrated. And even today, there are people claiming that aircraft using Nasal and Canvas are generally slow and don't provide sufficient performance, suggesting not to adopt Canvas yet, so here are some comments about that, to help put some context around such statements:
Canvas is a relatively new technology in FlightGear, and it not just a single technology, it's built on top of other technologies, like the Property Tree, ShivaVG/OpenVG, OSG and OpenGL. As you may have noticed, we didn't even mention Nasal yet - that's because Nasal scripting, strictly speaking, isn't even required to use Canvas - the whole thing can be used without touching any Nasal - just by using the property tree, the built-in httpd or even the telnet interface.
In theory, you could create a canvas just by setting properties, and even add placements (GUI/scenery/aircraft) by doing just that.
Canvas being a relatively new technology, we obviously still have to learn what works and what doesn't, and often that also means finding things that are too slow for some reason. And these days, there are easily a handful of abstraction layers involved, all of which may contribute to things being too slow. And debugging/profiling isn't always straightforward, especially when several boundaries are crossed (Nasal, property tree, C++, OSG/OpenGL).
But whenever we've seen dead-slow Nasal/Canvas code it was usually not the problem of Nasal or Canvas per se, but due the original code/implementation in the first place, including our own code by the way :D
Just because there are means available to add scripted graphics to FlightGear, doesn't mean that people automatically know how to use this technology properly.
For example, the very first version of the airport selection dialog was much slower than necessary, simply because it would redraw stuff unnecessarily, and not even use separate layers (canvas groups) for different features like airports, taxiways, runways etc.
Since then, we've learned a lot about using Canvas properly, but also about the combination of using Nasal and Canvas, including other subsystems.
So, as Canvas is a fairly recent feature, there's sometimes some really naive stuff done in various areas, that makes people think that Nasal and/or Canvas are generally slow.
However, that is not generally true. Aircraft like the m2000-5 or the extra500 are indeed fairly slow - not primarily because of Nasal/Canvas, but due a combination of factors, including several other FG technologies. And the 747 or 777 are slow even without any Nasal/Canvas code running; we can actually measure now how little impact our Nasal/Canvas code has, and how significant the impact is due to complex cockpit modeling (many polygons and high resolution textures). Understandably, under such circumstances, improper use of Nasal and/or Canvas may cause additional performance issues. And people may easily draw false conclusions under these circumstances.
Anyway, nobody should simply "port/convert" stuff like -for example- the Garmin196 to use Canvas, because that's exactly where all those problems come from: Canvas and Nasal themselves are simply too low-level for these purposes, people still need to be very experienced to come up with fast code here, very familiar with FG and certain Nasal technologies like timers and listeners (or the whole process inevitably involves lots of trial & error). Typically, that really only applies to core developers still, or fgdata committers who have extensively worked with both Nasal and Canvas over the years.
To use Nasal and Canvas properly, there are several layers that need to be understood, such as:
- Nasal
- Canvas scripting bindings
- Canvas elements (OpenVG paths, raster images, maps)
- FlightGear internals (navdb, timers, listeners etc)
- OpenSceneGraph
- OpenGL
Most people only understand #1 (well, partially), even though writing really fast code may very well involve looking at several layers in combination to see how they affect each other.
So writing "fast" Nasal/Canvas code still is quite an undertaking despite things being accessible from scripting space these days. And even our most experienced Nasal/Canvas contributors are still learning new things each day.
Which is exactly the point of having MapStructure and the NavDisplay frameworks: those are designed to handle things efficiently, e.g. by using smarter queries, smarter updates, and techniques like caching or selective/delta searches.
Imagine it like "Ruby on Rails" for aviation charts - that's what the whole MapStructure framework is all about: maps and charts.
The NavDisplay framework also used to be fairly inefficient in its early days - since then, we've significantly reworked it to use MapStructure. That first introduced some ugly hacks because we didn't want to rewrite it completely, but now its layers are mostly using MapStructure. And most of the original ND stuff has been refactored, generalized and integrated with the MapStructure framework, so that this very code can be used in other places, not just other aircraft, but also GUI dialogs.
Very fast Nasal/Canvas code will typically do very little at runtime/frame rate, but instead use pre-created data structures and dynamically toggle canvas layers on/off (show/hide groups) and update the underlying data selectively, while using cached images instead of having lots of identical OpenVG paths.
We've arrived at these conclusions based on testing and lots of profiling.
Frame rates >= 60 fps are not impossible to achieve like this - but coding such a design is obviously much more involved than simply drawing/updating once per frame, which is what people will typically do. This is very similar to people running timer callbacks at frame rate instead of using using split-frame loops or listeners to do certain computations and processing selectively. A simple design can get you only so far, but an efficient design requires much more thinking, and time to get right.
For instance, D-LEON has done quite some Nasal/Canvas benchmarking and confirmed that MapStructure/Canvas are sufficiently fast already (and we're still exploring additional options for making it even faster). Also, we're looking into augmenting/re-implementing certain features through native code additions, such as having dedicated extension functions, Nasal library functions or new Canvas extensions to make things even faster.
The key point here is that having a set of generic abstraction layers allows us to easily generalize, but also optimize, things - without having to rewrite all the places where Nasal/Canvas are used for mapping purposes. Things like the Avidyne Entegra R9 don't use the MapStructure framework at all currently - which also means that the code doesn't benefit from recent MapStructure optimizations unfortunately.
Imagine we were to optimize positioned queries (NavDB stuff like VORs, NDBs, airports etc) to become 50% faster - all instruments and dialogs using the MapStructure framework would get this speedup for free, while custom solutions would need to separately implement the optimized query. And that applies to pretty much any effort that doesn't favor a framework-centric development approach.
By the way, this is exactly the reason why the MapStructure framework lives under $FG_ROOT/Nasal, to help grow a shared library of fast components that can be easily reused, but also maintained - freeing aircraft and GUI developers from such chores and obligations, so that they don't have to track development and update all their own work in order to avoid breakage, but still benefit from recent optimizations. This is a lesson that we've learned from all the feedback that some of the most active airliner developers, like omega95 and redneck, have provided over time.
Unless someone is a really experienced programmer, working with "low-level" Nasal & Canvas for mapping purposes is probably not a good idea, because we already have a handful of people working on a single framework that is dedicated to just that, and we actually do regularly profile things and we're talking to the Canvas guys to sneak out more performance, better speed, less lag etc.
But whenever someone comes up with a custom mapping solution -solving the same problem that MapStructure and Gijs' ND frameworks solve- that doesn't use those frameworks, they need to do all the hard work from scratch, and code sharing/reuse and maintenance is made increasingly difficult, too. Basically, we end up "competing" without meaning to, by working on fairly similar projects, without coordinating our work to generalize and reuse existing solutions.
Which is why we talked with the Avidyne Entegra R9 developers to team up with us: their code is much more elegant than the original ND/MapStructure code, but the latter is much more generic (aircraft/instrument agnostic), and also fairly optimized already.
Admittedly, we already spent a while examining all the Avidyne Entegra R9 code there - we were kinda surprised seeing OOP code using design patterns solving a problem that we had been working on for several months. Actually, had we seen that code earlier, it would have been a much more mature foundation for a generic ND/MapStructure framework, because of its OO nature. But in the meantime, we've come up with something fairly generic - mostly thanks to Philosopher's MapStructure framework.
As mentioned elsewhere, if we could have had a look at the Avidyne code it would have been a great/better foundation for MapStructure and the ND framework - but we had to work off a completely different code base (several actually), so things are a little inconsistent and less elegant - but those frameworks are really designed to be generic, not just intended to be used with different aircraft, but also different GUI dialogs. And whenever we add a new optimized feature, all people/aircraft/dialogs using those frameworks will benefit automatically (backward compatibility is handled by US).
We literally depend on having many different use cases and front-end scenarios, i.e. for these two frameworks to evolve properly, we need many different aircraft developers to adopt them, do regular testing/profiling and provide feedback - and GUI use-cases are just as important. In fact, just for the sake of generalizing things, both frameworks contain support for being not just driven by the main/FDM aircraft, but even by AI aircraft.
Technically, MapStructure layers are a bit more sophisticated than having pre-created SVG/OpenVG groups, because symbols can be cached in a separate canvas via a texture map, so that there's true "instancing" support for each cached symbol. This is something that we've been working on in the last two weeks. Also, positioned queries are handled by an abstraction layer to ensure that things are sufficiently fast using selective delta-updating. Besides, the ND/MapStructure code was intended to be reusable right from the beginning.
Quite a few of the problems people, interested in mapping, are likely to encounter are already solved via MapStructure, i.e. identical paths for different symbols are simply instanced by using a raster image (canvas) as a cache.
The bottom line is: if there's someone who actually IS experienced enough to know how to write good and fast Nasal/Canvas code, that person should better team up with us, to help improve the generic framework, rather than develop some niche instrument or dialog that will only ever be used by a few aircraft, work that may never make it into fgdata.
Nasal & Canvas are really just tools, and tools can be misused obviously. Using them properly still requires certain knowledge, or slow code may result from it. We've been trying to make this easier by providing a few wrappers on top of Nasal/Canvas, that are intended to help with the creation of mapping displays, so that unnecessarily slow code can be avoided, while also allowing front-end code to directly benefit from optimized features.
Badly written code will remain slow no matter how optimized underlying technologies like Nasal or Canvas are, even if they should be completely replaced at some point. Those are algorithmic issues, and MapStructure/NavDisplay are intended to help people focus on non-algorithmic stuff.
|
|
Claiming that Nasal/Canvas would be "a failure as a tool" just because people can still implement slow code, is far too short-sighted - just because you are allowed to drive a car (or fly an airplane) doesn't make you an expert in car engines or airplane turbines - things like Nasal and Canvas are really just enablers, that are truly powerful in the hands of people who know how to use them, but that can still be misused by less-experienced contributors.
That is exactly why people are working towards more targeted frameworks on top of Nasal/Canvas - but it's a process that is very much still in progress, and probably will be for at least another 2-3 release cycles. Pointing out obvious shortcomings isn't going to help anyone though - certainly not as much as getting involved in one way or another
— Hooray (Fri May 30). Re: Does FlightGear has Multiplayer Combat mode?.
|
|
A Canvas-based Map dialog
As part of increasingly adopting our Canvas 2D rendering framework and in order to help Unifying the 2D rendering backend via canvas, the canvas-based Map dialog is currently being overhauled by Philosopher and Hooray, who are hoping to finalize this in time for 3.2 - the hard-coded Map dialog will obviously remain functional for at least one full release cycle until it can be phased out by a pure Nasal/Canvas based solution using the new MapStructure framework. Currently, this is all still just available in the canvas-hackers team clone on gitorious - but we're hoping to implement the main missing features within the next few weeks.
Currently, the amount of code required to display a full map dialog is surprisingly small, i.e. under 30 lines typically. Most of the other code is just about customizing appearance of the map and its various layers, i.e. styling.
Spare time permitting, Philosopher and Hooray may also explore porting Stuart's airport selection dialog to get rid of the original mapping helpers there and use MapStructure instead. However, this will be a bit more involved, as it requires updating and porting a few non-MapStructure layers that are currently not yet used elsewhere, including some of the more sophisticated layers, e.g. for drawing airports, runways, taxiways and parking spots/heliports.
One major addition that can already be seen in the screen shot below is that styling support is now becoming a key concept of the MapStructure framework, which means that symbols and appearance can be easily customized by non-programmers just by changing some values for things like font, font size, colors, line width etc. Sooner or later, we're also hoping to support replacing image sets completely, e.g. by using the vector artwork provided by Michat and pommesschranke.
Internally, the code rendering the screen shots shown below is 100% identical with the back-end code used by Gijs' NavDisplay for rendering mapping layers, and it's already making use of symbol instancing, i.e. caching, to support faster updates and better frame rates/performance. Also, we can already show multiple independent instances of such dialogs/maps/instruments at the same time.
Furthermore, we're also exploring the possibility of supporting interactive layers, these would be layers that respond to GUI events (mouse for now). Initially, this will be primarily needed for supporting zooming/panning functionality, which is already supported by the existing airport selection dialog. But we've also seen some interesting discussions on the forum about extending the new Canvas-based Map dialog to include navigation tools for flight planning purposes, like for example having an interactive protractor.
After reviewing the requirements to make this happen, we've come to the conclusion that we're almost there - the MapStructure framework can already load and display most SVG images, and animating them to respond to GUI events is also supported through Canvas - Event Handling. So it's really just a matter of integrating things a little more and coming up with some helpers for "interactive" or even "editor" layers, which should also come in handy for the FlightGear Missions and Adventures effort, an experimental layer has already been added to display tutorial targets as a conventional MapStructure layer.
Conceptually, it may even be possible to dynamically place 3D models via geo.put_model() by using an interactive MapStructure layer that turns screen coordinates into lat/lon pairs and uses them in the put_model() call. This could certainly be the foundation for a run-time object placement tool, e.g. for placing scenery models or even AI traffic, which should come in handy for the Tutorials system, the advanced weather system or even the Bombable add-on.
The upcoming Canvas/MapStructure based dialog (purely scripted)
Philosopher's new FLT (flight path/history) layer for the MapStructure framework (flight path exposed to Nasal by TheTom)
The new Canvas Map dialog showing the waypoint/route layers originally developed by Gijs, and now ported to MapStructure by Philosopher
Gijs' original wxr (storms) layer ported to Philosopher's MapStructure framework (still experimental)
Missions & Adventures
FGTAM - FlightGear Tutorials, Missions & Adventures has received an assorted set of icons created by Michat in order to support with standard vectorial graphics the broad range of options that this collaborative code effort and technology can offer to the FG Project.
Here are shown some examples of icons that have been created.
 |
The FlightGear forum has a subforum related to: Tutorials, Missions & Adventures |
Getting your own ideas into FlightGear without having to be a programmer
We've been seeing an increasing number of discussions on the forum started by people who are obviously eager to become potential contributors, either by adding new features to FlightGear, or by improving other aspects of FlightGear as a whole (community, infrastructure, usability, end-user support, accessibility, funding etc). Unfortunately, this has caused some friction over time, because people were expecting their involvement to work differently, especially those primarily making suggestions and providing feedback through discussions are obviously getting fed up with the community of contributors not responding directly to such feedback.
Now, we do appreciate any community involvement obviously, but people who are serious about actually bringing certain changes to FlightGear will find that just making suggestions will typically not work too well, and that just participating in lengthy community discussions is usually fruitless. We've had some extremely heated discussions over the years, some debating interesting ideas - and many ending up being dozens of pages in size, containing hundreds of postings. Often, these contain lots of good ideas and suggestions, but sooner or later these suggestions become emotional and are no longer constructive - yet, we're dealing with them constantly, which is taking up resources, i.e. time and energy. In an open source project like FlightGear, which is entirely volunteer driven, time is the most precious resource we have to contribute. It is like a "currency" for the project, and whenever something (or someone) is taking up lots of time without anything materializing, this is draining resources from other areas, no matter if it's end-user support or development in some shape or form.
We are now trying to document how "bootstrapping" a feature or project works conceptually, i.e. implementing new features for Flightgear - to provide a perspective that enables people to better understand how to bring changes to FlightGear without having to do all the work on their own. Note that this doesn't mean that this is the only way to accomplish something, but this is a tested and proven way - which we didn't come up with, but which is just a convention that happens to "just work", which is an important aspect for a non-organized project like FlightGear, where development itself also primarily "just happens".
Continue reading at Implementing new features for FlightGear...
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.
FlightGear's built-in Nasal scripting language comes with a set of standard libraries, and can be extended using FlightGear specific APIs.
Exposing simulator internals to scripting space is a fairly common and useful thing, because it enables base package developers to access these internals without having to build FlightGear from source, so the barrier to entry is significantly lower and we've seen an increasing number of novel features purely implemented in scripting space, due to powerful APIs being available to aircraft developers and other base package developers.
Until FlightGear 2.8, the Nasal scripting engine only provided a C API to expose such hooks/bindings to scripting space or to expose scripting space data structures back to C/C++.
Unlike the core Nasal engine itself (which is C), FlightGear however is mostly written and being developed in C++. For quite a while, that meant that the Nasal APIs were a bit low-level, and sometimes also awkward to use when making functions, data structures or objects accessible between C++ and Nasal.
Thanks to development on Tom's Canvas system, there's now a new bindings framework to be found in $SG_SRC/simgear/nasal/cppbind. This is fully object oriented and supports modern C++ features by operating through classes and methods with full STL support, abstracting most common operations away.
After working through the Nasal/CppBind article, some of the more useful things to play with in the beginning, would be exposing additional SG/FG classes to Nasal space, such as for example:
Done
- SGPath
Done (by TheTom) - SGCondition Done (by TheTom) flightgear/flightgear/1b55ab5f4032c6f3f1a4d07c0b9babd3744f1c37 commit view
Work in Progress
- SGPropertyChangeListener
Pending (suggested by Zakalawe & TheTom) [3] 
|
|
This and using maketimer instead of settimer should reduce the number of leaked resources a lot, because you would not be able to accidentally leak listeners/timers anymore.
— Thomas Geymayer (2014-11-22). [Flightgear-devel] RFC: Nasal ghosts and garbage collection.
(powered by Instant-Cquotes) |
|
Autopilot/Property Rules
| Note This is a summary of all discussions about exposing the autopilot/property-rule system (there are certain Nasal GC issues, so that we ask people not to implement FDM-coupled Nasal code like autopilots): this would be the best way to decrease the amount of Canvas-related Nasal code, i.e. by using property-rules for animation purposes, as per Torsten's RBAR EFIS [4] and TheTom's system-modeling plans.
|
|
|
The quantity of details and system modeling that goes in to covering all the aircraft of the world is impossibly complex. The idea is to put as much support for common/shared systems in C++ as we can and then make it possible to stitch these systems and details together and configure them with xml in a wide variety of ways to create aircraft. But we can never anticipate every system in use, and we can't anticipate the level of detail or feature set that every aircraft developer might want to implement or experiment with, and even if we could there would be no way to model everything in the world in a single application. Nasal gives a lot of flexibility to cover those unanticipated gaps and it allows aircraft developers to push in new areas ahead of the C++ coverage.
Now in many cases, aircraft developers were happy with the nasal implementation and called it good enough. Many aircraft developers have become proficient and comfortable in nasal and prefer doing their work there. — curt (Dec 16th, 2015). Re: Military simulation (from Su-15 Screenshots).
(powered by Instant-Cquotes) |
|
|
|
Nasal does have an advantage in that it is easier to tailor to specific requirements. So, providing that the CPU overhead is acceptable, this may be a preferable method for many aircraft.A C++ coded module is fixed in stone, but nasal and xml modules are far easier to modify/overload on a per-aircraft basis.As I am modelling a 1960´s military bomber I have quite a number of (very) aircraft specific requirements which are not met by the current RM/GPS code which is targeted at present day commercial usage. |
|
|
|
I would prefer to do this in an XML filter in the generic autopilot helpers - definitely not in Nasal. It can be done in C++ if strictly required but then we need way to disable it for people who want different filtering.
— James Turner (2015-04-03). Re: [Flightgear-devel] Route manager: waypoint smoothing.
(powered by Instant-Cquotes) |
|
|
|
I vote for #3: avoid *any* Nasal in the fast simulation [FDM] loop. Nasal execution is slow and non-deterministic. Running it in the fast simulation loop is the last thing we want.
— ThorstenB (2012-08-29). Re: [Flightgear-devel] Running Nasal at simulation rate.
(powered by Instant-Cquotes) |
|
|
|
Concerning your original issue on implementing an autopilot: a much better way to do it is to avoid Nasal for the actual autopilot controller elements (numeric computation). Instead, use XML "autopilot" rules for the filter, gain, damper, integrator elements: Autopilot Configuration Reference
You can then use Nasal for the high level stuff, and enable/disable/switch the individual controller elements (e.g. in order to automatically switch the autopilot mode when capturing the ILS). — ThorstenB (2012-08-29). Re: [Flightgear-devel] Running Nasal at simulation rate.
(powered by Instant-Cquotes) |
|
|
|
This is also how such things are done in the real world: controllers aren't implemented in imperative programming languages these days - especially not in scripting languages. People use model-based design and connect controller elements - using graphical tools like MATLAB/Simulink. Obviously, FG is missing a graphical interface to specify the controller rules - but the idea of specifying through XML is the same and specification is straight forward.
— ThorstenB (2012-08-29). Re: [Flightgear-devel] Running Nasal at simulation rate.
(powered by Instant-Cquotes) |
|
|
|
I agree with your main point that xml-configured hard-coded filters are the right way to implement and autopilot, and I also agree that in general low-level multi-purpose workhorse code should be C++ whereas Nasal is more suitable for the numerically cheap high-level specific functions.
— Renk Thorsten (2012-08-30). Re: [Flightgear-devel] Running Nasal at simulation rate.
(powered by Instant-Cquotes) |
|
|
|
it should basically resemble the C++ 3D animation system and be invisible (enough) that it could easily be replaced with more C++ should we need more performance (or just 'cause). Exposing SGExpression to Nasal would be helpful soon but not necessary yet.
|
|
|
|
Given that a very simple animation system would mainly need to deal with "events/triggers" (i.e. timers & listeners) and "actions", we might even be able to reuse some of galvedro's sophisticated failure management modules, because those already deal with both concepts via the property tree (sent a heads-up to him for some feedback).
|
|
|
|
I'd strongly agree with Thorsten here. It's nothing against Nasal from me - I've not even used it - but creating an autopilot (or any GNC or system model, for that matter) can be done very effectively with discrete objects such as summers, gains, controllers, filters, switches, etc., much as JSBSim has done with the system components. This is a standard approach in industry as Thorsten mentions as exemplified by Mathwork's $imulink product.
Scilab/Scicos is similar in concept. Control system topologies are often diagrammed in a way that can lead to a one-to-one correspondence between a block and a control system object that can be referenced in an XML file, if the control system component library has been defined properly. This, again, is the way that JSBSim has approached the solution. Some benefits to such an approach include (IMHO) better testability, more predictability, and easier interface (someday) with a GUI tool, should one materialize. The downside is that XML can be verbose, but it's a price I've come to accept. — Jon S. Berndt (2012-08-30). Re: [Flightgear-devel] Running Nasal at simulation rate.
(powered by Instant-Cquotes) |
|
|
|
I have recently committed some code to allow runtime loading of property rules and have a Nasal binding for that in mind.
|
|
|
|
The more I think about it, the more I am leaning towards unifying the different system modeling blocks in the C++ core under a generic interface that is exposed (or linked in some way) to Nasal. Think the PID controller, the different filters, flip-flops, etc. They are not substantially different to the basic bricks I am writing...The basic idea would be to detach those blocks from their specific application (autopilot, for example) and refactor them into an independent library with bindings in Nasal and a similar interface to what I have been showing so far. The end result would be quite simulinkish in flavour. It is already starting to smell a bit to that actually... :D
An architecture like that would eventually enable three possible approaches to system modeling: low level C++, static xml driving C++ underneath and fully scripted Nasal. — galvedro (Tue Nov 05). Re: A general approach to systems modeling in Nasal.
(powered by Instant-Cquotes) |
|
|
|
Regarding things like the PID controller code, its developer/maintainer (Torsten) was actually planning on making this stuff accessible from Nasal, just to prevent scripters from implementing APs in Nasal (due to garbage collection issues) - so that should be a no-brainer actually, and such work should be appreciated
— Hooray (Tue Nov 05). Re: A general approach to systems modeling in Nasal.
(powered by Instant-Cquotes) |
|
|
|
there's an extremely powerful and flexible autopilot system in FG that is entirely XML configurable: Autopilot There's also a very powerful route manager. Please note however, that there's currently no support for AI traffic to directly make use of the autopilot system or the route manager, so you need to come up with your own infrastructure in scripting space. |
|
|
|
Note however that scripted AI traffic cannot currently make use of any hard-coded FDMs/AP/RM functionality (JSBSim/YaSim), instead you need to come up with your own "pseudo systems" in scripting space unfortunately.
|
|
|
|
The AI traffic system has its own "route manager" system which is currently not yet compatible with the rest of FG unfortunately. But there are plans in place to fix this eventually: [5]
|
|
|
|
At the moment, Durk has already implemented his own "custom" AI FDM logic, exactly like David predicted a decade ago
|
|
|
|
You can probably find 50+ postings by long term contributors suggesting that AI traffic with FDM support would be a good idea: An_Integrated_AI_Traffic_System#FDM_driven_AI_Traffic
|
|
|
|
When you then take into account that you will probably not need to run the AI traffic FDM at a rate of 120 hz (the FlightGear default), but much more likely at 1-5 hz (at most), you should be able to multiplex at least 20-30 different aircraft onto one dedicated FDM thread (or process).
|
|
|
|
you would need to hack the autopilot code so that autopilot configurations can be loaded and created dynamically. At the moment, the autopilot code makes the fixed assumption that there's only a single "main aircraft", so it doesn't know about more than one aircraft.
|
|
|
|
if you wanted to equip your AI traffic with a working route manager, autopilot or even FDM, you would also need to instantiate these subsystems dynamically
|
|
props.nas
|
|
ne thing I thing I want to achieve with this changes is to make the Nasal props API more similar to its C++ counterpart as this makes it easier to use if you are using both the C++ and the Nasal API. Also someday I want to refactor nasal-props.cpp to use cppbind, where I want to export as much methods as possible with exactly the same signature than in C++. Especially if using properties seldom (eg. only for initialiation) the relative versions are probably even faster, as the Nasal overhead is lower. Eg. consider the following Nasal code used to initialize some module: var cfg = props.globals.getNode("/my/config/root", 1); var x = cfg.getDoubleValue("x"); var do_it = cfg.getBoolValue("do_it"); Using getprop on the one hand does not allow getting a property converted to a given type and on the other hand is tedious to use for more than one property, as one has to assemble the according property paths (which is definitely less efficient than using a relative method). — Thomas Geymayer (Apr 14th, 2013). Re: [Flightgear-devel] Nasal props API relative path support.
(powered by Instant-Cquotes) |
|
Candidates
- environmental sounds [6]
- simgear::PropertyBasedElement (background/motivation)
- for better diagnostics, and better end-user bug reports, we could consider exposing a cross-platform process and system utilities module via Nasal/CppBind, such as e.g. SIGAR (Windows, MacOS & BSD/Unix)
Not done - Airways/Airspace boundaries don't seem to be exposed via NasalPositioned currently? [7] [8]
- FGProtocol, to implement I/O protocols via Nasal (and help solve ticket #396 and support AJAX, REST, JSON or WebSockets)
[9] [10] [11] (stubs available at gitorious/fg/hoorays-flightgear/topics/cppbind-fgprotocol). - the loglist/SG_LOG() logging buffer machinery [12] [13]
- expose VoiceSynthesizer/FLITE TTS[14] to Nasal to get rid of ATC chatter [15] Not done
- the SGSubsystem interface to register scripted SGSubsystems
- flight path history [16] Done (by TheTom)
- the flight recorder system (replay buffers) Not done
- State machines e.g. to help clean up the ND code [17]
- exposing the sound manager, so that scripts can directly play audio files [18]
- exposing the random buildings system [19] [20] Pending [21] [22]
- There's also a pending feature request (ticket #619) to implement USB-HID support [23] .
- ESRI shapelib? [24]
|
|
When we have vector road data at runtime, we can do the following:
— James Turner (2014-11-21). Re: [Flightgear-devel] Future city terrain strategy.
(powered by Instant-Cquotes) |
|
- effects framework ?
- Howto:Using OpenCL in FlightGear
- Nasal/HLA bindings, so that we can run certain scripts as HLA federates outside the fgfs process space (such as bombable or local weather)
|
|
Specifically, there are some C++ data structures that still need to be exposed to Nasal via cppbind so that we can implement features available in the Map dialog and the hard-coded ND |
|
| Note Before working on anything related, please do get in touch with other contributors to ensure that this list is still up-to-date.
For more technical Nasal questions (C API, internals etc), you'll probably want to refer to Philosopher, TheTom, Zakalawe or Hooray on the forum - TheTom and Zakalawe can also provide help on using cppbind, having both used it extensively during the last months. |
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.
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. |
And finally ...
Contributing
Many people think that contributing to the FlightGear project requires writing C++ code or doing 3D modeling and that it takes lots of time, and therefore feel that they cannot contribute directly. Not so. There's a whole variety of ways to make a valuable and satisfying contribution to FlightGear without being a developer.
The Volunteer page is intended to provide a starting point for those wanting to contribute, but who don't know how. Of course, these are just suggestions. So if you have already a specific idea in mind, please do get in touch with the community to ask for feedback, using the mailing lists, forum or the IRC channel (chat).
Remember that work in non-development areas will be appreciated as much as developer contributions (or more!), because generally more visible to the end user.
If you'd like to learn more about getting your own ideas and features into FlightGear, check out Implementing new features for FlightGear.
If you are contributing to the core simulator, or an aircraft in the master repository, you should be part of the FlightGear-devel mailing list, which is the primary point of contact for all discussions regarding the development of the simulator. You may want to check out also Howto: Understand the FlightGear development process and Howto: Starting core development.
Call for volunteers
- 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.
- The Target4Today team is looking for volunteers to help improving FlightGear's combat support