statto wrote:Might it not be better to include these as shared models, automatically placed by TerraGear where the standard taxiway lights should be?
That would be nice thing.
I already use the airport lights more ore less as shared models and use the information from the btg file to create the light positions.
curt wrote:For standard airports, all the lighting points locations and types (and orientation) are computed by terragear and then encoded in a simple format. This is read in by the "btg" loader and then lights are created dynamically on the fly by FlightGear. The light creation scheme could be replaced with something that creates much more realistic lights along with the posts and all the other bits. But light position, type, and orientation is available for all airport lights ...
I sort of tried to simulate that part with the scrip…
This way I just could start to could develop the models needed and start field testing the impact of all that models before going ahead with the project. (before bugging the developer guys, since I got only rudimentary c skills).
As far as I understand, the lights are stored in the btg as point light objects, as for example 1527 light points for LOWI generating the directed lights. I just process this data, to only place the light models needed based on a set of rules, that figures what goes where and ignores the duplicates, since I place for example only one model for a runway centre light that has a directed red and white light (I figured that with less models the fps impact could be reduced).
But I hope that a part of my work could help developing a better native airport light system for fgfs. I am open for any suggestions.
Tuxklok wrote:I think the problem is the way taxiway lights are defined with taxidraw. The overlapping rectangles, except in straight sections, leave many many redundant and inaccurate light placements on taxiways. This is why most of our airports, especially more detailed layouts, look as much like Christmas trees as they do airports. If you just placed lights at every one of those automatically it would be quite nasty I think. I imagine Oliver had to do quite a bit of manual cleanup, removal, and repositioning to get the taxiway lights positioned and spaced properly...will have to let him chime in on that though. I also worry about the wisdom of placing hundreds (even thousands) of singular model objects around every airport by default.
That is exactly the problem with using the lights that are currently created by taxidraw / terragear is that you get a lot of unwanted and wrong positioned lights (taxiway lights in the middle of the runway). The cleanup is done by hand and I had to remove half of the generated taxiway lights but only hand place about 15 of them. The runway turns out ok, but I only use a small part of the actual points based on the rules to generate the lights.
I guess this could be just be helped by redesigning the way taxidraw / terragear is generating those. There would be the need for a way to place lights one by one or as lines in taxidraw or delete the unwanted lights. And it would still be nice thing for the scenery developer to use custom models at dedicated places by choice. In the long run a update to the new btg format?
Ernest1984 wrote:I found a bug, when i want to start from LOWI now, it can't load up the scenery... I have this "plane splashscreen" with the "loading" texts, it stops at "loading scenery objects" text at the bottom, and nothing happens.. When i close the fgfs i can see for couple seconds on the mpmap, that i was positioned somewhere on the Atlantic Ocean, near Africa continent, AND i have some different nickname.
If you use the custom btg I provided try to start by choosing runway 26.
Oliver
FlightGear Forum
I know you put a lot of effort into it. That's a job well done! 
