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
world
> 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.
Curt.
--
Curtis Olson - University of Minnesota - FlightGear Project
http://baron.flightgear.org/~curt/ http://www.humanfirst.umn.edu/
http://www.flightgear.org
Unique text: 2f585eeea02e2c79d7b1d8c4963bae2d
-------------------------------------------------------------------------
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
