Talk:ALS technical notes
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. |
|
Do we actually have to have the ALS vs. Rembrandt philosophy here? I'm trying to create a technical documentation page which should be concise and to the point, I can't see how the assortment of things I have said about ALS and Rembrandt features here.
- it's your article, so feel free to remove whatever you disagree with - that said, your quotes may still be useful elsewhere, especially because the whole Rembrandt vs. ALS debate is a recurring one, so maybe some kind of FAQ ? I don't know ... I just added some of your quotes here to ensure that people can refer to those arguments, without having to resurrect these debates on the forum over and over again. If you think there is a better way to accomplish that, it's your call. --Hooray (talk) 06:29, 11 March 2015 (EDT)
Surfaces
There is internally no 'ALS' or 'Rembrandt' in the effect framework. We assign effects to surfaces. These effects have techniques which depend on conditionals (predicates), always the first matching technique of an effect is used. It is at the level of these conditionals that we decide upon ALS or Rembrandt.
This is not a must - it would be easy to write an effect which only runs ALS, even if Rembrandt is on. Just leave the conditional out of the technique.
The opposite is pretty much what happens if you assign model-transparent to a surface. This is an effect which has just a single technique (a fixed pipeline setup). Which means that you get transparency rendered okayish, no depth buffer written and outside- in rendering of a depth ordered bin - but at the same time, this technique wrecks ALS light and fog - at night at high altitude the glass will glow faintly red (because that's the light setting of the default renderer) and you will see it through fog no matter the distance.
Now, an unassigned surface uses the general-purpose model-default.eff. This has depth buffer writing and no outside-in rendering and does not use a depth sorted bin - so it may have issues for transparent surfaces. But this has a proper sequence of conditionals and will run ALS when ALS is selected and Rembrandt when Rembrandt is selected, i.e. always get lighting and fogging right.
The glass effect eventually will be one way to render glass in ALS (intended for windows seen from inside). It has correct lighting and fogging, and it will soon use the depth sorted bin and do all the other transparent stuff - and automatically dispatch the surface to the same fixed-pipeline technique Rembrandt uses in model-transparent when Rembrandt is running[1].
Article name
Looking over the page, this article seems to be devoted to describing effects based on ALS used on aircraft, while the title suggests that it describes the technical processes and details of the "works" of ALS itself. As such, would a title such as "ALS Aircraft Effects," "ALS effects" or "ALS aircraft information" be more appropriate? Adam (else MIG29pilot) (talk) 16:22, 1 January 2016 (EST)
GLSL code quoted
/* Fading of a directional light */
Note: To better explain the relation of the variables inner_angle, outer_angle and zero angle, this is the algorithm that produces the scalar value directional_fade from which the intensity value is defined in the shaders file light-ALS.frag:
float directional_fade (in float direction) {
float arg = clamp(direction, 0.0, 1.0);
float ia = (1.0 - inner_angle);
float oa = (1.0 - outer_angle);
float za = (1.0 - zero_angle);
if (direction > ia) {return 1.0;}
else if (direction > oa)
{return outer_gain + (1.0-outer_gain) * (direction - oa) / (ia - oa);}
else if (direction > za)
{return outer_gain * (direction - za) / (oa - za);}
else {return 0.0;}
}
Quoting GLSL code in the wiki is risky (it might change on the repository without warning), too detailed and misleading (generally people tend to expect copy/pastable examples).
If more explanation is required, either link to the shader code on the repository or make an illustration please.
- For that, try the {{fgdata source}} template.
Rain vector
I believe the first Nasal snippet has incorrect sign at least in Z direction, so it ends up displaying only static raindrops when standing still, without new ones splashing from above.
I have made an improved example of rain vector that should:
- fix the missing new drops effect when standing still;
- work correctly for absolutely any attitudes (but I would ask people who would be more familiar with "stability-axis vs body-axis" transforms to check this).
It is written in property rules, but should be straightforward enough to convert to JSBSim or Nasal.
The one problem with it is that, like the old Nasal example, it still has an artificial tuning coefficient `0.01` (`-0.01` for `y`) that scales the airspeed, because the vector is in some arbitrary speed units. My first guess (from the case with standing still where the vector should be `(0.0, 0.0, -1.0)`) was that it would be in the units of a raindrop's terminal velocity, then the coefficient would be `1 / V_rain = 1 / 17.5 = 0.057`, `V_rain` being terminal velocity of a raindrop (9 m/s) in knots -- but in flight the drops moved 10 times too fast to look convincing. If anyone knows what is going on with the units, please let me know.
```
<filter>
<output type="float">
<property>environment/aircraft-effects/splash-vector-x</property>
</output>
<type>gain</type>
<gain>1.0</gain>
<input>
<expression>
<sum>
<product>
<value>0.01</value>
<property>velocities/airspeed-kt</property>
<cos>
<property>orientation/side-slip-rad</property>
</cos>
<cos>
<deg2rad>
<property>orientation/alpha-deg</property>
</deg2rad>
</cos>
</product>
<sin>
<deg2rad>
<property>orientation/pitch-deg</property>
</deg2rad>
</sin>
</sum>
</expression>
</input>
</filter>
<filter>
<output type="float">
<property>environment/aircraft-effects/splash-vector-y</property>
</output>
<type>gain</type>
<gain>1.0</gain>
<input>
<expression>
<sum>
<product>
<value>-0.01</value>
<property>velocities/airspeed-kt</property>
<sin>
<property>orientation/side-slip-rad</property>
</sin>
</product>
<product>
<cos>
<deg2rad>
<property>orientation/pitch-deg</property>
</deg2rad>
</cos>
<sin>
<deg2rad>
<property>orientation/roll-deg</property>
</deg2rad>
</sin>
</product>
</sum>
</expression>
</input>
</filter>
<filter>
<output type="float">
<property>environment/aircraft-effects/splash-vector-z</property>
</output>
<type>gain</type>
<gain>1.0</gain>
<input>
<expression>
<sum>
<product>
<value>0.01</value>
<property>velocities/airspeed-kt</property>
<cos>
<property>orientation/side-slip-rad</property>
</cos>
<sin>
<deg2rad>
<property>orientation/alpha-deg</property>
</deg2rad>
</sin>
</product>
<product>
<value>-1.0</value>
<cos>
<deg2rad>
<property>orientation/pitch-deg</property>
</deg2rad>
</cos>
<cos>
<deg2rad>
<property>orientation/roll-deg</property>
</deg2rad>
</cos>
</product>
</sum>
</expression>
</input>
</filter>
```