> It sounds VERY interesting, the sample images and video look extremely
> impressive. If it does get released under the GPL, and can be integrated
> then I think it'd be a crime not to try.
> What sort of tools are available for producing the scenery?
Well, I have written a few perl scripts and C tools to download and reproject
SRTM3 and landsat data for a given utm zone (thanks, GDAL!). The landsat
images are then automatically color corrected, reprojected and mosaiced
using a set of custom C tools. Same goes for srtm3 (without the
color correction, obviously :-) ). The generated heightfield and texture are
then preprocessed into a quadtree data structure using
simplification&compression-tools (part of the terrain rendering engine).
The whole process is automated (mostly perl driven), but can be improved upon
in a few points (especially color correction). Maybe noteworthy to add that
the processing for a UTM zone may take a few hours, depending on available
band-width and processing power.
> How difficult is it to include other 3d models in the rendering? (Things
> like aircraft, ground features, etc)
Well, this is one of the integration problems which need to be solved. I think
the easiest thing would be to encapsulate the terrain rendering into its own
scenegraph node, and let flightgear handle the ground objects separately
(probably placing them using elevation queries or some such).
I am not sure IIRC, but I think the separation between terrain and ground
objects would require a bit of detangling on the sides of flightgear, as
currently runways and ground objects seem to be interwoven with the
tile/terrain management. I'd have to look into that, though - just my first
However, it is certainly also possible to incorporate ground object rendering
into the terrain engine itself (and such a feature is planned), but I guess
might make it harder to keep the terrain rendering subsystem interchangeable.
And I do think that it would be a good idea to couple the terrain subsystem
as loosely as possible to flightgear (e.g. to help keeping the old system
running). Maybe a few line-of-sight, intersection, elevation, and
ground type query routines might just do the job for such an API (besides the
scene graph node, of course)?
I hope someone with inside knowledge will comment (but I'll also read a
bit into the code, promised :-)).
I am not sure, but maybe we would also need special handling for runways,
to handle incosistencys between terrain and runway elevation, or irregular
terrain underneath the runway. Easiest way would probably be to modify the
input height field prior to mesh generation (while thinking hard how to avoid
z-buffer artefacts etc.)... How is this currently handled?
Anyway, I hope we'll be able to release the engine soon (but think weeks or
months, not days!), but I will try to get the flightgear integration work as
far as possible in the meantime...
And I certainly appreciate any insights into "flightgear terrain issues"
you might give :-)
Flightgear-devel mailing list