ALS technical notes
Quality level mapping
The rendering quality of ALS effects is controlled by two main sliders, landmass effects and transition effects. Transition effects regulate overlay texturing quality whereas landmass effects regulate all other aspects of procedural texturing like pixel color postprocessing (dust, snow or wet terrain effects) and apparent terrain roughness (bump and parallax mapping).
In addition, specific effects for certain terrain types (water, urban, forest, agriculture...) and models in the scene can be switched on separately. In some cases this may be needed for a consistent visual impression: If a dust effect is used on the terrain, water needs to be rendered using a separate water shader, otherwise it will appear dusty as well. Likewise, if the Rayleigh haze is used in the highest quality terrain effect, then the highest quality water effect needs to be used to see the same Rayleigh scattering effect on the water.
For technical reasons (landmass and transition control the same shader code) the settings are sometimes mutually dependent, i.e. transition quality level 6 won't have any effect unless landmass quality is also level 6.
Transition
The mapping of quality to visuals of the transition slider is
1:
- Base texture scheme
2:
- Alternative hires airport keep effect
3:
- Base and overlay texture, runway effect (if landmass > 4)
- Supports secondary lights on runway and airport keep
4:
- Base, overlay and hires texture
6:
- Base, overlay, hires, detail, grain, dot and rock texture (if landmass > 6)
Landmass
(Quality levels 1 and 2 are reserved to represent fixed pipeline rendering and the classic FG default renderer in an eventually merged rendering GUI, currently however ALS is switched on per checkbox and not by quality level, so they do not have a function).
3:
- ALS-rendered position-differential haze and light, moonlight
4:
- Procedural snow cover on terrain
- Procedural dust and vegetation effects
- Wet terrain effect with approximate reflection half vector
- Patchy fog distribution
5:
- Noise bump-mapping and parallax mapping of terrain
6: (requires transition 6 as well)
- Wet terrain effect with correct reflection half vector
- Hires bump mapping and snow patchiness
- Variable upper haze layer surface
- Rayleigh haze
- Secondary lights on all terrain types
- Slope line and strata effects
ALS secondary lights
The ALS framework supports a generic implementation of landing lights and a searchlight which are based on a framerate friendly computation in screen coordinates, i.e. the lights project correctly only if the light is close to the viewer (typically, that'd be from cockpit view). In other words, this is not a full (rather expensive) computation of light volumes as Rembrandt does it but a much faster test of illuminated screen areas.
Two landing lights and a searchlight are supported. The landing lights have a fixed position with respect to the aircraft axis (technically, with respect to the default view axis as defined in the respective view), whereas the searchlight follows any offset of the view axis in view mode, i.e. when using the mouse to look around, the searchlight will follow the motion, the landing lights will not. The lights require ALS to run above basic quality level and work on runway and airport keep above transition setting 3 and everywhere else only at highest quality setting. All lights are controlled via properties in /sim/rendering/als-secondary-lights/.
The names of the properties should be self-explanatory, if for instance if use-searchlight=true then the searchlight (which always follows the current view axis) is used.
The properties landing-light1-offset-deg and landing-light2-offset-deg allow to specify angular offsets for the landing light which are then not centered on the view axis. This can be used to simulate one or two landing lights set in the wings.
The lights can be switched on and off from the property browser for any aircraft without any modifications to the aircraft definition. Implementing them correctly aircraft side thus just involves linking the landing light switches to the ALS control properties and setting the correct angular offsets. Additionally, it is recommended to switch the lights off unless in a cockpit view, as they don't project correctly for any external view.
Range, color, light cone opening angle or intensity of the lights can currently not be configured, and there are no plans to support such a feature in the near future.
All three lights will illuminate fog (if dense enough) and precipitation.
The grain texture and the rain effect
ALS supports a grain texture for models. This is a semi-transparent overlay texture that works just as its equivalent for terrain texturing and provides the option of generating cm-scale details such as rust or discoloration on a surface without having to use huge textures. An example of a surface rendered with grain texture is the Vinson flightdeck below:
This is done using the following effect declaration inheriting from model-combined-deferred.eff as
<?xml version="1.0" encoding="utf-8"?>
<PropertyList>
<name>flightdeck</name>
<inherits-from>Effects/model-combined-deferred</inherits-from>
<parameters>
<grain-texture-enabled type="int">2</grain-texture-enabled>
<grain-magnification type="float">0.1</grain-magnification>
<rain-enabled type="int">2</rain-enabled>
<texture n="7">
<image>Models/Geometry/Nimitz/rust_texture.png</image>
<type>2d</type>
<filter>linear-mipmap-linear</filter>
<wrap-s>repeat</wrap-s>
<wrap-t>repeat</wrap-t>
<internal-format>normalized</internal-format>
</texture>
</parameters>
</PropertyList>
The grain texture has the number 7 and needs to be enabled by
<grain-texture-enabled type="int">2</grain-texture-enabled>
If the value is set to 1, the grain texture uses the uv-mapping of the underlying surface. If that is very irregular (as in the case of the Vinson flightdeck), alternatively the grain can be mapped in xy-model coordinates if the parameter is set to 2, the uv-mapping of the base texture layer is then discarded.
The resolution of the grain texture with respect to the base coordinate layer is specified by
<grain-magnification type="float">0.1</grain-magnification>
If the number is < 0, the grain resolution is lower than the base layer, if the parameter is > 0, it is higher (note that in the above case, the grain is mapped to (xy) rather than (uv), hence the base size is 1 m, so the grain texture is mapped on a 10x10 m patch on the flightdeck), for which a 1024x1024 pixel texture provides ~1 cm sized details).
Finally, any number greater than 0 passed to
<rain-enabled type="int">2</rain-enabled>
enables the splash effect of raindrops on the surface if it points upward. The surface does not have to be flat for this to work, the effect checks for the surface normal automatically, see the rain enabled for the Citation Bravo.
Thorsten noted about rain splashes: "Works fine here - runway needs to get really wet though before you see them (put the environment slider to max to achieve this quickly, it will take some waiting with just rain on)."
ALS fuselage shadow effect
ALS supports the manipulation of a (simplified) ground shadow. This effect uses an existing simplified shadow animation configuration and by default uses the gear-agl-m property to calculate the ground placement of that simplified shadow.
The effect can be applied easily in any aircraft that report the gear-agl-m property by simply adding a declaration inheriting from shadow.eff.
If the aircraft does not support the gear-agl-m property, (notably JSBSim), you need to create a Property Rule to pass a supported AGL data to the gear-agl-m property. In this case we use altitude-agl-ft converted to meters using a property rule configuration file.
For the first example we'll use the "supported gear-agl-m" method for aircraft that don't require a property rule.
Simply add the following inheritance declaration after you declare your shadow animation statement.
<effect>
<inherits-from>Effects/shadow</inherits-from>
<object-name>name_of_the_shadow_object</object-name>
</effect>
In the non-ALS simplified shadow code you normally use a "translate" animation to position the shadow on the ground. When using the ALS method you must either remove, comment out, or apply a condition to restrict its use to non ALS shadow applications, because ALS is responsible for computing the shadows ground position.
Here is how we apply a condition to the translation to limit it effect to non-ALS application only.
<!--Translate to ground level -->
<animation>
<type>translate</type>
<object-name>shadow</object-name>
<condition>
<not>
<property>/sim/rendering/shaders/skydome</property>
</not>
</condition>
<property>/position/altitude-agl-ft</property>
<factor>-0.3048</factor>
<center>
<x-m>0</x-m>
<y-m>0</y-m>
<z-m>0</z-m>
</center>
<axis>
<x>0</x>
<y>0</y>
<z>1</z>
</axis>
</animation>
A complete shadow animation block looks like this.
<PropertyList>
<animation>
<!-- opaque objects -->
<!-- transparent objects -->
<object-name>shadow</object-name>
<type>select</type>
<condition>
<not>
<property>/sim/rendering/rembrandt/enabled</property>
</not>
</condition>
</animation>
<effect>
<inherits-from>Effects/shadow</inherits-from>
<object-name>shadow</object-name>
</effect>
<animation>
<type>noshadow</type>
<object-name>shadow</object-name>
</animation>
<!-- pitch -->
<animation>
<type>rotate</type>
<object-name>shadow</object-name>
<property>/orientation/pitch-deg</property>
<factor>-1.0</factor>
<center>
<x-m>0</x-m>
<y-m>0</y-m>
<z-m>0</z-m>
</center>
<axis>
<x>0</x>
<y>1</y>
<z>0</z>
</axis>
</animation>
<!-- roll -->
<animation>
<type>rotate</type>
<object-name>shadow</object-name>
<property>/orientation/roll-deg</property>
<factor>1.0</factor>
<center>
<x-m>0</x-m>
<y-m>0</y-m>
<z-m>0</z-m>
</center>
<axis>
<x>1</x>
<y>0</y>
<z>0</z>
</axis>
</animation>
<!--Translate to ground level -->
<animation>
<type>translate</type>
<object-name>shadow</object-name>
<condition>
<not>
<property>/sim/rendering/shaders/skydome</property>
</not>
</condition>
<property>/position/altitude-agl-ft</property>
<factor>-0.3048</factor>
<center>
<x-m>0</x-m>
<y-m>0</y-m>
<z-m>0</z-m>
</center>
<axis>
<x>0</x>
<y>0</y>
<z>1</z>
</axis>
</animation>
</PropertyList>
For aircraft requiring a Property Rule there are a couple extra steps.
In aircraft-set.xml you add the property rule call to the "configuration file" in between the PropertyList/sim/systems tag pairs.
<property-rule n="101">
<name>gear_agl-m</name>
<path>Aircraft/c172p/Systems/gearAGL.xml</path>
</property-rule>
Note: the n="101" needs to be =+100 as -100 is reserved for system wide property rules. In the above example 101 was used because 100 was already being used by a previous property rule definition.
The "configuration file" normally goes in /Systems. In this example we named the configuration file /Systems/gearAGL.xml.
Here is the complete /Systems/gearAGL.xml configuration file.
<?xml version="1.0"?>
<PropertyList>
<filter>
<type>gain</type>
<gain>0.3048</gain>
<input>/position/altitude-agl-ft</input>
<reference>6</reference>
<output>/position/gear-agl-m</output>
</filter>
</PropertyList>
What the configuration file does is convert the input of altitude-agl-ft to the output of (((altitude-agl-ft)-6)*0.3048) or (convert ft-6 to m) and pass it to /position/gear-agl-m.
See Input and reference properties or values <input> and <reference>.
General comments from forum discussion
|
A few aircraft have a fake shadow, in essence a flat silhouette of the aircraft floating maybe a feet above ground. The silhouette get there using a few properties, possibly driving some calculations and basically the same kind of animations as is used to for example animate the control surfaces. I do not remember having seen a list with aircraft using a fake shadow, but I think that for example Helijah's Diamond twin has one. The big drawback with a fake shadow is that it has to float to not get broken through by even the slightest undulations in the ground, while still will not work as soon as there is a slope. |
|
|
|
As the tree shadow code has shown, it's near-trivial to do the projective geometry not by an animation but in the vertex shader, i.e. fake shadows can be placed where the sun casts them, stretched by the projection, depth adjusted to weather condition and if the current terrain normal is passed, they can even be put co-planar with the local triangle, i.e. they'd project correctly even on sloped runways and terrain.
At a computational cost of almost zero, because you just process the four vertices of the shadow quad, and four is a number which isn't even a warm-up exercise for a GPU used to crunch millions of vertices. But of course, it wouldn't be a real shadow, in particular it wouldn't project correctly onto trees and buildings as a stencil buffer or shadow map solution would. |
|
|
|
Having said that, it is fairly simple to do. Here's an implementation for the EC-130 which comes with an animation based fake shadow out of the box, switching the shadow projection to a GLSL shader:
The animation just puts the shadow onto the ground. The GLSL code can do some projection of the shadow, i.e. it magnifies a bit for low sun and changes position: The shader can do a full light calculation of the surrounding scene, so the depth of the shadow can be varied according to the ambient to diffuse light balance: Also, once the aircraft is in the air, it projects the shadow along the light ray rather than underneath the aircraft: And of course, all that means shadow depth adjusts to weather conditions - no shadows in overcast skies: Implementation (using current git) - make the quads displaying the fake shadow inherit from Effects/shadow.eff, don't translate the shadow (the shader expects it to be correctly positioned for the sun in the zenith for an aircraft standing on the runway), don't try to correct for low sun or to adjust shadow texture transparency, the shader just uses the texture alpha channel. |
|
|
|
Where should I put this? Into one of the *.eff files of any aircraft? -you need the shadow itself as a model (a textured quad). In ac3d (blender,...) that has an object name - in my example shadow_fuselage. You can give it any you want. -in the aircraft-set.xml (or files included there), animations, effects, sounds,... are declared and models included. In the scope where your shadow quad is included, you declare shadow.eff as your effect. What wlbragg has has done (inheriting a copy of the shadow effect under the aircraft effect directory) is probably more by the book, but not strictly necessary unless you want to pass parameters to the effect. |
|
|
|
It works with anything that sets a property how far the gear is off the ground - it works with your home-made Nasal FDM if you like... |
|
|
|
wlbragg wrote in Sat Feb 14, 2015 1:14 am: After looking at how slow altitude-agl-ft update is, I don't think it would work very well anyway. I'll try the "property rule". But now I am curious why I couldn't get altitude-agl-ft to work at all? If altitude-agl-ft seems to update slowly in the property browser it might be a tied property that can't be listened to so instead it is polled at a lower rate - but the property will actually be updated for each frame or FDM iteration. This might also explain why you have problems getting its value into the effect - the effect system might also rely on listeners to get updates (I don't know). |
|
|
|
Yes - you can't pass tied properties to effects. Learned that one the hard way (took me a while to figure out...) That's probably the problem here as well. Okay, then we need an aircraft-side property rule in any case.
It doesn't need to be AP (they're updated at FDM rate), we only need it at framerate. I vaguely remember there was a catch that you had to give an index to airplane-side property rules to avoid overriding the system-wide which do e.g. weather - there's documentation on the wiki somewhere, I think in the AP howto. |
|
|
|
After setting up two separate aircraft with the simplified shadow effect, here is what I found to work best.
Simply put I used a property rule for for both YSim and JSBSim aircraft and override gear-agl-m with a filter passing altitude-agl-ft to gear-agl-m in both aircraft. The reason for this is to accommodate all the shadow AGL adjustment needed for both ASL-shadows and non-ALS-shadows. My Cub has two configurations for tire size and thus two different altitude-agl-ft starting points. The c172p also has its own altitude-agl-ft starting point. I guess they would be dependent upon where and how the model designer created the center point of the aircraft. To accommodate this variability you need to do an offset in the shadow.xml to place the shadow's AGL where you want it. But when using ALS-shadow method it has a tendency to put it where it thinks it needs to go based on the hard code. So you use the offset to position the initial shadow. Then you use the property rule configuration to position the shadow when ALS method takes control of the shadow's AGL. |
|
ALS 3d shadow volume effect
What might be considered the next level of realism using a relatively "cheap" shadow effect is to use a 3d volume shadow.
The basic concept is ....
...............
.................
First you have to have a 3d shadow volume model of the aircraft you are applying the effect to. This model should be a low poly model that is optimized to be as little of a footprint as possible.
The procedure to implement it is almost identical to the ALS-shadow above with a few modifications.
A property rule is required, same as above. This is used to generate the above ground altitude in meters, (altitude-agl-m). The "altitude-agl-m" is used to place the shadow close to the ground in real time at an FDM rate of execution. NOTE: Do not confuse "altitude-agl-m" with the other type of non-3d ALS-shadow property of "gear-agl-m". The shaders involved use these two different properties respectively for the two different effect. They are not interchangeable.
<?xml version="1.0"?>
<PropertyList>
<filter>
<type>gain</type>
<gain>0.3048</gain>
<input>/position/altitude-agl-ft</input>
<reference>1.0</reference>
<output>/position/altitude-agl-m</output>
</filter>
</PropertyList>
The other difference from the ALS-shadow above is that it uses a different inherited effect. Instead of
<effect>
<inherits-from>Effects/shadow</inherits-from>
<object-name>shadow</object-name>
</effect>
you use
<effect>
<inherits-from>Effects/shadow-vol</inherits-from>
<object-name>shadow</object-name>
</effect>
General comments from forum discussion
ALS vs. Rembrandt
|
|
Rembrandt and ALS work with two different rendering pipelines/implementations using very different assumptions - thus, it would be a lot of work to integrate those two properly, and as has been said, Rembrandt isn't beint actively maintained currently, while ALS has been under active development.
— Hooray (Tue Sep 02). Re: Why in Rembrandt, can not be activated Atmospheric light.
(powered by Instant-Cquotes) |
|
|
|
For my visual preferences and on my system ALS is a much better use of what rendering resources there are than Rembrandt and the view out the windows is superior to that of the default scheme.
|
|
|
|
the reason we still havent moved to opengl 3.x+ has been due to supporting OSX. If we wish to support OSX, we need to completely abandon the fixed function pipeline. Some of our dependencies (plib) are no longer maintained , so must be replaced with something that supports shaders (canvas, etc).
|
|
|
|
the other issue is that there's still legacy GL code running in the main/rendering loop that prevents us from using a more recent OpenGL version, such as the panel/HUD and GUI code - those things are in the process of being unified, and re-implemented, on top of modern OSG code using a shared back-end via Canvas.
|
|
|
|
you never actually transit from a deferred to a forward scheme, which is why you don't have the same baseline internally, which is why you need to structure operations you do very differently and can in general expect a very different performance footprint.
|
|
|
|
But the point is - I do understand what the shaders outside ALS do, and I could fix them and/or develop them further if needed. And, given a few weeks to iron out the details, I could also make ALS work under Rembrandt.
|
|
|
|
The actual reason why this isn't happening is twofold:
|
|
|
|
You could in fact take lots of the procedural texturing code and it would run - it's even easy, since I factored the noise functions into libraries which can be included. As to why Rembrandt doesn't do that, it's a question for the Rembrandt maintainers, not for me. I have offered 3 or 4 times to assist if anyone wants to port these code blocks on the devel list.
|
|
|
|
I tend to use/support what works for me well enough (including performance), as well as features that are either sufficiently generic and extensible or at least well-documented with some manpower - for the time being, none of this applies to Rembrandt unfortunately. I consider myself fairly familiar with FG, including its internals - and I am generally able to make FG work well enough on most systems - in fact, I am the one who started the corresponding wiki articles to document such tips - I have yet to see sufficient "configuration advice" from Rembrandt evangelists. I would also very much like to see Rembrandt development to continue, and I might even contribute to such an effort - but for that to happen, a few other things need to happen first, including more/better developer docs - Rembrandt is covering a lot of uncharted waters, i.e. areas in FG to which only long-time contributors like Fred, Tim or Mathias have contributed. |
|