>> That's where I'm stuck. I don't know how to deal with that conversion. I
>> already asked in ML about the conversion but got no practical answer. Do
>> you have one?
>
> I don't have time to sink my teeth into this right now, but perhaps the
> easiest thing would be to rig flightgear to write the airport chunk of the
> scene graph back out to .ac3d format right after it loads it.
Thanks for the idea Curtis, but sorry that's Voodoo to me. I don't think
I know where to start from. Let FGFS write the airport chunk? How? I've
no idea.
> However, the runway and approach lighting is somewhat of a special case so
> that doesn't have a direct analogy in ac3d or any other modeller. There is
> a specialized data chunk in the .btg format and specialed flightgear
> code to load and handle lights.
Maybe there's no 3d analogy in ac3d but almost any 3d package is able to
use 3d placeholders which can be named and categorized in order to use
them for ligth positioning. It's just a matter of converting those 3d
placeholders to a convenient data chunk into the .btg file when the
scenery is complete.
> Perhaps in a future version it would make sense to write the airport
> geometry out in a separate file from the airport lighting. That way they
> could be manipulated independently ... but certain changes to the airport
> geometry would require lighting changes so that's a tough problem.
Again, I don't care about the future right now. I'd like to create a
nice 3d airport geometry right now. If that can be used as a proof of
concept for future large scale development, I'll be happy. If not, I'm
happy to have a high res/quality airport anyway, even if that's useless
for future scenery enhancement.
>> The same goes for lighting, I just want to change the positioning of
>> those light points in space because I don't like the way they are
>> automatically positioned now (specifically on taxiways).
>
> But if you change the elevations of any of the airport surface mesh, the
> lighting elevations will also need to change.
Agreed, no problem. Ligthing has to be placed after the surface is done
anyway. There's no reason to place it before. There's always room for
automatic height corrections inside the 3d modeller if needed, a bunch
of scripts could be the solution.
>> Anyway, the starting point is the 3d mesh file conversion. Without this
>> step I wont go far. Should I really write down a conversion script by
>> myself (that will take time and there's no way to tell if I'll be
>> successful :-) ?
>> Did anyone already experimented with that?
>
>
> As a first stab, I'd suggest finding the place in the scenery loader that
> loads the airport model and add a file save after the load is complete.
> Also, if you set the position correctly, you can load a .ac3d version of an
> airport instead of a .btg format ... that shouldn't be an issue.
What does that mean? Digging into the code?
I have to be clear about that. I don't say I will never read FGFS code,
that's not the point, but I don't think that's very easy to someone like
me who doesn't know the code already. Is it really so wrong to try and
get the 3d data out of the .btg file? With all due respect, is the .btg
file so useless regarding this aspect?
Roberto
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
