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?
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."