Board index FlightGear Development Effects and shaders

ALS landing lights

An exciting "new" option in FlightGear, that includes reflections, lightmaps, the particle system etc.. A lot is yet to be discovered/implemented!

Re: ALS landing lights

Postby Hooray » Fri Oct 10, 2014 6:18 pm

Responding in part to your previous PMs here:

As I mentioned previously, I would also like to see the whole journey documented on the wiki to help lower the barrier to entry for newcomers, so I am certainly going to help with that - regarding your wiki formatting issues, I really would't worry too much about style/formatting for now - content is more important, and we have enough people to help with cleaning up formatting if required.

Besides, this could be a great match actually - given that you mentioned that you are familiar with C++ and GLSL, and that Thorsten is familiar with the way shaders and effects work in FlightGear, Thorsten posted his first C++ patches a few days ago, so some more networking between the two of you could certainly be worthwhile for both of you - and Thorsten seems to be enjoying the "mentoring mode", too - and seems to be pretty good at this, too :D

Regarding your questions on wiki formatting - Here's the wiki markup required for XML snippets:
Code: Select all
<syntaxhighlight lang="xml">
</syntaxhighlight>


You can replace "xml" with glsl, c, cpp or nasal respectively to highlight other code.
Equally, sections are primarily formatted/nested by using this:
Code: Select all
= Heading =
== Sub Heading ==
=== Sub-Sub Heading ===


Bulletin points are simply added like this:
    * first
    * second
    * third

for numbering, use the hash tag instead of the asterisk.
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 11377
Joined: Tue Mar 25, 2008 8:40 am

Re: ALS landing lights

Postby Thorsten » Sat Oct 11, 2014 7:28 am

I worked with the model again last night to see if I could figure out the models without texture and only specular and after a couple hours decided it will wait for your handy work. I can't wait to see how it's done.


I can tell you what the problem is, I'm not yet sure how I'll attack it.

So, in old times when rendering textures was slow and complicated, we rendered objects with monochromatic surface colors. Then the (schematic) lighting equation (without specular, and the sum of ambient and diffuse already computed) was

visibleColor.rgb =objectColor.rgb * light.rgb + objectEmissive.rgb

Now, we have textures and so we get

visibleColor.rgb = objectColor.rgb * texel.rgb * light.rgb + objectEmissive.rgb + lightMapTexel.rgb

Since we can have the full color information in the texture, objectColor.rgb is usually (1.0,1.0,1.0) because the info is redundant. But if you don't use a texture, of course objectColor.rgb has the actual color value (incidentially, I think we shouldn't texture with monochromatic surfaces at all, it creates a jarring visual impression which can be cured by using even a small texture...)

But if you do, the rendering pipeline is set up to compute color.rgb = objectColor * light.rgb in the vertex shader, so the equation we have in the fragment shader is something like

visibleColor.rgb = color.rgb * texel.rgb + objectEmissive.rgb + lightMapTexel.rgb

and if we add a secondary light like

visibleColor.rgb = (color.rgb + secLight.rgb) * texel.rgb

it of course can never recover the color information, because color.rgb is zero at night since you multiplied the actual color with zero sunlight and the texel doesn't carry information for an untextured object.

Since the secondary light is in screen coordinates, it can't appear in the vertex shader, so the solution would be to pass the actual color and light rather than their product to the fragment shader. Which is expensive, because we need another varying vec3, and varying variable types fill memory and need to be computed an interpolated per vertex/per fragment - which is why I'm not sure whether we shouldn't accept the loss of the color...
Thorsten
 
Posts: 11210
Joined: Mon Nov 02, 2009 8:33 am

Re: ALS landing lights

Postby wlbragg » Sat Oct 11, 2014 8:36 am

I'm not sure whether we shouldn't accept the loss of the color...

I don't disagree, as far as that is concerned anyone can clean up any models they need for their projects.

because we need another varying vec3

How much memory are we talking about?
Kansas(2-27-15)/Ohio/Midwest scenery development.
KEQA (2-27-15), 3AU, KRCP Airport Layout
Intel i5 3570K AMDRX480
User avatar
wlbragg
 
Posts: 4989
Joined: Sat Aug 25, 2012 11:31 pm
Location: Kansas (Tornado Alley), USA
Callsign: WC2020
Version: next
OS: Win10/Linux/AMDRX480

Re: ALS landing lights

Postby Johan G » Sat Oct 11, 2014 1:37 pm

Hooray wrote in Fri Oct 10, 2014 6:18 pm:...regarding your wiki formatting issues, I really would't worry too much about style/formatting for now - content is more important, and we have enough people to help with cleaning up formatting if required.

Indeed, content is king. In addition, you will most probably learn as you go. :)

Hooray wrote in Fri Oct 10, 2014 6:18 pm:Equally, sections are primarily formatted/nested by using this:
Code: Select all
= Heading =
== Sub Heading ==
=== Sub-Sub Heading ===

As the first heading level only is used for the article title, that should be:
Code: Select all
== Heading ==
=== Sub Heading ===
==== Sub-Sub Heading ====
Low-level flying — It's all fun and games till someone looses an engine. (Paraphrased from a YouTube video)
Improving the Dassault Mirage F1 (Wiki, Forum, GitLab. Work in slow progress)
Johan G
Moderator
 
Posts: 5546
Joined: Fri Aug 06, 2010 5:33 pm
Location: Sweden
Callsign: SE-JG
IRC name: Johan_G
Version: 3.0.0
OS: Windows 7, 32 bit

Re: ALS landing lights

Postby wlbragg » Sat Oct 11, 2014 8:34 pm

Thanks Johan G and Hooray.

OK, either I'm impatient and your not finished with model/buildings, or I have something wrong with my git, or you do with the latest commit code.

Pertaining to Effects Inheritance

Code: Select all
Base is model-defrag.eff
  includes
    parameters for secondary-lights
    no technique 4
      no associated shader program for secondary-lights
      no associated uniforms for secondary-lights

then model-combined.eff inherits from model-defrag.eff
  includes
    no parameters for secondary-lights (doesn't need to because they are inherited)
    technique 4
      shader programs for secondary-lights
        fragment-shader n="1" Shaders/model-ALS-ultra.frag (calls to secondary_lights.frag)
        fragment-shader n="4" Shaders/secondary_lights.frag (must be included to link in the above called code)
      uniforms for secondary-lights

then model-combined-deffered.eff inherits from model-combined.eff
  includes
    no parameters for secondary-lights (doesn't need to because they are inherited)
    no technique 4 (shader programs and uniforms would have to be included, (if needed), because there is no technique 4 inheritance)
      no associated shader program for secondary-lights
      no associated uniforms for secondary-lights

then building.eff inherits from model-combined-deffered.eff
  includes
    no parameters for secondary-lights (doesn't need to because they are inherited)
    technique 4
      shader programs for secondary-lights
        fragment-shader n="1" Shaders/model-ALS-ultra.frag (calls to secondary_lights.frag)
        fragment-shader n="4" Shaders/secondary_lights.frag (must be included to link in the above called code)
      no uniforms for secondary-lights

Can uniforms be passed from technique 4 in model-combined.eff
even though technique 4 is skipped in model-combined-deffered.eff
and the same for the shader programs, can they be passed when skipping a technique?

What does n="1" mean in <program> <fragment-shader n="1">?

Because my secondary_lights over model/buildings aren't working with this configuration.
If I jumped the gun here because you not finished, I apologize.
Kansas(2-27-15)/Ohio/Midwest scenery development.
KEQA (2-27-15), 3AU, KRCP Airport Layout
Intel i5 3570K AMDRX480
User avatar
wlbragg
 
Posts: 4989
Joined: Sat Aug 25, 2012 11:31 pm
Location: Kansas (Tornado Alley), USA
Callsign: WC2020
Version: next
OS: Win10/Linux/AMDRX480

Re: ALS landing lights

Postby Hooray » Sat Oct 11, 2014 9:42 pm

wlbragg wrote in Sat Oct 11, 2014 8:34 pm:What does n="1" mean in <program> <fragment-shader n="1">?


See our earlier comments below:

Subject: ALS landing lights
Hooray wrote:
Thorsten wrote:Maybe the various fragment shader functions also want indices - <fragment shader n="1">... and so on - I'm not really sure when this should be used, it always seems to be working for me.

Did you really ever have to add explicit indexing to your effects files ? That would be interesting but unexpected - 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?



Thorsten's response was this:
Subject: ALS landing lights
Thorsten wrote:I didn't ever, but I know that Emilian and Fred have used it now and then - presumably for some reason (?)


The original property list documentation also applies, see: https://gitorious.org/fg/fgdata/source/ ... panel#L164
But that will just explain how property indexing works in general, it doesn't tell you anything about the way this affects shaders/effects.
The most obvious explanation would be that program/effect and technique order is made explicit like this, so that it is less prone to accidental re-ordering issues due to implicit indexing (e.g. by using copy & paste to add new effects/programs or techniques) as mentioned in the docs: http://wiki.flightgear.org/PropertyList ... ist_format

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
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 11377
Joined: Tue Mar 25, 2008 8:40 am

Re: ALS landing lights

Postby Thorsten » Sun Oct 12, 2014 5:33 am

Can uniforms be passed from technique 4 in model-combined.eff
even though technique 4 is skipped in model-combined-deffered.eff
and the same for the shader programs, can they be passed when skipping a technique?


Inheritance works like this:

The base effect has a list of things

A1 B1 C1 D1

The second effect inherits 1 but just declares C2 and E2, so then the list is

A1 B1 C2 D1 E2

The third effect inherits from 2 and declares A3, so then the list is

A3 B1 C2 D1 E2

whereas if the third effect would inherit from 1, then the list would be

A3 B1 C1 D1

So if already present, inheritance overrides, if not present it adds. I suspect that's why programs need to be indexed, so they they override and don't add...
Thorsten
 
Posts: 11210
Joined: Mon Nov 02, 2009 8:33 am

Re: ALS landing lights

Postby wlbragg » Sun Oct 12, 2014 8:04 am

Ok, that covers indexing and inheritance really well.

I'm not sure I got two questions answered though. Probably because I didn't ask it in a manner that made sense.

Regarding building.eff,
You added secondary_lights shader code to building.eff, (fragment-shader model-ALS-ultra.frag and fragment-shadersecondary_lights.frag), and it should have inherited the parameters from its base inheritance of model-default.
But, there is no uniforms in it because they weren't defined and aren't being inherited from it's predecessor of model-combined-deferred (model-combined-deferred didn't define or inherit any). So unless they were somehow inherited from 2 predecessors back (model-combined/technique 4) it would leave fragment-shader model-ALS-ultra.frag with no uniform input from building.eff.
I say this because I thought you said that the parameters will be inherited all the way down the inheritance pipeline but not the programs or the uniforms unless they are passed along the way in the same defined techniques. Does that make sense?
If your not understanding what I am asking, simply put it is, there are no defined uniforms in building.eff and they are not being inherited (or at least I don't think they are). Certainly they are not inherited from the immediate predecessor of model-combined-deferred.

Or using your analogy,

The base effect has parameters called A1
A1

The second effect inherits A1 and declares B1 (programs) and C1 (uniforms) in technique4
A1 (technique4, B1 C1)

The third effect inherits A1 and nothing else because it has no technique4
A1

The forth one inherits A1, and defines B1
A1 B1

where is C1 (the uniforms)?

Bottom line is the secondary_lights shader added to model-combined doesn't appear to be working.
Is that because your not finished?
Or do I have problems? (code problems not personal :lol:)
Kansas(2-27-15)/Ohio/Midwest scenery development.
KEQA (2-27-15), 3AU, KRCP Airport Layout
Intel i5 3570K AMDRX480
User avatar
wlbragg
 
Posts: 4989
Joined: Sat Aug 25, 2012 11:31 pm
Location: Kansas (Tornado Alley), USA
Callsign: WC2020
Version: next
OS: Win10/Linux/AMDRX480

Re: ALS landing lights

Postby Thorsten » Sun Oct 12, 2014 9:15 am

building.eff inherits technique 4 from model-combined.eff which contains a technique 4 with all the uniforms and just modifies it to use partially different shaders and uniforms.

It works all fine here, so it's a problem at your end. Is the model shader all the way up? Otherwise you render buildings with technique 5.
Thorsten
 
Posts: 11210
Joined: Mon Nov 02, 2009 8:33 am

Re: ALS landing lights

Postby wlbragg » Sun Oct 12, 2014 4:30 pm

Is the model shader all the way up?

Yes

I had completed a hard reset to bb0cbc6 to make sure anything I had done wasn't missed when I pulled your last changes. That is when the model wasn't working. I just did a hard reset again (to be sure) and then pulled c179bf0 (cleanup of naming conventions) and it is all working now. I don't know why bb0cbc6 wasn't. No matter, it works now.

Except,
I still have grayscale models (untextured).
Did you bring in the color on models with no texture?

Also I noticed in the log,
Code: Select all
opengl:4:..\..\..\..\flightgear\src\Viewer\fg_os_osgviewer.cxx:193:glLinkProgram "" FAILED

opengl:4:..\..\..\..\flightgear\src\Viewer\fg_os_osgviewer.cxx:193:Program "" infolog:
Vertex info
-----------
0(91) : warning C7564: assignment to attribute gl_Vertex
0(91) : warning C7564: assignment to attribute gl_Vertex
0(91) : warning C7564: assignment to attribute gl_Vertex
0(91) : warning C7564: assignment to attribute gl_Vertex
0(91) : warning C7564: assignment to attribute gl_Vertex
0(91) : warning C7564: assignment to attribute gl_Vertex
0(91) : warning C7564: assignment to attribute gl_Vertex

Fragment info
-------------
0(24) : error C1013: function "rand2D" is already defined at 0(53)
0(32) : error C1013: function "cosine_interpolate" is already defined at 0(57)
0(40) : error C1013: function "simple_interpolate" is already defined at 0(65)
0(45) : error C1013: function "interpolatedNoise2D" is already defined at 0(71)
0(99) : error C1013: function "Noise2D" is already defined at 0(91)

I think this is caused by the same condition I posted about earlier in this thread.
For some reason if you start out with the spotlight set to true in preferences.xml and the shaders set high enough to activate the spotight you get the error in the log.
You don't get the error if you start out with spotlight off (in preferences.xml) and then turn it on after startup
You also don't get the error if you start out with the shaders off and then turn them up after startup.
It doesn't appear to affect anything though, least not that I can easily see unless that is why I am not getting color on untextured models.
Kansas(2-27-15)/Ohio/Midwest scenery development.
KEQA (2-27-15), 3AU, KRCP Airport Layout
Intel i5 3570K AMDRX480
User avatar
wlbragg
 
Posts: 4989
Joined: Sat Aug 25, 2012 11:31 pm
Location: Kansas (Tornado Alley), USA
Callsign: WC2020
Version: next
OS: Win10/Linux/AMDRX480

Re: ALS landing lights

Postby Thorsten » Mon Oct 13, 2014 6:27 am

Did you bring in the color on models with no texture?


which is why I'm not sure whether we shouldn't accept the loss of the color...

I think this is caused by the same condition I posted about earlier in this thread.


No it's not. The first is a completely unrelated fix to the runway markings and the second is a not yet adapted dirt runway effect. Patience please...
Thorsten
 
Posts: 11210
Joined: Mon Nov 02, 2009 8:33 am

Re: ALS landing lights

Postby wlbragg » Mon Oct 13, 2014 6:41 am

which is why I'm not sure whether we shouldn't accept the loss of the color..


Like I said, I don't have a problem with that.
I was not sure if you had brought in the color or not and maybe my system was just messed up. That is all I was asking, not will you, just, did you? I guess the answer in no. No problem as far as I am concerned. I'll just add textures to any problem models if I don't like them.

Patience please...

My mistake, I just now noticed that this isn't even the same error. This is a new, different error. In my defense it was late when I noticed it. :oops:
Again, the only reason I brought it up was to let you know it was there, in case you didn't know. And to make sure it wasn't something only I was getting for unknown reasons (like my system is all screwy). But apparently it's not and your aware and I'll shut-up.

Oh, and by the way. I wrote up in layman's terms some documentation on this at Howto:Shader Programming in FlightGear. If you get a chance you might look it over and make sure it OK with you. Or that there is nothing glaringly wrong.
Last edited by wlbragg on Mon Oct 13, 2014 11:25 pm, edited 1 time in total.
Kansas(2-27-15)/Ohio/Midwest scenery development.
KEQA (2-27-15), 3AU, KRCP Airport Layout
Intel i5 3570K AMDRX480
User avatar
wlbragg
 
Posts: 4989
Joined: Sat Aug 25, 2012 11:31 pm
Location: Kansas (Tornado Alley), USA
Callsign: WC2020
Version: next
OS: Win10/Linux/AMDRX480

Re: ALS landing lights

Postby Hooray » Mon Oct 13, 2014 5:02 pm

Here's the direct link: http://wiki.flightgear.org/Howto:Shader ... Flightgear

PS: Good job there !
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 11377
Joined: Tue Mar 25, 2008 8:40 am

Re: ALS landing lights

Postby LesterBoffo » Fri Oct 24, 2014 4:50 pm

OK I'm going to ask a dumb question, is there any way to implement the ALS spotlight in an older version of FlightGear Like 2.12?

Since I've been making road vehicles lately the little streetlight sprites(?) seem a bit poorly rendered. They appear OK from a distance but when approached they scale down to almost firefly size and intensity. I'm not sure if even ALS has any effect on their point source effects. It would be nice to render a small oblong blotch of streetlight illumination on the surroundings under each of these lights with the ALS light feature if possible.

I suspect I'll need to upgrade to GIT or the latest release of FG for this?
User avatar
LesterBoffo
 
Posts: 2124
Joined: Sun Oct 02, 2011 4:02 pm
Location: Oregon, USA
Callsign: LesBof
Version: 2018.3.2
OS: Win10 Pro

Re: ALS landing lights

Postby Thorsten » Sat Oct 25, 2014 8:39 am

Well, that's a bunch of different issues...

The answer to your question asked is that I guess for most things, just copying the effect and shader files would work on an older version (I don't think that we have done much core work of late, and the landing light doesn't involve it).

The answer to the question implied is that we can render the random streetlight point sprites in any way you like using a shader, but they remain point sprites (and for that you need at least 3.2 because this did involve core changes). That means that whatever happens, they're going to remain emissive blobs of light with no crosstalk with the surrounding terrain - they're not actual light sources and never have been.

The answer to the actual question is you can't use the ALS landing light for this, because that assumes the origin of the light is at your eye coordinate, so you can use it as headlight, but not as some other light in the scene. We could theoretically render other lights in the scene by passing their position, but that's going to become increasingly expensive and really not what ALS is for - if you want to render hundreds of real lights in the scene, deferred rendering (Rembrandt) is clearly the better framework, the strength of ALS lies in a different direction and the landing light code is a neat hack, but nothing more, and definitely not a direction I will generalize to a Rembrandt like scheme.

For what you're interested in, a lightmap would work with best performance. You'd need roads which are uv-mapped using the line feature code of terragear (not in the officially shipped scenery unfortunately) so that the lights are properly aligned with the road.
Thorsten
 
Posts: 11210
Joined: Mon Nov 02, 2009 8:33 am

PreviousNext

Return to Effects and shaders

Who is online

Users browsing this forum: No registered users and 2 guests