Atmospheric light scattering FAQ

From FlightGear wiki
Jump to navigation Jump to search

Technically, Atmospheric Light Scattering, ALS, is a forward rendering framework for FlightGear, supplying a series of GLSL shader effects with consistent position-differential lighting and fogging for the whole scene.

Conceptually, ALS serves to make the Flightgear visuals realistic, committing the computing power of the graphics card predominantly to what a pilot gets to see most during flight, i.e. chiefly visuals in the air, from the cockpit. Primarily this is, as the name suggests light scattering in the atmosphere on the air and haze and visuals of sky and clouds, then hires dynamical texturing of the terrain and finally support for effects on 3d models. Things like aircraft shadows or secondary lights, the speciality of Project Rembrandt are minimally supported by ALS since they are relevant primarily on the ground and cost a lot of performance.

I am an aircraft developer, how do I make use of ALS effects?

Like any rendering framework, ALS has a simple default technique to render models. For more interesting effects (normal, reflection or dirt maps) it supports the Model-combined effect which is also supported by the other rendering frameworks (default and Project Rembrandt).

In addition, there is support for several ALS-specific effects: hires grain overlay, raindrop splashes, simple aircraft shadows, canopy glass and shading of the cockpit interior. These are documented in the ALS technical notes.

I am a custom scenery developer, how do I make use of ALS terrain texturing?

ALS has extensive support for Procedural Texturing which is xml-configurable in the (regional) materials file.

Why does ALS not make use of the light technology project Rembrandt provides?

The short answer is - because there's only so much performance to be had from a graphics card.

Many real-time rendering techniques can not simply be switched on and off as needed, they need supporting technology. For instance, deferred rendering needs additional camera passes over the scene to fill various buffers - and these passes cause a significant performance drain - regardless of whether one actually needs a light or not.

ALS has made an (intentional) choice to spent the available power of the graphics card on computing a good approximation of real-time light scattering physics in the atmosphere and on procedural terrain texturing rather than multiple passes. There is also the (equally intentional) design choice that whatever effect can be pre-computed beforehand should be computed beforehand and not on a per-frame basis (which is as a rule both faster and gives better visuals). For instance, the quality of cockpit lighting done by a raytracer taking essentially infinite time to follow multiple reflections is much superior to what deferred rendering can compute in 1/60 of a second - and using this in a lightmap takes a small fraction of the performance.

Example of a raytracer generated lightmap for the Space Shuttle cockpit

As usual, implementations are a tradeoff between visuals, performance footprint and implementation friendliness and it is impossible to maximize all three at the same time. The guideline for ALS has been to consistently allocate most performance for what is seen most during normal use of the sim (e.g. in cockpit visuals are more important than external visuals, views from the air are more important than close-up ground views,...) and that implementation friendliness is not a design criterion since this saves a lot of performance (aircraft maintainers are required to pre-compute effects rather than add a few lines of xml).

I think ALS really should have effect XY - what should I do?

Create a performance-friendly implementation of it and submit a patch providing the effect announcing it on the mailing list. Or, if you can't do that, try a polite question.

Please don't point to other sims having effect XY and claim we should be able to have the same - that's quite often not true because FG operates with its own constraints (compatibility, scenery framework, basic rendering architecture,...) and never helpful.

Why is the effect XY available under ALS but not in another rendering framework?

Usually because the maintainer of the other rendering framework was not interested in implementing it.

Why is there no motion blur, lens flare or bloom available?

Because these are artistic effects, whereas ALS is intended to be a physics-driven rendering scheme trying to get close to reality. Simply put, such effects are video-game codes for some situations, but in reality they eye does not see blurred motion, bloom or lens flare - only a camera does.

ALS aims to incorporate effects which are genuine to real eye perception (such as the apparent blue hue of very faint light caused by the fact that blue color perception remains sensitive the longest), but not artistic representations of reality.

Effect XY really looks ugly under some conditions - why is that?

A good example for this is the urban relief effect which looks poor under shallow view angles, another the tree shadows which can 'hang' over a precipice.

Real-time 3d rendering is the art of illusion - trying to render it 'for real' would take far too long. So it's not a matter of 'if' the illusion breaks but of 'when' - and that correlates with performance footprint.

A fairly frequent situation is that one can design something that works for 99% of use cases and takes some performance. Making it work for 99.9% of use cases might take a factor 100 more performance, making it work for 99.99% a factor 10.000 - taking special cases into account quickly requires vastly more expensive techniques.

So there's a line drawn somewhere. For instance, the urban relief shader is a great way to generate the illusion of many buildings from high up, but if you look into the math of Relief maps, you discover that it can't work under shallow view angles. It's equally possible to put explicit 3d models of buildings into the scene - but in the same numbers, they become vastly more expensive to render - though they work from any angle.