On 1/2/07, Roberto Inzerillo wrote:
> I hope you all had a nice new year start.
> Ok, now back to FGFS.
> > I don't know if I was successful, but when discussing the upcoming
> > apt.datformat to include a much more flexible taxiway spec, I also
> > lobbied to have
> > an airport boundary also included. If this boundary was fixed and never
> > changed, then a user could change anything inside that boundary (leaving
> > the
> > actual boundary points intact) and their airport would always mesh in
> > perfectly with the surrounding terrain, even if we autogenerated the
> > again.
> I have to say I don't think having fixed airport boundaries is _the_
> definitive solution to the problem. Things change in time, airport areas
> grow up and the cities in the world are expanding. There will be changes
> in terrain geometry every once in a while. Those boundaries will have to
> change too. Anyway, I don't like to discuss about this point, I will
> adapt my work to whatever decision will be made in this regard.
> > So back to your point, there's no reason you couldn't convert an airport
> > model to a more convenient 3d model format and then edit it in what ever
> > tool you want ... ac3d, multigen creator, blender, etc.
> 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.
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.
Just to be clear, I can make use of whatever common 3d file format but
> the .btg file is pretty useless right now. And then I need to convert
> the manipulated 3d file back to .btg; that's "misterious" to me too; do
> you think we can arrange a way to let Terragear accept some kind of
> generic 3d file input, .obj .ac or whatever, complete with textures?
> I will have to struggle with those two basic tasks before going deep
> into other details. Once I got that cleared out I can investigate more
> on lighting, ground markings etc...
> The boundary stuff should not be that big of a problem if I can operate
> with a generic 3d mesh both in the airport modelling phase and in the
> Terragear including phase. I guess it's fairly easy to determine those
> boundary edges in the airport 3d mesh, and later on define them as being
> the boundary of the hole to be created into the world terrain mesh when
> it comes to import the airport into terragear. That's my idea, tell me
> if you see more obstacles to such an apporach.
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.
Regarding textures and lighting I would use the standard fgfs textures
> for taxiway/runway/aprons as a starting point, and I guess I'll stay
> with that untill I really need new ones.
> 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.
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.
Curtis Olson - University of Minnesota - FlightGear Project
Unique text: 2f585eeea02e2c79d7b1d8c4963bae2d