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 wkitty42 » Wed Aug 01, 2018 1:56 pm

Thorsten wrote in Wed Aug 01, 2018 6:26 am:
if it is actually a texture, that would be nice to know so maybe it could be used with this other stuff...

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

i brought it up because it looks good and if it was a texture, generated or existing in a png file, i wanted to use it because some of the others just look like a dog's twice eaten breakfast... the look of the lights was the main attraction for me when i saw them...

also, in the discussions, several sub-topics have been talked about... "how to make them blink", "how to make them blink in a pattern", "how they look in the sim" are three different sub-topics that have all been in one or more posts mixed in with the rest of the text... i've never been one to ask only one question in a post... sometimes i ask four or five and am then left hanging when only one is answered and the others either simply missed or possibly ignored :shrug:

now i'll go back and read the rest of your post ;)
"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: 9123
Joined: Fri Feb 20, 2015 4:46 pm
Location: central NC, USA
Callsign: wk42
Version: git next
OS: Kubuntu 20.04

Re: ALS aircraft lights

Postby wkitty42 » Wed Aug 01, 2018 2:21 pm

Thorsten wrote in Wed Aug 01, 2018 6:26 am:
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.

i'm sorry... i don't understand... we're currently using nasal that apparently runs in a loop to cause lights to blink in a pattern... i don't understand how we can do that with property rules...

Thorsten wrote in Wed Aug 01, 2018 6:26 am: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.

i definitely recognize nasal for that type of processing... it has variables that you can store things in like any good programmer needs to do at times... i understand that property rules are faster and have lower overhead but without variable storage...

Thorsten wrote in Wed Aug 01, 2018 6:26 am:
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,

working example, please?

Thorsten wrote in Wed Aug 01, 2018 6:26 am:so from a coding POV this is redundant work and bad design.

no kidding! hahaha... we've done the best we could with what we had and the knowledge we understood ;)

Thorsten wrote in Wed Aug 01, 2018 6:26 am:
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).

wowowowow... if i'm understanding correctly, that's a lot more engineering for little gain... but in this case, with the nasal code we now have, the above is simply

<intensity_scale type="float"><use>controls/lighting/strobes</use></intensity_scale>

for all craft because we finally got the code corrected to find the craft's ai/models/aircraft* branch and use it... then we just use relative pathing from there... that's a major PITA that i've been chasing for over a month! finally Richard gave us a hint and then we were off to the races...

but back to this... if we do create a bunch of base effects with different flash/light[x]/intensity on/off pairs, how to we make this xml code cause the state to change between true and false using those tenth second timings? that's the part i don't get... nasal can do that loop but how to do it in xml?

Thorsten wrote in Wed Aug 01, 2018 6:26 am:
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.

so it would be better to combine the current beacon-top, beacon-bottom, navlight-left, navlight-right, navlight-tail, strobe-left, strobe-right all into one ac file, load them once and then assign the effect and move on like we've been doing? i think that merging can be done manually... the main thing about these individual ones is that there is no texture in the ac file... i think that has been the biggest difference...

the best way would be to go take another year and learn blender to add the lights to the AI Traffic craft's model unless it already has some... the trick then is to make sure they, the lights, have the proper names used by the light code... then the lights are loaded when the model is loaded and we can simply go from there without having to specifically load and position the lights... we'd probably still need to scale and dist-scale them, though??

does it matter when we assign the effect? if i'm understanding the process correctly, it is pretty linear... the code loads the model from the ac file, scales it, dist-scales it, then assigns the effect... could we load the model and assign the effect and then do the scaling and positioning later in the code? i've read a few times that the order of things is important and i kinda saw that when i was fumbling about at one point and the lights were much larger and way out of position which i think was due to scaling being done and then translation... it was like the scale made the translation much larger then it had been... the reason i'm asking about this is because of the work being done to centralize the code... the models and the effects can be centralized with a loading xml and then each craft can handle the scale and positioning once we return from the load xml... i'm just trying to figure out how it can be done and still allow for a craft to customize something like the blink pattern if desired... right now that's nasal until i can figure out this property format you spoke of... i think it is what someone called "xml code" at one time...

geez, i've been up three hours and still haven't gotten my c0ffee... i'll be right back ;)
"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: 9123
Joined: Fri Feb 20, 2015 4:46 pm
Location: central NC, USA
Callsign: wk42
Version: git next
OS: Kubuntu 20.04

Re: ALS aircraft lights

Postby Thorsten » Wed Aug 01, 2018 6:24 pm

that's a lot more engineering for little gain... (...) but in this case, with the nasal code we now have, the above is simply

<intensity_scale type="float"><use>controls/lighting/strobes</use></intensity_scale>

for all craft because we finally got the code corrected to find the craft's ai/models/aircraft* branch and use it...


But for 100 aircraft, you're then back to updating 700 properties per frame, rather than a dozen. So whether reducing the overhead from 700 updates to ~ 1/70 of that is 'a little' is up to discussion.

how to we make this xml code cause the state to change between true and false using those tenth second timings?


You use /sim/time/elapsed-sec in whatever filter / state machine combination you'd like to have. I don't know property rule syntax overly much, I usually do it in JSBSim because my use cases are aircraft-specific, but given that the two are supposed to be equivalent, it ought to be very doable.

that's the part i don't get... nasal can do that loop but how to do it in xml?


property rules are evaluated per frame, so they loop implicitly, you don't have to do anything.

so it would be better to combine the current beacon-top, beacon-bottom, navlight-left, navlight-right, navlight-tail, strobe-left, strobe-right all into one ac file, load them once and then assign the effect and move on like we've been doing


No - you actually have to reduce the number of lights and animations on the aircraft. Given the way FG loads and processes 3d models, there's not really much you can do except simplify each single model you want to show. Whenever we have a subsystem that is performing better (random buildings and vegetation, OSM2City objects) we use dedicated techniques like instancing or merging all into one mesh - which you can't do without C++ modifications (I suppose we could instance AI aircraft, but it'd be quite some work...)
Thorsten
 
Posts: 12490
Joined: Mon Nov 02, 2009 9:33 am

Re: ALS aircraft lights

Postby wkitty42 » Wed Aug 01, 2018 9:38 pm

it is starting to come together... i'm gonna have to think it over a bit and probably reread this discussion a few times...

about "simplify each single model you want to show"... the AI Traffic models are all pretty well stripped and low poly... the seven or eights lights i'm using are all exactly like this except for the object name...
Code: Select all
AC3Db
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 "DefaultWhite.001" rgb 1 1 1 amb 0.2 0.2 0.2 emis 0 0 0 spec 0.025 0.025 0.025 shi 50 trans 0.1
OBJECT world
kids 1
OBJECT poly
name "Top_Beacon_Red"
data 8
Mesh.005
crease 30.000000
numvert 4
-0.090665 -0.991468 -0.999611
-0.090663 1.008532 -0.999611
-0.090662 -0.991468 1.000389
-0.090661 1.008532 1.000389
numsurf 1
SURF 0x20
mat 1
refs 4
1 0.0 0.0
0 0.0 0.0
2 0.0 0.0
3 0.0 0.0
kids 0

i don't think they can get much simplier than that ;) i especially like them because there is no texture and the eff provides the coloration and any blinking... so real simple craft models with maybe three retractable landing gear and the fuselage plus these simple light objects... if there's another way to provide coloration and blinking without using the effect AND without using a texture, i'm all ears as that would eliminate the effect overhead we've been talking about ;)
"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: 9123
Joined: Fri Feb 20, 2015 4:46 pm
Location: central NC, USA
Callsign: wk42
Version: git next
OS: Kubuntu 20.04

Re: ALS aircraft lights

Postby abassign » Thu Aug 02, 2018 12:18 am



For the beacon I think there may be a valid alternative:
having to reproduce the beacon model G8400A24-24 (which is also used in many civil aviation and pleasure aircraft of the years 50-80) I used the technique based on electro-mechanical reproduction exploiting both the emissive surfaces and the procedural-light effects.

Image

In the example we use 3 effects, two for tied to a rotating element to simulate the flash of the beams and a third to illuminate the dome from the outside, while from the inside we use various emissive surfaces controlled by the ambient light. The electrical system that manages the device is written in JSBSim, while the management of light emissions according to ambient light in NASAL.

I would love to insert two conical beams that illuminate the fuselage of the plane, but I do not know which is the best solution. I saw something with the interior lights of the C172 but I do not know if it can be a good solution. ALS flashlight would be great, but you can duplicate it to have two beams and follow, instead of your point of view, a certain direction (that of the beam).

Can anyone offer me a solution?
Developer of the program https://wiki.flightgear.org/Julia_photoscenery_generator
FDM developer of the G91R1B aircraft https://wiki.flightgear.org/FIAT_G91R1B
JSBSim collaborator
abassign
 
Posts: 947
Joined: Mon Feb 27, 2012 6:09 pm
Location: Italy (living 5 Km from airport LIME)
Callsign: I-BASSY
Version: 2020.4
OS: Ubuntu 20.10

Re: ALS aircraft lights

Postby Thorsten » Thu Aug 02, 2018 6:29 am

the AI Traffic models are all pretty well stripped and low poly... the seven or eights lights i'm using are all exactly like this except for the object name...


Low-poly doesn't matter nearly as much as number of parts.

Whenever you have an animation, you have a static and a movable part - which means one of the transformation matrices is different - which means a new state set,

Whenever you're declaring a new procedural light - new state set.

Whenever you have a glass surface with transparency declared - new render bin, new state set.

Even if you just break your model into 'fuselage' and 'wing' objects - new state set (with same parameters though).

Anything in your ac model with a distinct object name - new state set.

That's how it works conceptually. In practice, changing a single parameter in a state set is much faster than changing to a different set of texture sheets, and the NVIDIA driver is usually much better in doing all of this quickly than the nouveau driver etc.

So to get good visual quality, you can't optimize everything to death, you need to use different effects. You just need to be aware that if you introduce a large number of objects, then you will run into these issues eventually and reducing complexity (rather than poly count) will help you.

That's really all.

i'm all ears as that would eliminate the effect overhead we've been talking about


As I said, the general model loader being how it is, I don't think you can do anything without a massive C++ intervention to use a special optimization.
Thorsten
 
Posts: 12490
Joined: Mon Nov 02, 2009 9:33 am

Re: ALS aircraft lights

Postby Thorsten » Thu Aug 02, 2018 6:43 am

Can anyone offer me a solution?


If you really like coordinate transforms, you can take a look into the high-quality space shader - this has an experimental option to specify a light geometry (intersection with a blurry light sphere at a property-specified position basically).

It's used to get the outside visuals during SRB-sep at night for instance.

Be warned - there's a reason I didn't introduce this more widely - you'll have to muddle through a lot of coordinate computations. It's not a published feature, just experimental (and moreover considered probably failed), so don't ask for detailed explanations.
Thorsten
 
Posts: 12490
Joined: Mon Nov 02, 2009 9:33 am

Re: ALS aircraft lights

Postby wkitty42 » Thu Aug 02, 2018 11:04 pm

@Thorsten: in the case of AI Traffic lights, which is better?

1. use an effect to blink the lights with a nasal blinking loop
2. use an animation select to blink the lights with a nasal blinking loop
3. use an animation select to blink the lights with some sort of xml to determine the blink pattern
"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: 9123
Joined: Fri Feb 20, 2015 4:46 pm
Location: central NC, USA
Callsign: wk42
Version: git next
OS: Kubuntu 20.04

Re: ALS aircraft lights

Postby Richard » Fri Aug 03, 2018 12:43 am

Personally I'd recommend setting up a bunch of properties, e.g. /flash/light[0..3]/intensity and then use the following code to alias these global properties to ai model properties, and wrap around when the limit is reached.

Feel free to change the actual properties to match what you need; and also don't hesitate to ask questions if you don't understand this.
Code: Select all
    <nasal>
        <load>
        <![CDATA[

                 var self = cmdarg();
                 print("Model load F-15 ", self.getPath());

                 var ai_lighting_node = self.getPath() ~ "/controls/lighting/strobes";
                 var flnode = props.getNode("/sim/lighting/ai-lighting-index",1);
                 var fli = flnode.getValue() or 0;
                 var root_lighting_node = sprintf("/flash/light[%d]/intensity", fli);

                 flnode.setDoubleValue(fli+1);
                 if (fli > 3) #wraparound when end of defined nodes reached
                     fli = 0;
                 print("Using root node ",root_lighting_node," alias to ",ai_lighting_node);
                 props.getNode(root_lighting_node,1).alias(ai_lighting_node);
Richard
 
Posts: 810
Joined: Sun Nov 02, 2014 11:17 pm
Version: Git
OS: Win10

Re: ALS aircraft lights

Postby Thorsten » Fri Aug 03, 2018 7:20 am

@Thorsten: in the case of AI Traffic lights, which is better?

1. use an effect to blink the lights with a nasal blinking loop
2. use an animation select to blink the lights with a nasal blinking loop
3. use an animation select to blink the lights with some sort of xml to determine the blink pattern


Hm... the select anmination generally might give you a marginal performance since the lights not visible are removed from the scenegraph - but then again, it might not because they have to be re-added.

It's not as realistic though, real incandescent lights don't 'just' extinguish when switched off, they have a decay pattern for the intensity which is imo quite notable with strobes - a select animation doesn't do that.

Generally I'd slightly prefer property rules over Nasal to drive the flash sequences, because you need (especially when modeling decay) per frame computations but the actual complexity of what you compute is small - so that's the sweet spot of property rules.

But I suspect that in practice the performance difference between Nasal and property rules for driving a dozen properties might not be measurable.
Thorsten
 
Posts: 12490
Joined: Mon Nov 02, 2009 9:33 am

Re: ALS aircraft lights

Postby abassign » Fri Aug 03, 2018 3:44 pm

Hi I parameterized the brightness values of the beacon according to the ambient brightness through a corrective function of the to be applied to the <intensity_scale> parameter of the effect derived from the procedural-light (which activates the light-ALS.frag and light-ALS.vert) .



The problem that is observed from the test is the presence of an intense glare effect around the beacon during the typical brightness of the day (at night instead it seems all quite correct). Unfortunately I can not reduce the brightness of the beacon beam too much because I would lose the central spot that is essential to observe the beacon during the day. It would be useful to make the outer (red) part of the glare more transparent, perhaps with a specific parameter and to change the angle of the central spot. The central spot has a dimension that seems to depend on the intensity, but this does not allow for a narrower beam spot. I would be curious to know if this possibility already exists, and if you can parametrizzate it. The Wiki does not seem to report anything useful.

Code: Select all
<?xml version="1.0" encoding="utf-8"?>
<PropertyList>

    <name>procedural_light_beacon_01</name>
    <inherits-from>Effects/procedural-light</inherits-from>

    <parameters>
        <light_color_base_r type="float">1.0</light_color_base_r>
        <light_color_base_g type="float">0.0</light_color_base_g>
        <light_color_base_b type="float">0.0</light_color_base_b>
        <light_color_center_r type="float">1.0</light_color_center_r>
        <light_color_center_g type="float">0.8</light_color_center_g>
        <light_color_center_b type="float">0.8</light_color_center_b>
        <intensity_scale>
            <use>sim/G91/lightning/beacon-light/intensity_effect</use>
        </intensity_scale>

        <!-- Arc is 140 deg, is 70 deg per side -->
        <pointing_x type="float">0.2</pointing_x>
        <pointing_y type="float">0.0</pointing_y>
        <pointing_z type="float">0.0</pointing_z>

        <is_directional type="bool">true</is_directional>
        <is_strobe type="bool">false</is_strobe>

        <inner_angle type="float">0.1</inner_angle>
        <outer_angle type="float">0.8</outer_angle>
        <zero_angle type="float">0.0</zero_angle>
        <outer_gain type="float">0.0</outer_gain>
    </parameters>

</PropertyList>
Developer of the program https://wiki.flightgear.org/Julia_photoscenery_generator
FDM developer of the G91R1B aircraft https://wiki.flightgear.org/FIAT_G91R1B
JSBSim collaborator
abassign
 
Posts: 947
Joined: Mon Feb 27, 2012 6:09 pm
Location: Italy (living 5 Km from airport LIME)
Callsign: I-BASSY
Version: 2020.4
OS: Ubuntu 20.10

Re: ALS aircraft lights

Postby Thorsten » Fri Aug 03, 2018 3:57 pm

Hi I parameterized the brightness values of the beacon according to the ambient brightness through a corrective function of the to be applied to the <intensity_scale> parameter of the effect derived from the procedural-light (which activates the light-ALS.frag and light-ALS.vert) .


I guess I told you already that the aircraft modeler is not supposed to do any corrections to ambient brightness as the shader does them already.
Thorsten
 
Posts: 12490
Joined: Mon Nov 02, 2009 9:33 am

Re: ALS aircraft lights

Postby abassign » Fri Aug 03, 2018 4:34 pm

Thorsten wrote in Fri Aug 03, 2018 3:57 pm:I guess I told you already that the aircraft modeler is not supposed to do any corrections to ambient brightness as the shader does them already.


The NASAL code

Code: Select all
# Calculate Beacon light emission by ambient lux

var prop = props.globals.initNode("sim/G91/lightning/beacon-light/intensity", 0, "DOUBLE");
var prop = props.globals.initNode("sim/G91/lightning/beacon-light/emission_cover", 0, "DOUBLE");
var prop = props.globals.initNode("sim/G91/lightning/beacon-light/intensity_effect", 0, "DOUBLE");
var prop = props.globals.initNode("sim/G91/lightning/beacon-light/intensity_mirror", 0, "DOUBLE");
var prop = props.globals.initNode("sim/G91/lightning/beacon-light/intensity_bulb", 0, "DOUBLE");
var prop = props.globals.initNode("sim/G91/lightning/beacon-light/transparent_cover", 0, "DOUBLE");
var prop = props.globals.initNode("sim/G91/lightning/beacon-light/transparent_glass", 0, "DOUBLE");

var prop = props.globals.initNode("sim/G91/Test/V0_10A", 0, "DOUBLE");

var timerFrontal_gear_lights = maketimer(0.1, func() {
    var beacon_light = props.globals.getNode("fdm/jsbsim/systems/lightning/beacon/on",1).getValue();
    var ambientRedLight = props.globals.getNode("/rendering/scene/ambient/red",1).getValue();
    var pl_emission = 0.0;
    if (beacon_light > 0.001) {
        pl_emission = -29.7 * math.pow(ambientRedLight,3) + 6.7 * math.pow(ambientRedLight,2) - 1.29 * ambientRedLight + 0.97;
        pl_emission_effect = 70 * math.pow(ambientRedLight,4) - 63 * math.pow(ambientRedLight,3) + 18 * math.pow(ambientRedLight,2) - 1.5 * ambientRedLight + 0.75;
        if (pl_emission >= 1.0) {
            pl_emission = 1.0;
        } else if (pl_emission <= 0.01) {
            pl_emission = 0.01;
        }
        setprop("sim/G91/lightning/beacon-light/intensity",pl_emission * beacon_light);
        setprop("sim/G91/lightning/beacon-light/emission_cover",pl_emission * beacon_light);
        setprop("sim/G91/lightning/beacon-light/intensity_effect", pl_emission_effect * beacon_light * 1.2);
        setprop("sim/G91/lightning/beacon-light/intensity_mirror",0.3 + pl_emission * beacon_light);
        setprop("sim/G91/lightning/beacon-light/intensity_bulb",0.3 + pl_emission * beacon_light * 3.0);
        setprop("sim/G91/lightning/beacon-light/transparent_cover", 1 - pl_emission / 4);
        setprop("sim/G91/lightning/beacon-light/transparent_glass", 1 - pl_emission);
    } else {
        setprop("sim/G91/lightning/beacon-light/intensity",0);
        setprop("sim/G91/lightning/beacon-light/emission_cover",0);
        setprop("sim/G91/lightning/beacon-light/intensity_effect",0);
        setprop("sim/G91/lightning/beacon-light/intensity_mirror",0);
        setprop("sim/G91/lightning/beacon-light/intensity_bulb",0);
        setprop("sim/G91/lightning/beacon-light/transparent_cover",1.0);
        setprop("sim/G91/lightning/beacon-light/transparent_glass", 1);
    }
});
timerFrontal_gear_lights.start();


The NASAL code implements some functions of adaptation to ambient light (I chose to use "/rendering/scene/ambient/red" because I found it, after a series of tests carried out in recent months, the most useful. Value is used as an independent variable to obtain a correction parameter useful to make the luminosity of the emissive objects and of the "procedural-light" effects more precise. Is necessary to performs a series of tests in order to obtain the order curve 3 or 4 that best follows the brightness trend of the object infusing the ambient brightness.

It may seem like a complicated way to proceed, but sincerely, the results are excellent and if in the future the adaptation parameters of the "Effects / procedural-light" will change, it will only be necessary to re-parametrizzate the curves that are used by several objects.

Today I did several editing tests of "...fgdata/Shaders/light-ALS.frag" and I have noticed that some parts have been fixed (obviously it is a correct choice for 90% of the aircraft present in FGFS ...), but in our case it is a rather heavy limitation. I think that you can vary the size of the spot and the transparency of the glare allows you to give a great increase in visual quality. Obviously I could make some spot areas with emissive elements, but it gets lost in visual 3D dept.
Developer of the program https://wiki.flightgear.org/Julia_photoscenery_generator
FDM developer of the G91R1B aircraft https://wiki.flightgear.org/FIAT_G91R1B
JSBSim collaborator
abassign
 
Posts: 947
Joined: Mon Feb 27, 2012 6:09 pm
Location: Italy (living 5 Km from airport LIME)
Callsign: I-BASSY
Version: 2020.4
OS: Ubuntu 20.10

Re: ALS aircraft lights

Postby wkitty42 » Fri Aug 03, 2018 4:55 pm

Richard wrote in Fri Aug 03, 2018 12:43 am:Personally I'd recommend setting up a bunch of properties, e.g. /flash/light[0..3]/intensity and then use the following code to alias these global properties to ai model properties, and wrap around when the limit is reached.

thanks, Richard... i'll have a play with this...
"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: 9123
Joined: Fri Feb 20, 2015 4:46 pm
Location: central NC, USA
Callsign: wk42
Version: git next
OS: Kubuntu 20.04

Re: ALS aircraft lights

Postby wkitty42 » Fri Aug 03, 2018 5:01 pm

Thorsten wrote in Fri Aug 03, 2018 7:20 am:
@Thorsten: in the case of AI Traffic lights, which is better?

1. use an effect to blink the lights with a nasal blinking loop
2. use an animation select to blink the lights with a nasal blinking loop
3. use an animation select to blink the lights with some sort of xml to determine the blink pattern


Hm... the select anmination generally might give you a marginal performance since the lights not visible are removed from the scenegraph - but then again, it might not because they have to be re-added.

that's what i was thinking...

Thorsten wrote in Fri Aug 03, 2018 7:20 am:It's not as realistic though, real incandescent lights don't 'just' extinguish when switched off, they have a decay pattern for the intensity which is imo quite notable with strobes - a select animation doesn't do that.

yeah, i guess it also depends on how close you are to the light... when you're 400 feet up in the tower looking at the craft on the tarmac, it isn't quite so noticible...

Thorsten wrote in Fri Aug 03, 2018 7:20 am:Generally I'd slightly prefer property rules over Nasal to drive the flash sequences, because you need (especially when modeling decay) per frame computations but the actual complexity of what you compute is small - so that's the sweet spot of property rules.

everything i've seen since finding FG has pointed to using property rules instead of nasal... now i've gotta go back and look at some of this again after having burned out my brain trying to figure out nasal and failing miserably until one small hint blew open the doors...

Thorsten wrote in Fri Aug 03, 2018 7:20 am:But I suspect that in practice the performance difference between Nasal and property rules for driving a dozen properties might not be measurable.

it is kinda starting to look like the refinements over time have helped to speed things up in several areas making the distinction not as noticeable as it once was...
"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: 9123
Joined: Fri Feb 20, 2015 4:46 pm
Location: central NC, USA
Callsign: wk42
Version: git next
OS: Kubuntu 20.04

PreviousNext

Return to Effects and shaders

Who is online

Users browsing this forum: No registered users and 3 guests