ALS landing lights

[abassign]

I did a test of ALS landing light with the 757-200, in the view of the pilot seems to work:


The problem is in the other views, because it shows that the ALS landing light has as riferiento the plane, but not as a "point of view", in fact, in this example, being behind the air, the lights are seen behind (?!)



The idea is great ! But at this point it would be handy to have at least three lights for the front lighting, and other lights to add more effects. It would also be useful to define the size, color, intensity, and if possible also a pulsation (2 parameters: duration on, duration off)

[Johan G]

Due how the landing lights are implemented in order to have the least possible frame rate impact it only works in the cockpit view:

Also, landing lights which work from the cockpit only would be much easier than those which work in external views as well.

Why is that? Because of the distance fading?

Because if you are (almost) at the origin of the light beam, doing near exact geometry in screen coordinates is a matter of two lines, whereas if you're not at the origin of the light beam, you actually need to compute a bit of geometry.

[Thorsten]

But at this point it would be handy to have at least three lights for the front lighting, and other lights to add more effects. It would also be useful to define the size, color, intensity, and if possible also a pulsation (2 parameters: duration on, duration off)

I'm just curious - how would you like me to get the information out so that it reaches you?

In addition to what Johan has quoted from the forum thread:


From implementation wiki page:

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).
(...)
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.

From the newsletter:

The current set of lights is rather different from the 'true' rendering of lights the Rembrandt framework uses, and utilizes the fact that projective geometry is much simplified and rendering very fast when the origin of the light is close to the eye, i.e. the lights project correctly from cockpit view only.

From the announcement to the mailing list:

So far, I have two lights which work in a realistic way from cockpit view only

[abassign]

I'm curious, where are implemented the "ALS secondary lights", I think this is a community in which there are also developers and maybe someone has the technical capacity to implement the features missing in this interesting feature. I believe that in addition to defining the functions is useful, in the Wiki, also document the way in which these functions are implemented. This little hints could dramatically improve the ability of the program to evolve.

[Thorsten]

I'm curious, where are implemented the "ALS secondary lights",

In the ALS pixel shaders. Strangely enough, there's a fairly detailed description on page 1 of this thread following this.

I think this is a community in which there are also developers and maybe someone has the technical capacity to implement the features missing in this interesting feature.

As also mentioned in this thread, the reason is not that it'd be technically difficult to do, it's the performance scaling. So even if someone else develops it, I'm still not going to commit it because of that.

[abassign]

Thank Thorsten for your beautifull but very hard work, and merry Christmas!

[abassign]

I noticed, with horror, that the definition of "landing_light" is repeated for 13 file type "frag" in the folder Shaders!

Code: Select all

file:///home/abassign/fgfs/install/flightgear/fgdata/Shaders/water-ALS-high.frag
file:///home/abassign/fgfs/install/flightgear/fgdata/Shaders/urban-ALS.frag
file:///home/abassign/fgfs/install/flightgear/fgdata/Shaders/tree-ALS.frag
file:///home/abassign/fgfs/install/flightgear/fgdata/Shaders/terrain-ALS-ultra.frag
file:///home/abassign/fgfs/install/flightgear/fgdata/Shaders/skydome-ALS.frag
file:///home/abassign/fgfs/install/flightgear/fgdata/Shaders/secondary_lights.frag
file:///home/abassign/fgfs/install/flightgear/fgdata/Shaders/runway-ALS.frag
file:///home/abassign/fgfs/install/flightgear/fgdata/Shaders/rock-ALS.frag
file:///home/abassign/fgfs/install/flightgear/fgdata/Shaders/model-ALS-ultra.frag
file:///home/abassign/fgfs/install/flightgear/fgdata/Shaders/model-ALS-base.frag
file:///home/abassign/fgfs/install/flightgear/fgdata/Shaders/drunway-ALS.frag
file:///home/abassign/fgfs/install/flightgear/fgdata/Shaders/airfield-ALS.frag
file:///home/abassign/fgfs/install/flightgear/fgdata/Shaders/agriculture-ALS.frag


And these definitions are always similar to these lines of code:

Declaration part:

Code: Select all

vec3 landing_light(in float offset);


Execution part:

Code: Select all

if ((quality_level > 5) && (tquality_level > 5))
    {
    if (use_searchlight == 1)
   {
   secondary_light += searchlight();
   }
    if (use_landing_light == 1)
   {
   secondary_light += landing_light(landing_light1_offset);
   }
    if (use_alt_landing_light == 1)
   {
   secondary_light += landing_light(landing_light2_offset);
   }
    if (dist > 2.0) // we don't want to light the cockpit...
   {color.rgb +=secondary_light * light_distance_fading(dist);}
    }


But there are also variations in the code for specific cases. It is very complex to manage all this, I think it is a typical problem of the file ".frag", but there is a concept of inheriting the properties from a class of higher level? Or these file types do not allow it?

Where is a good documentation on these types of files? If you change a file ".frag", the change when it is interpreted by the program?

[Hooray]

I noticed, with horror, that the definition of "landing_light" is repeated for 13 file type "frag" in the folder Shaders!
Where is a good documentation on these types of files? If you change a file ".frag", the change when it is interpreted by the program?

Based on your posting, those are just so called "forward declarations", i.e. "function prototypes" declaring functions implemented elsewhere - a prototype is there to make a symbol known to the compiler which may be linked in at a later time (where the symbol is replaced with the correct address). I haven't looked at the files in questions, but I wouldn't worry about these things - GLSL is basically a slightly extended subset of C, and as such include files are supported, which would be the more conventional method to deal with forward declarations, i.e. having to maintain only a single "header file". But Thorsten is well aware of how both, C and GLSL, work - so there must be more to it (i.e. why he's not using include files according to your findings in this case).

Personally, I'd suggest to conceptually understand effects and shaders first before looking at any GLSL code. Besides, understanding the compilation model would make sense, too - otherwise, your findings are likely to appear mainly like "noise" to people who wrote the original code.

To learn more about effects, and shaders, I'd suggest these resources:

$FG_ROOT/Docs/README.effects
$FG_ROOT/Docs/README.materials
http://wiki.flightgear.org/Shaders
http://wiki.flightgear.org/Howto:Shader ... FlightGear
http://wiki.flightgear.org/GLSL_Shader_ ... _Resources


Once you've read these, you should have a better understanding of how effects and shaders hang together, and what *.frag/*.vert files are doing, and how they're generally structured.
Note that these articles will usually contain additional pointers - while familiarity with programming (especially in C/C++) will come in handy, GLSL is primarily about 3D math - so you need a strong background in math to understand more sophisticated coding examples/snippets.

To answer some of your other questions, I'd suggest to read these responses:

Subject: ALS landing lights

internally, the GLSL compiler will take all sources and compile them into objects to link them together - if some effects work/stop working once you change explicit indexing, that would suggest that something else is going on - normally, this should only affect compilation order - but as long as you're using forward declarations and/or include files (preprocessor directives), the compiler should not be bothered by re-arranging your sources.

The C++ code will internally run the equivalent of a Nasal foreach() loop and then compile each file, and finally link all objects together. So I don't quite see why/where this might fail?

Subject: ALS landing lights

The other thing to keep in mind is how the OpenGL/GLSL shader compilation model works, i.e. by linking objects together to create programs: https://www.opengl.org/wiki/GLSL_Object ... tion_model

Subject: About FlightGear graphics

If you are into the really heavy eye-candy, then you'll probably want to look at using FlightGear effects, which are plain XML files, see $FG_ROOT/Docs/README.effects: http://gitorious.org/fg/fgdata/blobs/ma ... ME.effects

And then, the final -and most powerful option- is obviously creating custom GLSL shaders: http://wiki.flightgear.org/Shader
The latter will involve programming obviously, and does require a strong mathematical background though - or at least familiarity with 3D graphics and the necessary maths involved.

We only have a handful of people developing shaders here. While that doesn't involve any C++ programming or rebuilding FG from source, most of the shader developers here are in one way or another either professional software developers and long-term FG contributors with at least a master's degree, or have other degrees in related fields such as mathematics, physics or computer science/software engineering.

A very basic introduction to shader programming is available here: http://wiki.flightgear.org/Howto:Shader ... FlightGear
Numerous pointers on more complex topics are provided here: http://wiki.flightgear.org/GLSL_Shader_ ... _Resources
And we even have our own sub forum for "eye candy developers" here: http://flightgear.org/forums/viewforum.php?f=47

Subject: Disable shaders?

It IS possible to tell OSG to avoid certain features, or use vendor-specific implementations instead (such as ARB extensions).
Some of this is also exposed via the effects framework (i.e XML configurable).

Is there some way to identify which shaders are not supported, and remove them from the Shaders folder or otherwise make the problem go away?

You should watch the terminal window during startup and keep a log of all warnings or errors that seem related to rendering or shaders, these notes should then be added to the issue tracker, so that people can try to reproduce the problem.

I suspect the bump-map stuff is a major part of the problem, because aircraft with rivets tend to result in frame rates in the 1-2 range. I tried removing some shaders, but fgfs would crash on loading.

I don't know how exactly you tried to remove "some shaders", but as long as FG tries to load them, things will obviously fail. Without touching the C++ code and rebuilding FG, you can only remove shaders via the effects system, i.e. in $FG_ROOT/Shaders - see: https://gitorious.org/fg/fgdata/blobs/m ... ME.effects

However, keep in mind that shaders may be related to others (not just *.vert and *.frag, but also different shaders).

I wouldn't suggest to do this without knowing GLSL or without at least fully understanding README.effects.
It would be better to forward startup messages to the issue tracker, to see if some shaders can be reworked to better work on Macs.

[abassign]

A curiosity, to understand the effects of the change in the type code. "Frag" and ".vert", you can recompile during execution of the program? Or there is a a command to recompile without recompiling all the code of the program?

[wlbragg]

A curiosity, to understand the effects of the change in the type code. "Frag" and ".vert", you can recompile during execution of the program? Or there is a a command to recompile without recompiling all the code of the program?

If I understand your question correctly .frag and .vert are GLSL programs and are compiled by the GPU at program run time. They are independent of the C code compilation.
The docs Hooray pointed out explain it fairly well as any GLSL docs you might find online with a Google search. It's all pretty strait forwards except the actual math involved to get the effects you want. That is where it starts to get complex and requires a PHD

[abassign]

Let me explain, if I modify a file ".vert" or ".frag" how do I see the outcome of the change on the program? For this there are many systems, I would like to know how do developers FGFs to understand the implications of the code they have achieved. Certainly OpenGL can compile the fly, but I tried to edit a file and restart the program, but did not see anything It is evident that it is necessary to adopt a more specific technique;) ... I'd like to understand because I can see in these techniques really very interesting

[wlbragg]

The easiest way to explain this is for you to read some documentation on the general idea of GLSL and a specific example of how FG was modified to allow end users like us to manipulate graphics in FG using GLSL without having to embed this code in the C source. It is done through the use of Effects (.xml files) and Shaders (vert & frag files)
Start here, then read how FG implements GLSL through the Effects system with this fairly detailed example of one effect.
It has all the necessary information to show you how this effect is initiated from start to finish without touching the C code.

As far as your specific question, you can change all the vert and frag files you want but if you don't call on any of the files you've changed then you won't see any difference. For example, if you changed the color of the spotlight that shines on a tree in the frag file tree.frag but don't turn on the shader with its associated slider or "on" switch, then you won't see any changes. The vert and frag files are but one piece of the pipline. They do nothing if they aren't called upon somewhere upstream.
Look at the example for the spotlight on trees, "fairly detailed example". It explains the pipeline and how it all fits together.

[Thorsten]

I noticed, with horror, that the definition of "landing_light" is repeated for 13 file type "frag" in the folder Shaders!

Perhaps you might want to start learning what a GLSL shader is and what it does before declaring your horror at things you plainly don't understand

Let me explain, if I modify a file ".vert" or ".frag" how do I see the outcome of the change on the program?

You look at the screen. GLSL shaders are compiled 'as needed' - a bit simplified, the very frame an object using a shader (at your current quality level setting) comes into view the shader is compiled.

(Which, incidentially, is why definitions are repeated in any shader - each shader must be a standalone object because it can't rely on other shaders being compiled or running or exchanging information. GLSL is basically the most parallel processing environment you can thing of where no part of the ongoing computation talks much to any other - one pixel doesn't know what any other pixel does)

Edit: As an important side note - may I suggest that you rethink your communication strategy?

You report a 'problem' with the external view for which I have put disclaimers basically everywhere. Perhaps you can understand that this is somewhat frustrating for me. In addition, you ask information that is earlier in the thread, making it clear that you haven't actually read the thread and asking people such as myself to spend time to explain again.

Okay - it happens. We're all guilty of that now and then. The thing I find not so easy to understand is why it's so difficult to type the words 'Sorry, should have read through the thread before writing.' (or something like that). I think it'd have been a fair thing to do.

Now you express your 'horror' at the way the GLSL code is written, yet you don't actually know even know the basics of GLSL coding.

So the messages you're implicitly sending to me is 1) your time is so much more valuable than mine, because while you can't be bothered to read through the previous threads and answers I gave, I should now take time again and answer your questions and 2) you're so much smarter than I am because even without knowing any GLSL, you immediately see that the way I do it is 'horrible'

The thing I find difficult to understand is that if you know yourself you don't understand something, why can't you ask a question like 'I'm surprised, is there a reason this is done that way?' rather than a declarative statement?

Okay - the problem you're facing with your approach is that I really don't want to have this kind of conversation, and that I seem to be the only GLSL expert of FG who hangs out in the forum. So it's your call of course, but I won't be going on like this any further.

[Thorsten]

After going through the view axis defs in the property tree, I have to confess I was wrong - the current setup does not allow to re-point the light by defining different view axis. Sorry for any confusion that has caused.

Giving the matter some thought, I will add a single vertical displacement parameter to make the lights work correctly for taildraggers (and other unconventional cases...) after the feature freeze is over.

[Necolatis]

I just found a bug I think.
The landing light would not switch off even though the property use-landing-light were set to false. (the other 2 light properties were false also)
The shader setting is at max. (not custom)

FG 3.4 RC from 10. Feb., windows 7, 64bit, geforce 520m

Any more data you need?