FlightGear Newsletter September 2012: Difference between revisions

== Development news ==

=== Random Buildings ===

Shortly after the 2.8 release, a number of users reported severe memory growth issues related to a new feature: [[Random Buildings]].

=== Canvas System ===

Work has now started to develop a dedicated Nasal module specifically for [[Canvas Maps|mapping/charting purposes]]. A first proof of concept is available in $FG_ROOT/Nasal/canvas/map.nas, but we expect to commit more changes (and a real API) soon. Initially, we'll be collecting all related features in a single "map.nas" module, and refactor/improve things later on.  

With these changes in place, it is already possible to directly show a SVG image for each waypoint and connect them using OpenVG paths, even without separate "icon" support.

=== Usability Improvements ===

Aircraft typically have a large number of checklists, covering almost every phase of flight.  Previously, aircraft authors have added checklists to the help text for the aircraft.  This is a bit unwieldy.  To improve matters, there is now an Aircraft Checklists dialog under the Help menu specifically designed to organize and display checklists.  Aircraft authors can create new checklists easily without having to worry about how they will be displayed.  See [[Aircraft Checklists]] for details.

==== Integrated Documentation Browser ====

Often, especially new FlightGear users are not aware of all the documentation that comes with FlightGear. While the manual is fairly easy to find and pretty accessible (being a PDF file), most of the other documentation in $FG_ROOT/Docs is hardly easy to find and often pretty inaccessible to new users, even though these files are standard text files, because of the non-standard file extensions used by most README* files there.  

That's why we have now added a new built-in dialog to FlightGear which shows most plain text files in $FG_ROOT/Docs directly inside FlightGear, without having to start any other applications.

== Interview with a contributor (Thorsten Renk) ==

''In each edition we have an interview with a contributor. Suggestions for possible questions are available on [[interview questions]], you are invited to come up with new questions and interview ideas obviously! Anyone is free to write an interview (with him-/herself or others) for next month's newsletter! If you'd like to help interview a contributor or get interviewed, please do consider adding yourself to the [[list of interview volunteers]]! To keep this going and less awkward, we are currently trying to come up with the convention that former interviewees become next month's interviewers.''

Since late 2009.

In the broadest sense, modelling of the environment. I've started out modelling clouds and weather, then as I discovered shaders I've also included dust, haze and light scattering effects, and of late I am into improved ways of texturing the terrain.

All these areas are related, so it's actually pretty powerful if the same person knows how to affect all of them - for instance, on a rainy day, we not only see an overcast cloud layer, but also the light beneath the clouds is dimmed, the sunrise has a different color hue, the ground is wet and hence darker than usual and there may be water on the ground. Being able to do all these things with the same environment model is pretty cool.

Procedural texturing, i.e. computing the texture mix to be displayed on the terrain inside the shader code - this allows for effects which would be impossible to achieve with the standard way of assigning textures due to the huge memory footprint.

Who knows? I have plenty of things I would like to do and in principle know how to do - the problem is just making them run fast enough. It's pretty amazing how fast a graphics card can crunch numbers, but there are limits eventually. And basically every day, looking out of the window and observing the richness in detail on a real sky, I see how inadequate even our most advanced shading models really are. It's amazing how nature solves all the rendering equations in real time.

Mostly. I know many people think FlightGear should have a project structure which works more like a commercial project, i.e. with clearly defined project goals and well-defined tasks. Rather, it is a somewhat anarchic collection of different individual projects merged together, often with multiple ways to solve the same problem (we support as many as four different ways to generate clouds for instance) which makes it not always easy for new contributers in need of a feature. But, coming from a research environment, I actually feel quite at home with such a development model - science works the same way, and for instance, while having several independent ways of doing the same thing can be seen as a waste of resources, it can also be seen as a feature - we explore many different ways of doing things which helps us find the best solution.

What I don't like is that there is often a lot of friction - for instance 3-D modellers feel underappreciated since most of the project decisions are made by the coders, there's an ongoing controversy between scripting space (Nasal) and C++ coding, and there are contributors of world scenery vs. custom scenery creators. While some level of discussion seems useful to me, related discussions often reach a point which I find no longer productive.

The same thing Tolkien enjoyed about writing 'The Lord of the Rings' - the possibility to do subcreation. The visible FlightGear scenery is a world to explore, and this world is directly and visibly influenced by code I write. I can place myself high up in the air, look down and wave my mouse - and a whole layer of clouds appears. I get to decide what color the sunrise has. That's pretty fascinating as far as that goes.

And actually, I've always enjoyed flying through clouds in flight simulators - in the early ones, they were just so bad, but now I can make them just the way I've always wanted them to be. Flying between two scattered cloud layers is still one of my favourite activities.

Plenty. Several I decided not to release since they are too tricky to control, so flags switch them off. For instance, there's a working model for wave lift in the Advanced Weather code, but there is no code to automatically place it (that's much more tricky to develop), so the wave needs to be placed by hand with a suitable line of Nasal. There are experimental cloud layer definitions which are just too expensive to render on a normal system. Many things I just try, and when I find no good way of implementing them, they stay in the code in a de-activated mode.

Be patient. The world doesn't revolve around you, but good work is recognized eventually.

I know it looks pretty unwelcoming if someone wants to contribute and needs to go a long way before getting help. On the other hand, I know the other perspective of investing a lot of work into someone's project, just to see the other person disappear and all that work being lost. So I understand much better that established developers want to see that someone is serious about what he proposes to do before they jump in.  

== Translators required ==

|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 [[:nl:Help:Vertalen|Help:Vertalen]].

|}

== Scenery corner ==

The creation of the scenary is still an on-going project. Additional information and temporary data files can be found at [http://flightgear.creatuforo.com/-temas30521.html?sid=976c97a07264ae7e75b15fbee03373a0#30521 Vive FG!]

== Community news ==

== And finally ... ==

=== Contributing ===

* The [[FGFSPM]] (FlightGear Package Manager) is looking for a new maintainer.