Hi, > 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 impression... 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 :-) cheers, Manuel _______________________________________________ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
