Thanks!
Good catch!
did this new lighting technique ever get commited
If so, I'll be able to create them by observing the SpaceShuttle...
I never noticed the nav lights shining on the ground,
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 think there is a .eff file to configure, but I can not find documentation.
<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
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?
Thorsten wrote in Mon Jul 30, 2018 6: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).
Thorsten wrote in Mon Jul 30, 2018 6: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.
Thorsten wrote in Mon Jul 30, 2018 6: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.
Thorsten wrote in Mon Jul 30, 2018 6: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.
Thorsten wrote in Mon Jul 30, 2018 6:36 pm:You're probably not doing yourself a favour by creating hundreds of different effects either...
doesn't that put us back in nasal territory? territory that we're trying to get away from.
uhhhh... i thought this was being driven in C code and then fed to GLSL...
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...
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...
Thorsten wrote in Tue Jul 31, 2018 6: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).
Thorsten wrote in Tue Jul 31, 2018 6: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.
Thorsten wrote in Tue Jul 31, 2018 6: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.
Thorsten wrote in Tue Jul 31, 2018 6: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.
Thorsten wrote in Tue Jul 31, 2018 6: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.
Thorsten wrote in Tue Jul 31, 2018 6: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
if it is actually a texture, that would be nice to know so maybe it could be used with this other stuff...
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 thought i had a way of assigning the strobes to a group, the beacons to another group and the navlights to a 3rd
i'm not sure what you mean by "switching them from one effect to another"... we're not changing the effect...
Users browsing this forum: No registered users and 6 guests