Atmospheric light scattering FAQ: Difference between revisions

From FlightGear wiki
Jump to navigation Jump to search
No edit summary
Line 25: Line 25:
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).
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? ===
== 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.
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.

Revision as of 08:18, 30 September 2016

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.