Board index FlightGear Development Effects and shaders

ALS aircraft 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 aircraft lights

Postby jam007 » Sun Apr 16, 2017 5:59 pm

Thanks!
Good catch! :)
jam007
 
Posts: 477
Joined: Sun Dec 16, 2012 10:04 am
Location: Uppsala, Sweden
Version: 2017.3.1
OS: Ubuntu 16.04

Re: ALS aircraft lights

Postby legoboyvdlp » Sat Feb 24, 2018 1:50 am

Thorsten wrote in Wed Aug 03, 2016 5:54 pm:[Image

Image



Just checking - did this new lighting technique ever get commited, or is it still pending, while, as far as I remember, Richard was doing something so that Rembrandt lighting definitions were being reused? The reason I am asking is, I do not mind it being more complex to add it to the IDG-A32X (there are no Rembrandt definitions, so I cannot reuse them anyway), but I would need to know if this is actually in 2018.1 or not. If so, I'll be able to create them by observing the SpaceShuttle...

Edit: the lnding lights of the 172 seem to use this effect, in that they do not have the problem with outside views which the ALS secondary lights have?

Edit 2: and yes, I am talking about the illumination of the ground, not the light source itself :mrgreen:
User avatar
legoboyvdlp
 
Posts: 5840
Joined: Sat Jul 26, 2014 1:28 am
Callsign: YV-LEGO
Version: 2018.3.1
OS: Windows 10 HP

Re: ALS aircraft lights

Postby wlbragg » Sat Feb 24, 2018 4:02 am

did this new lighting technique ever get commited


Yes it is a standard in fgdata .The c172p does use it when in exterior view and it uses the ALS secondary lights when in interior view.
Kansas(2-27-15)/Ohio/Midwest scenery development.
KEQA (2-27-15), 3AU, KRCP Airport Layout
User avatar
wlbragg
 
Posts: 4183
Joined: Sat Aug 25, 2012 11:31 pm
Location: Kansas (Tornado Alley), USA
Callsign: WC2020
Version: next
OS: Win10/Debain/nVGT640

Re: ALS aircraft lights

Postby Thorsten » Sat Feb 24, 2018 6:52 am

If so, I'll be able to create them by observing the SpaceShuttle...


That'll probably confuse you major, because the lights the Shuttle uses for landing are mobile lights on the ground, i.e. the lightspot never changes during the approach regardless of where the Shuttle is - I'm guessing you want lights attached to the aircraft instead...

Anyway, take a look at the effect manager of the Alouette-III, I've written it as an example of how to implement the various effects.
Thorsten
 
Posts: 10000
Joined: Mon Nov 02, 2009 8:33 am

Re: ALS aircraft lights

Postby legoboyvdlp » Sat Feb 24, 2018 3:45 pm

Good. I'll look at the Alouette-III, I meant to fly it anyway... :)

@wlbragg, I never noticed the nav lights shining on the ground, that must not be implemented yet...?
User avatar
legoboyvdlp
 
Posts: 5840
Joined: Sat Jul 26, 2014 1:28 am
Callsign: YV-LEGO
Version: 2018.3.1
OS: Windows 10 HP

Re: ALS aircraft lights

Postby wlbragg » Sat Feb 24, 2018 9:13 pm

I never noticed the nav lights shining on the ground,

If your talking about landing lights and a taxi light, or nav lights (red, green and white) yes they are, both from an interior and exterior view if I remember correctly. See the image above. Also if I am remembering correctly interior and exterior are using two different techniques for at least taxi and landing lights. The Alouette-III code would be the better example as it is written with fluidity in mind, I would imagine. The effects in the c172p, more than likely, are more disjointed simply due to the fact that most of the effects were added piecemeal.
Kansas(2-27-15)/Ohio/Midwest scenery development.
KEQA (2-27-15), 3AU, KRCP Airport Layout
User avatar
wlbragg
 
Posts: 4183
Joined: Sat Aug 25, 2012 11:31 pm
Location: Kansas (Tornado Alley), USA
Callsign: WC2020
Version: next
OS: Win10/Debain/nVGT640

Re: ALS aircraft lights

Postby abassign » Fri Jul 27, 2018 2:45 pm

Hi, I'm trying to activate the landing and taxi light, by switching in NASAL code:

setprop("controls/lighting/landing-lights",1);
setprop("controls/switches/landing-lights",1);

but nothing happens ... :(

Even if the electrical system I use ... is not the system, but anyway the system voltage is 28V and the /systems/electrical/outputs/taxi-light is 28V. At this point I think there is some prerequisite not satisfied. I'd be curious to know which one.

My second question is that if it then starts working, how can the effect parameters be modified? I think there is a .eff file to configure, but I can not find documentation. The C172P makes the most of the effect, but the code is complex and difficult to follow, it does not seem very suitable for me to understand the basic lighting mechanism.

Thanks for your help :)
abassign
 
Posts: 737
Joined: Mon Feb 27, 2012 5:09 pm
Location: Italy (living 5 Km from airport LIME)
Callsign: I-BASSY
Version: 2018.3
OS: Linux Mint 19. x

Re: ALS aircraft lights

Postby wlbragg » Fri Jul 27, 2018 4:00 pm

Need more info, what are you trying to do, in what aircraft, what part of the code are you having trouble with, code examples?

setprop("controls/lighting/landing-lights",1);

What does the code that is using these properties look like?
Kansas(2-27-15)/Ohio/Midwest scenery development.
KEQA (2-27-15), 3AU, KRCP Airport Layout
User avatar
wlbragg
 
Posts: 4183
Joined: Sat Aug 25, 2012 11:31 pm
Location: Kansas (Tornado Alley), USA
Callsign: WC2020
Version: next
OS: Win10/Debain/nVGT640

Re: ALS aircraft lights

Postby Thorsten » Fri Jul 27, 2018 4:45 pm

Hi, I'm trying to activate the landing and taxi light, by switching in NASAL code:

setprop("controls/lighting/landing-lights",1);
setprop("controls/switches/landing-lights",1);

but nothing happens ...


I'd guess that's because these are just random properties unrelated to the effect.... but as wlbragg pointed out, it'd be good to know what aircraft this refers to.

I think there is a .eff file to configure, but I can not find documentation.


Keep looking, it's in the wiki, same place every other ALS documentation is.

Edit: Actually, I'm wrong, the lightspots described in this thread are (by design) undocumented because Richard had plans to simplify the usage - currently the Alouette-III code contains sample code how this might be implemented for anyone who wants to muddle through on his own - but since this isn't officially released, the usage might change without prior warning, and I won't help with the implementation.
Thorsten
 
Posts: 10000
Joined: Mon Nov 02, 2009 8:33 am

Re: ALS aircraft lights

Postby wkitty42 » Mon Jul 30, 2018 5:17 pm

we've been working with some AI craft and adding these procedural ALS lights to them... we've run into a few things...

1. all of the lights blink in unison. there's no randomization. so all strobes and beacons blink at the same time on all of the many craft at an airport or flying near by... i would have thought they'd be separated by their spawn times so that one spawned .5 second before another would blink .5 seconds different or maybe based on when their controlling boolean property allows them to be selected and start lighting...

2. some craft have beacons that are faster than others. some have strobes that blink certain patterns. can we have a feature added so that we can specify the strobe pattern to be used when is_strobe is true? maybe something like this?
Code: Select all
<strobe_pattern>[0.2, 0.2, 0.2, 0.5, 0.2, 1.5]</strobe_pattern>    this one could be for strobes. 2 fast blinks, .5 sec delay, 1 blink
<strobe_pattern>[0.3, 0.5]</strobe_pattern>                        this one could be for beacons that are faster than normal beacons.
<strobe_pattern>[0.5, 1.0]</strobe_pattern>                        this one could be for beacons that are slower than normal beacons.
<strobe_pattern>[0.0, 0.0]</strobe_pattern>                        this one could be for beacons that use the existing strobe timing.
                                                                   if this property doesn't exist, the existing strobe timing would be used

IIRC, the above number sets are arrays as used in nasal... the numbers are "on time", "off time" in float seconds... i don't know if there was a limit on the number of these pairs we could put in the nasal code we were using... we definitely had different sequences that all craft assigned to that eff file would use... there were also a few with a five or six blink pattern... that was pretty cool looking, too... 5 fast blinks followed by 1.5 seconds of no blinks... definitely an attention getter... especially at night and suddenly you see their strobes when they are 20nm or more away :)

we've used nasal with these timings and things are ok until you get too many craft and then things kinda slow down and some lights that were working don't any more... let some craft get out of range and the non-working ones would suddenly start working... adding strobe patterns to this effect would be great! then we can have different craft with different blink patterns... especially since each craft has its own eff assignments for each of the external lights that blink differently than others...
"You get more air close to the ground," said Angalo. "I read that in a book. You get lots of air low down, and not much when you go up."
"Why not?" said Gurder.
"Dunno. It's frightened of heights, I guess."
User avatar
wkitty42
 
Posts: 4773
Joined: Fri Feb 20, 2015 3:46 pm
Location: central NC, USA
Callsign: wk42
Version: git next
OS: Kubuntu 14.04.5

Re: ALS aircraft lights

Postby Thorsten » Mon Jul 30, 2018 5:36 pm

1. all of the lights blink in unison. there's no randomization. so all strobes and beacons blink at the same time on all of the many craft at an airport or flying near by... i would have thought they'd be separated by their spawn times so that one spawned .5 second before another would blink .5 seconds different or maybe based on when their controlling boolean property allows them to be selected and start lighting...


They're by default driven by osg_SimulationTime which is the same for all models. If you have the spawn time property, you can try to drive them by that instead (not sure if the effect framework allows to override osg_SimulationTime as uniform, but worth a try).

2. some craft have beacons that are faster than others. some have strobes that blink certain patterns. can we have a feature added so that we can specify the strobe pattern to be used when is_strobe is true?


The idea was that if you need something more detailed, you drive it by the on/off property. Strobe true is simply a cheap stand-in for a customized setup. It turns out GLSL isn't very good to drive the strobe, I've had all sorts of issues (especially at lower famerates), so I did not pursue the approach further. There's no thing like a timer in GLSL, so it's mainly based on suitably interfering sine waves, which makes it kind of awkward to generalize.

Given that you only need to drive one property for every class of strobe patterns you want to use (and declare that in its own effect file) and given that with a dozen properties you should have enough classes, this seems entirely doable in Nasal/property rules.

You're probably not doing yourself a favour by creating hundreds of different effects either...
Thorsten
 
Posts: 10000
Joined: Mon Nov 02, 2009 8:33 am

Re: ALS aircraft lights

Postby wkitty42 » Mon Jul 30, 2018 5:46 pm

Thorsten wrote in Mon Jul 30, 2018 5:36 pm:They're by default driven by osg_SimulationTime which is the same for all models. If you have the spawn time property, you can try to drive them by that instead (not sure if the effect framework allows to override osg_SimulationTime as uniform, but worth a try).

i have no clue about that being in the property tree...

Thorsten wrote in Mon Jul 30, 2018 5:36 pm:
2. some craft have beacons that are faster than others. some have strobes that blink certain patterns. can we have a feature added so that we can specify the strobe pattern to be used when is_strobe is true?


The idea was that if you need something more detailed, you drive it by the on/off property.

doesn't that put us back in nasal territory? territory that we're trying to get away from...


Thorsten wrote in Mon Jul 30, 2018 5:36 pm:Strobe true is simply a cheap stand-in for a customized setup. It turns out GLSL isn't very good to drive the strobe, I've had all sorts of issues (especially at lower famerates), so I did not pursue the approach further. There's no thing like a timer in GLSL, so it's mainly based on suitably interfering sine waves, which makes it kind of awkward to generalize.

uhhhh... i thought this was being driven in C code and then fed to GLSL...

Thorsten wrote in Mon Jul 30, 2018 5:36 pm:Given that you only need to drive one property for every class of strobe patterns you want to use (and declare that in its own effect file) and given that with a dozen properties you should have enough classes, this seems entirely doable in Nasal/property rules.

yeah, as noted previously, we're trying to get away from nasal and its overhead... this was seen (and hoped) to be a/the solution...

Thorsten wrote in Mon Jul 30, 2018 5:36 pm:You're probably not doing yourself a favour by creating hundreds of different effects either...

i was wondering about that but what can you do if you have 20 ERJ195's all spawned at one airport and they each have seven lights? that's 140 effects in memory and they're all using the same .ac files and .eff files... we're not even loading any other craft which will bring another 7 (minimum?) lights each... some will bring 8 if there's a tail strobe, too...
"You get more air close to the ground," said Angalo. "I read that in a book. You get lots of air low down, and not much when you go up."
"Why not?" said Gurder.
"Dunno. It's frightened of heights, I guess."
User avatar
wkitty42
 
Posts: 4773
Joined: Fri Feb 20, 2015 3:46 pm
Location: central NC, USA
Callsign: wk42
Version: git next
OS: Kubuntu 14.04.5

Re: ALS aircraft lights

Postby Thorsten » Tue Jul 31, 2018 5:24 am

doesn't that put us back in nasal territory? territory that we're trying to get away from.


Not necessarily - it requires you to create and drive a dozen different strobe properties somehow. This can equally well be via property rules (or a C++ module).

uhhhh... i thought this was being driven in C code and then fed to GLSL...


Nope, but with a property rule, you can in essence achieve just that - which is why I wasn't worried about GLSL being limited here.

yeah, as noted previously, we're trying to get away from nasal and its overhead... this was seen (and hoped) to be a/the solution...


If you try to do it per aircraft, the property overhead is going to cripple you for a few hundred craft. If you do it per strobe sequence and (randomly?) assign strobe sequences to aircraft, then no matter how many aircraft you have, the strobe overhead will remain constant and relatively small.

The procedural light (and much less the strobe) was never intended to be applied to hundreds of objects - pretty much all other lights in the scene are auto-generated point sprites and utilize a different shader - the procedural light should just allow modelers to get the same visuals for their craft.

i was wondering about that but what can you do if you have 20 ERJ195's all spawned at one airport and they each have seven lights? that's 140 effects in memory and they're all using the same .ac files and .eff files... we're not even loading any other craft which will bring another 7 (minimum?) lights each... some will bring 8 if there's a tail strobe, too...


Generating the strobe properties is going to be the smallest part of your trouble... Eventually (dependent on GPU of course) you'll jam the pipeline with the overhead of switching from one effect to the next - and that's a problem you can't solve without core changes, the normal way of loading models doesn't scale well, especially if you make them detailed.

Anyway, my best suggestion here is

* create a relatively low number of strobe sequence generators (Nasal, property rules,...)
* assign each light to one generator via its effect file
* keep things simple and don't try to create highly realistic models with all lighting effects
Thorsten
 
Posts: 10000
Joined: Mon Nov 02, 2009 8:33 am

Re: ALS aircraft lights

Postby wkitty42 » Tue Jul 31, 2018 7:38 pm

Thorsten wrote in Tue Jul 31, 2018 5:24 am:
doesn't that put us back in nasal territory? territory that we're trying to get away from.


Not necessarily - it requires you to create and drive a dozen different strobe properties somehow. This can equally well be via property rules (or a C++ module).

somehow, that's what i/we thought procedural lighting was... i/we didn't grok that it was actually named "ALS procedural lighting"... it is basically what we want, though... mainly to get shed of the textures used for so many of these types of lights... the effect generates that star and light blobs very nicely... if it is actually a texture, that would be nice to know so maybe it could be used with this other stuff...

Thorsten wrote in Tue Jul 31, 2018 5:24 am:
uhhhh... i thought this was being driven in C code and then fed to GLSL...


Nope, but with a property rule, you can in essence achieve just that - which is why I wasn't worried about GLSL being limited here.

ok... so for now, we're back to using nasal to drive them... hopefully someone can do the C code to provide the effect and we can dump the nasal and use xml properties to set up the timings an such... i'm still trying to figure out how to get that nasal stuff to create the necessary properties in the craft's ai/models/aircraft* branch and keep it out of /sim/model where they are polluting the property tree... we're getting closer but my arms are getting tired of swinging the sledge hammer ;)

Thorsten wrote in Tue Jul 31, 2018 5:24 am:
yeah, as noted previously, we're trying to get away from nasal and its overhead... this was seen (and hoped) to be a/the solution...


If you try to do it per aircraft, the property overhead is going to cripple you for a few hundred craft. If you do it per strobe sequence and (randomly?) assign strobe sequences to aircraft, then no matter how many aircraft you have, the strobe overhead will remain constant and relatively small.

per strobe what we're looking to do, yes... the problem is getting the flow of the code right... i thought i had a way of assigning the strobes to a group, the beacons to another group and the navlights to a 3rd group but then ran into the problem of getting them positioned right... using the groups is ok for switching them on/off... if they're on, then the timed sequence will control their blinking... with nasal, we're setting the timed sequence with aircraft.light.new but i'm having a time getting it to use the craft's ai/models/aircraft* branch...

Thorsten wrote in Tue Jul 31, 2018 5:24 am:The procedural light (and much less the strobe) was never intended to be applied to hundreds of objects - pretty much all other lights in the scene are auto-generated point sprites and utilize a different shader - the procedural light should just allow modelers to get the same visuals for their craft.

ok...

Thorsten wrote in Tue Jul 31, 2018 5:24 am:
i was wondering about that but what can you do if you have 20 ERJ195's all spawned at one airport and they each have seven lights? that's 140 effects in memory and they're all using the same .ac files and .eff files... we're not even loading any other craft which will bring another 7 (minimum?) lights each... some will bring 8 if there's a tail strobe, too...


Generating the strobe properties is going to be the smallest part of your trouble... Eventually (dependent on GPU of course) you'll jam the pipeline with the overhead of switching from one effect to the next - and that's a problem you can't solve without core changes, the normal way of loading models doesn't scale well, especially if you make them detailed.

i'm not sure what you mean by "switching them from one effect to another"... we're not changing the effect... we're setting one effect for each light... right now there's seven lights per craft... so that's at least seven effects for each craft... since these are simple AI Traffic craft, the loading is minimal... an xml loading the craft's ac file and then loading the lights with each of their ac files... when the lights load via their xml, they are scaled, dist-scaled and the effect assigned... when we exit the light loading xml, then lights are positioned... finally they are grouped and select animations are used for the groups for when the lights are turned on/off via a property... no matter if the lights are selected (on or off) the nasal still makes the timed status changes...

Thorsten wrote in Tue Jul 31, 2018 5:24 am:Anyway, my best suggestion here is

* create a relatively low number of strobe sequence generators (Nasal, property rules,...)
* assign each light to one generator via its effect file
* keep things simple and don't try to create highly realistic models with all lighting effects

i think we're pretty close to that... maybe the ordering of the loading can be adjusted? if we ignore the directionality of the lights and just use light blobs as provided by the effect file, then we can use one effect for the beacons and one for the strobes... the navigation lights, on the other hand, have to use different effect files because of the different colors they have...
"You get more air close to the ground," said Angalo. "I read that in a book. You get lots of air low down, and not much when you go up."
"Why not?" said Gurder.
"Dunno. It's frightened of heights, I guess."
User avatar
wkitty42
 
Posts: 4773
Joined: Fri Feb 20, 2015 3:46 pm
Location: central NC, USA
Callsign: wk42
Version: git next
OS: Kubuntu 14.04.5

Re: ALS aircraft lights

Postby Thorsten » Wed Aug 01, 2018 5:26 am

if it is actually a texture, that would be nice to know so maybe it could be used with this other stuff...


procedural = appearance is created by evaluating a function rather than using a lookup-table (aka texture).

I'm not sure about why you brought this up here, because the on-off behavior of a procedural strobe can still be property-controlled (or not).

Suppose you have a property /flash/on which is true or false - you can

* assign this to any number of procedural lights to switch them (simultaneously)
* and drive it by any means to set a property - that includes manually toggling in the property browser, writing a Nasal snippet to control it or have a property rule output to it

So the question of how the light looks is completely unrelated to how its on/off behavior is controlled.

ok... so for now, we're back to using nasal to drive them...


No, as I said, if you don't want to use Nasal and imagine a C++ like setup, you can all do it in property rules. Usually it's possible to write equivalent code - when you need decisions per frame, property rules usually are superior in performance, when you need to evaluate complex logic now and then, Nasal is better.

hopefully someone can do the C code to provide the effect and we can dump the nasal and use xml properties to set up the timings an such..


Nobody will do that, because using property rules you can achieve that right now, so from a coding POV this is redundant work and bad design.

i thought i had a way of assigning the strobes to a group, the beacons to another group and the navlights to a 3rd


Assume you have a dozen strobe generator populating the array

/flash/light[i]/intensity

with strobe timing patterns.


Create a dozen base effects inheriting from procedural-light.eff, each of them altering one line to read

<intensity_scale type="float"><use> /flash/light[0]/intensity</use></intensity_scale>

(and so on for the other indexes). Call these strobelight0.eff to strobelight11.eff.

Now when you want to equip an aircraft with the strobe light, make it inherit the pattern you want, say strobelight0.eff, then alter all the lines you want different (like directionality).

i'm not sure what you mean by "switching them from one effect to another"... we're not changing the effect...


Sure you are - if you deliver the whole aircraft to the GPU with a merged mesh and a single texture sheet, the GPU will read the effect, compute the state-set needed, compile the shaders requested and then crunch through the whole mesh - the mesh can have a million vertices, it'll still be blindingly fast because the state set needs to be prepared once.

If you have your aircraft broken into 20 different parts, each of them having its own effect (and possible a separate texture sheet), the GPU needs to prepare the state set 20 times, possibly bring new shaders into the fray or even load new textures into GPU memory - even if the total number of vertices is just 50.000, the overhead from changing the effect will make it render much slower.

So every time you break a model into different objects and add an extra effect declaration to such an object, you should fundamentally think of this as costing rendering performance.

For the model you're flying, this usually doesn't matter overly much, rarely aircraft need a couple of hundred switches (yes, every animation changes the transformation matrices and also forces a new state set) - for a hundred AI craft with rudimentary animations and lights, you might easily reach 1000+ such changes.

Which, by the way, is why all the OSMCity buildings are not 20.000 individual buildings each with its own texture but internally all merged into the same mesh, referencing the same texture atlas - that makes it possible to render them at minimal cost.

So by lavishly equipping AI craft with different animations and effects, you will hit this issue sooner or later.
Thorsten
 
Posts: 10000
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 9 guests