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 » Mon Oct 06, 2014 9:28 pm

good job there, also to Thorsten on actually writing a tutorial that can be worked through without having to be an expert in effects/shaders ! :D
Maybe we should strive to add more such tutorials to the wiki so that we can grow a following of people able to making working modifications to existing effects/shaders, especially given the low number of active contributors working with these features ? :wink:
@wlbragg: if you'd be interested in pursuing this, let's add your snippets to the wiki, along with Thorsten's instructions, so that this can serve as an introduction to effects tweaking, i.e. an entry point for newcomers ?
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: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

Re: ALS landing lights

Postby wlbragg » Mon Oct 06, 2014 10:21 pm

Hooray,

Yes, I would be more than happy to add my bit once I know what specific document your referring to.
Are you referring to Howto:Shader Programming in FlightGear?
Or is there more, specific to this particular technique?
If there is more then I might not need to ask Thorsten the next question.


Thorsten,

I tried to spotlight random vegetation in tree-haze.frag next, but can't reconcile the difference between.
vec4 fragColor = vec4 (gl_Color.xyz,1.0) * texel;
and
vec4 color = gl_Color;
or specifically
color.rgb

Then I looked at forest.frag and that wasn't any better for my level of understanding.

If I spend "hours" I might be able to figure it out. But I know you have my answers in minutes!
Kansas and Ohio/Midwest scenery development.
KEQA, 3AU, KRCP Airport Layout
Intel i7/GeForce RTX 2070/Max-Q
User avatar
wlbragg
 
Posts: 7586
Joined: Sun Aug 26, 2012 12:31 am
Location: Kansas (Tornado Alley), USA
Callsign: WC2020
Version: next
OS: Win10/Linux/RTX 2070

Re: ALS landing lights

Postby Thorsten » Tue Oct 07, 2014 7:04 am

Well, it's a bit tricky :-)

In principle, we always do the same steps in the fragment shaders to determine the color of a pixel:

* texel color - what is the base color of the pixel fully lit and unfogged
* lighting - how is this color changed by the light falling onto that pixel, usually the relation is something like fragColor = texel*light
* fogging - how much is the color hidden by haze, usually the relation is something like gl_FragColor = mix(fragColor, hazeColor, transmission_factor);
* what is displayed on the screen in the end is whatever gl_FragColor is set to

But the location where this happens isn't always obvious - often (part) of the light is computed in the vertex shader already, in which case it typically enters the fragment shader as gl_Color.

So, the lighting equation in tree-haze.frag is indeed

Code: Select all
vec4 fragColor = vec4 (gl_Color.xyz,1.0) * texel;


and your change to the light should happen just before that. But you can't do

Code: Select all
gl_Color.rgb = gl_Color.rgb + my_light;


because gl_Color.rgb is a varying variable type, and you can't assign new values to them inside the shader, so you need to either make a new variable or just do

Code: Select all
vec4 fragColor = vec4 ((gl_Color.rgb + my_light),1.0) * texel;


(note that color.rgb is the same as color.xyz, GLSL doesn't really care which convention you use, but I took a few months to learn that, so early code by myself often uses xyz indexing convention for color vectors as well).
Thorsten
 
Posts: 12490
Joined: Mon Nov 02, 2009 9:33 am

Re: ALS landing lights

Postby wlbragg » Tue Oct 07, 2014 8:14 am

Ok, I'll get back to that after I figure out what just happened.

I pulled your offset additions and suddenly my model additions quit working.

I checked and double checked everything and I can't figure out what happened. Nothing you did even touched the searchlight part except for

Code: Select all
//float lightRadius = (200.0 * 55.0/field_of_view);
float lightRadius = (float(display_xsize) *9.16 /field_of_view);
//headlightIntensity = pow(cos(angularDist/lightRadius * 3.1415/2.0),2.0);
headlightIntensity = pow(cos(angularDist/lightRadius * 1.57075),2.0);

in secondary_lights.frag. So I changed it back just to make sure.

The spotlight is still working on everything you coded except the models I coded.

This is all the code I add that was working. You saw it in previous post. Plus the new additions for the offsets.

Code: Select all
uniform int use_searchlight;
uniform int use_landing_light;
//added below
uniform int use_alt_landing_light;
uniform float landing_light1_offset;
uniform float landing_light2_offset;

vec3 searchlight(in float dist);
//changed to below
vec3 landing_light(in float dist, in float offset);

if (use_searchlight == 1){
   color.rgb += searchlight(dist);
}
if (use_landing_light == 1){
   color.rgb += landing_light(dist);
   color.rgb += landing_light(dist, landing_light1_offset);
}
if (use_alt_landing_light == 1){
   color.rgb += landing_light(dist, landing_light2_offset);
}
fragColor = color * texel + specular;


Code: Select all
<parameters>
   ..............................
   ..............................
   .............................
   .............................
   <!--  END fog include -->
      
   <display_xsize><use>/sim/startup/xsize</use></display_xsize>
   <display_ysize><use>/sim/startup/ysize</use></display_ysize>
   <view_pitch_offset><use>/sim/current-view/pitch-offset-deg</use></view_pitch_offset>
   <view_heading_offset><use>/sim/current-view/heading-offset-deg</use></view_heading_offset>
   <view_fov><use>/sim/current-view/field-of-view</use></view_fov>
   <use_searchlight><use>/sim/rendering/als-secondary-lights/use-searchlight</use></use_searchlight>
   <use_landing_light><use>/sim/rendering/als-secondary-lights/use-landing-light</use></use_landing_light>
   <!-- added below-->
   <use_alt_landing_light><use>/sim/rendering/als-secondary-lights/use-alt-landing-light</use></use_alt_landing_light>
   <landing_light1_offset><use>/sim/rendering/als-secondary-lights/landing-light1-offset-deg</use></landing_light1_offset>
   <landing_light2_offset><use>/sim/rendering/als-secondary-lights/landing-light2-offset-deg</use></landing_light2_offset>   
</parameters>

<technique n="5">
<program>
   <vertex-shader>Shaders/terrain-haze.vert</vertex-shader>
   <fragment-shader>Shaders/terrain-haze.frag</fragment-shader>
   <fragment-shader>Shaders/secondary_lights.frag</fragment-shader>
</program>
          <!--added landing_light1_offset and landing_light2_offset uniforms -->
      <uniform>
         <name>landing_light1_offset</name>
         <type>float</type>
         <value><use>landing_light1_offset</use></value>
      </uniform>
      <uniform>
         <name>landing_light2_offset</name>
         <type>float</type>
         <value><use>landing_light2_offset</use></value>
      </uniform>

      <uniform>
         <name>view_pitch_offset</name>
         <type>float</type>
         <value><use>view_pitch_offset</use></value>
      </uniform>
      <uniform>
         <name>view_heading_offset</name>
         <type>float</type>
         <value><use>view_heading_offset</use></value>
      </uniform>
      <uniform>
         <name>field_of_view</name>
         <type>float</type>
         <value><use>view_fov</use></value>
      </uniform>
      <uniform>
         <name>use_searchlight</name>
         <type>int</type>
         <value><use>use_searchlight</use></value>
      </uniform>
      <uniform>
         <name>use_landing_light</name>
         <type>int</type>
         <value><use>use_landing_light</use></value>
      </uniform>

                <!--added use_alt_landing_light-->
      <uniform>
         <name>use_alt_landing_light</name>
         <type>int</type>
         <value><use>use_alt_landing_light</use></value>
      </uniform>

      <uniform>
         <name>display_xsize</name>
         <type>int</type>
         <value><use>display_xsize</use></value>
      </uniform>
      <uniform>
         <name>display_ysize</name>
         <type>int</type>
         <value><use>display_ysize</use></value>
      </uniform>


The only thing I haven't done yet is a hard reset prior to you last commit to see if that even still works.
Kansas and Ohio/Midwest scenery development.
KEQA, 3AU, KRCP Airport Layout
Intel i7/GeForce RTX 2070/Max-Q
User avatar
wlbragg
 
Posts: 7586
Joined: Sun Aug 26, 2012 12:31 am
Location: Kansas (Tornado Alley), USA
Callsign: WC2020
Version: next
OS: Win10/Linux/RTX 2070

Re: ALS landing lights

Postby wlbragg » Tue Oct 07, 2014 9:02 am

I rolled it back and it's working again. So I will take it one step at a time and see if I can figure out what is breaking it. If it is something you did or something I might have inadvertently done.
Kansas and Ohio/Midwest scenery development.
KEQA, 3AU, KRCP Airport Layout
Intel i7/GeForce RTX 2070/Max-Q
User avatar
wlbragg
 
Posts: 7586
Joined: Sun Aug 26, 2012 12:31 am
Location: Kansas (Tornado Alley), USA
Callsign: WC2020
Version: next
OS: Win10/Linux/RTX 2070

Re: ALS landing lights

Postby Thorsten » Tue Oct 07, 2014 10:53 am

Well, it's stuff in development, so I keep changing the structure - if you want to work with it yourself and aren't sure of all the details, it's best if you make your branch and figure things out on something stable and then get back to things my code has reached a stable state.

What happened is probably that the landing light function in secondary_lights.frag changed to take two arguments, and then it had a mismatch with the function call you didn't change in terrain-haze.frag but I changed in everything I coded, so you would have gotten a shader compilation error to the console/log file.


Some experiments with fog effect on the light (it's actually simple, we just need to include enough shaders to avoid black spots...)

400 m visibility - some blur, and halo effect on the runway lighting:

Image

125 m visibility - lights primarily illuminate the fog:

Image
Thorsten
 
Posts: 12490
Joined: Mon Nov 02, 2009 9:33 am

Re: ALS landing lights

Postby Hooray » Tue Oct 07, 2014 11:22 am

looking at your property names there, you might want to consider simply using a dedicated branch for each light, instead of appending an explicit number as the suffix of the name - that way, you can simply access each light as a conventional property/foo/bar[x] lookup - while keeping all properties neatly organized in their own "directory". You could end up having:

/sim/rendering/als-secondary-lights/light[x] then
where each light would keep its own properties without having to append any other identifiers - i.e. using just /sim/rendering/als-secondary-lights/light[0]/offset-deg and /sim/rendering/als-secondary-lights/light[1]/offset-deg

The other advantage is that if you ever contemplate exposing other attributes to the property tree, things will be straightforward to maintain without you having to modify a ton of files.

Obviously, you might say this is a no-brainer because nobody is ever going to use more than 2 landing lights - but as we all know, people tend to adopt & use what's easily available, so maybe this should be kept as generic and flexible as possible, so that others can build on it, and maybe extend the whole idea?
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: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

Re: ALS landing lights

Postby Thorsten » Tue Oct 07, 2014 11:28 am

It stalls at the point where you can't pass arrays through the effect framework, so if you want to extend it, you have to write every extension explicitly anyway, arrays have no advantage. The idea is good, and I looked for a good solution when making the cloud shadows, but there is none, every array element has to be handed over separately.
Thorsten
 
Posts: 12490
Joined: Mon Nov 02, 2009 9:33 am

Re: ALS landing lights

Postby Hooray » Tue Oct 07, 2014 12:47 pm

right, I forgot that we talked about that a while ago - and I think it was Zakalawe who said that the "correct" solution would be extending the effects framework to support arrays of UBOs (Uniform Buffer Objects) - The C++ side is relatively straightforward, I am just not sure if/how well OSG exposes this. The other question is if/how this affects backward compatibility by requring support for UBO arrays, I guess i4dnf could help clarify this though.

But even without effects-level support, it would be "cleaner" to maintain the hierarchy of the property tree, even if that's just in preparations for future changes to the effects code.

Like you said, it's a "good idea" in general, and doesn't add anything to the existing code, while being sufficiently flexible to be updated in the future - which means, that you'd still have to pass foo[x] explicitly for now, until array support becomes available.

If supporting uniform buffer objects is something that you'd like to explore, I can help and come up with a C++ patch to see how well this works, but we should probably get in touch with Stuart/James or i4dnf upfront because they discussed this a few months ago already.

The main challenge seems to be using a standard alignment/packing format for the passed data: https://www.opengl.org/wiki/Uniform_Buf ... ut_queries

And it seems that even Tim Moore was originally planning on supporting UBOs: http://markmail.org/message/nk3dswtmkcrn2j4m

http://forum.openscenegraph.org/viewtopic.php?t=12732
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: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

Re: ALS landing lights

Postby wlbragg » Tue Oct 07, 2014 6:58 pm

I double checked everything several times,

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:
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)


It's the second entry in terrain-haze.frag

Code: Select all
if (use_searchlight == 1){
   color.rgb += searchlight(dist);
}
//if (use_landing_light == 1){
//   color.rgb += landing_light(dist, landing_light1_offset);
//}
//if (use_alt_landing_light == 1){
//   color.rgb += landing_light(dist, landing_light2_offset);
//}


But even if I comment everything to do with landing lights (everywhere) I get rid of the error and the spotlight still fails to highlight models.
I do see what changes you made and I know I accounted for them in terrain-haze.frag. It's like something else crept into the whole process.
I can go back to stable and work from there but this should be working as is.
Kansas and Ohio/Midwest scenery development.
KEQA, 3AU, KRCP Airport Layout
Intel i7/GeForce RTX 2070/Max-Q
User avatar
wlbragg
 
Posts: 7586
Joined: Sun Aug 26, 2012 12:31 am
Location: Kansas (Tornado Alley), USA
Callsign: WC2020
Version: next
OS: Win10/Linux/RTX 2070

Re: ALS landing lights

Postby wlbragg » Tue Oct 07, 2014 9:43 pm

Your genius!

Image



What is going on here? It only appears to wash out completely at night. How to handle this?
Image

EDIT:
This models properties as I understand them are

Code: Select all
MATERIAL "DefaultWhite" rgb 1 1 1  amb 1 1 1  emis 0 0 0  spec 0.5 0.5 0.5  shi 64  trans 0
MATERIAL "Brick" rgb 0.40923 0.277385 0 amb 0.40923 0.277385 0 emis 0 0 0 spec 0.265272 0.265272 0.265272 shi 32 trans 0
MATERIAL "Roof" rgb 0.572858 0.568899 0.524482 amb 0.572858 0.568899 0.524482 emis 0 0 0 spec 0 0 0 shi 32 trans 0

No textures...

xml is simply
Code: Select all
<?xml version="1.0"?>

<PropertyList>

 <path>Office15x15.ac</path>
 <animation>
  <type>range</type>
  <min-m>0</min-m>
  <max-m>20000</max-m>
 </animation>

</PropertyList>
Last edited by wlbragg on Tue Oct 07, 2014 10:00 pm, edited 2 times in total.
Kansas and Ohio/Midwest scenery development.
KEQA, 3AU, KRCP Airport Layout
Intel i7/GeForce RTX 2070/Max-Q
User avatar
wlbragg
 
Posts: 7586
Joined: Sun Aug 26, 2012 12:31 am
Location: Kansas (Tornado Alley), USA
Callsign: WC2020
Version: next
OS: Win10/Linux/RTX 2070

Re: ALS landing lights

Postby Hooray » Tue Oct 07, 2014 9:52 pm

it's pretty freaking cool watching this - I mean, turning this into a little night vision/FLIR gadget by using a greenish filter would seem entirely possible now and it would also look incredibly cool, overlaid with a HUD, our combat folks should be pretty excited about this, and it probably won't take long for someone to come up with a Canvas-based sniper scope :lol:
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: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

Re: ALS landing lights

Postby wlbragg » Tue Oct 07, 2014 11:09 pm

My best guess for water was

water.eff
technique 1

water_lightfield.frag

but I cant get past
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:
Fragment info
-------------
0(591) : error C3002: call to undefined function "vec3 searchlight(float);"
0(595) : error C3002: call to undefined function "vec3 landing_light(float);"

and I don't understand where and why I'm getting that.
Kansas and Ohio/Midwest scenery development.
KEQA, 3AU, KRCP Airport Layout
Intel i7/GeForce RTX 2070/Max-Q
User avatar
wlbragg
 
Posts: 7586
Joined: Sun Aug 26, 2012 12:31 am
Location: Kansas (Tornado Alley), USA
Callsign: WC2020
Version: next
OS: Win10/Linux/RTX 2070

Re: ALS landing lights

Postby wlbragg » Tue Oct 07, 2014 11:13 pm

ok, I just noticed it inherits terrain-default.eff which already has everything in it.
Explanation sorely needed? :oops:
Kansas and Ohio/Midwest scenery development.
KEQA, 3AU, KRCP Airport Layout
Intel i7/GeForce RTX 2070/Max-Q
User avatar
wlbragg
 
Posts: 7586
Joined: Sun Aug 26, 2012 12:31 am
Location: Kansas (Tornado Alley), USA
Callsign: WC2020
Version: next
OS: Win10/Linux/RTX 2070

Re: ALS landing lights

Postby Thorsten » Wed Oct 08, 2014 8:58 am

Okay, let's try to go over the basics of an effect file:

An effect is a container for a series of techniques which are all the possible things you could do with some object.

The <predicate> section inside each effect determines which of the techniques we actually run. Typically the predicate section contains conditionals on a) rendering framework properties b) OpenGL extension support and c) quality level properties. The renderer searches the effects from lowest to highest technique number and uses the first one that fits the bill (which is why high quality levels precede low quality levels).

The rendering itself is specified as <pass> - each pass runs the renderer over the whole scene. We may sometimes make a quick first pass to fill the depth buffer or a stencil buffer, but usually we render with a single pass.

Techniques may not involve a shader at all, for instance 12 in terrain-default is a pure fixed pipeline fallback technique, but all the rendering you're interested in use a shader, which means they have a <program> section which determines what actual code is supposed to run.

If you run a shader, that needs parameters specified as <uniform>, and textures which need to be assigned to a texture unit _and_ be declared as a uniform sampler.

In addition, each technique contains a host of parameter configuring the fixed pipeline elements, like alpha tests before the fragment stage, or depth buffer writing/reading, alpha blending,... you can ignore them on the first go.

So if you want to look at which shader code is executed when you call the water effect at a certain quality level, you need to work your way through the predicate sections of the techniques from lowest to highest till you find the one that matches, and then look into the program section of that technique.

Now, to make matters more complicated, all the parameters and textures that are assigned to uniforms and texture units in the techniques need to be declared and linked to properties were applicable in the <parameters> section heading each effect declaration. So a texture you want to use has to appear three times - in the parameters section heading the effect, inside the technique assigned to a texture unit and assigned to a uniform sampler.

Now, inheritance moves all the declared parameters and techniques from one effect to the one inheriting. In the case of water, that means the technique is actually _not_ inherited because terrain-default.eff doesn't contain a technique 1 at all, but the general <parameters> section is inherited. So you don't need to declare the additions to <parameters> again, but you do need to make the changes to the <programs> and the <uniform> sections.

The compilation error you're getting suggests that you did not modify the <program> section of the technique 1 in water.eff.

What is going on here?


No idea - is it peculiar to the model in question?
Thorsten
 
Posts: 12490
Joined: Mon Nov 02, 2009 9:33 am

PreviousNext

Return to Effects and shaders

Who is online

Users browsing this forum: No registered users and 6 guests