Re: [Flightgear-devel] Re: [Terragear-devel]
Martin Spott ha scritto: Roberto Inzerillo wrote: So I guess, using more photoreal scenery into FGFS would give a more realistic result with less human effort then using default terrain textures, vector roads/lakes/rivers/railroads... I believe the most promising effort of this sort is 'osgPlanet' where you apparently can plug almost every sort of geodata. I wonder why Norman Vine didn't tell us about it ;-) Cheers, Martin. That's awesome! I'll give a deep look inside today. Do you (Martin) really think osgPlanet has the right key (from a developers point of view) to let FGFS make a new step into photo-real scenery? I really hope so. I've been come to the conclusion that the current scenery contributers are a lot but have a lot of difficulties too in order to integrate their work into the current world representation. Many people in the world use to hack simulators in order to achieve more realistic environment (that's real fun :-) , that is de facto possible thanks to the nature of most of them, FGFS is also opensource and that's a big advantage. But the lack of simple (not just for highly skilled developers) tools is a big stop (FGSD is a rare and good example of user-tool but it's definetely not enough). I am sad because I see Jon Stockill's repository almost stopped getting new contributes. I guess it's because of some obstacles (not in John's repository itself) which common people don't like to cope with. Anyway, I'm positive with the idea that FGFS is, because of it's opensource nature, a step behind to other simulators and has great potentials which just need to come to reality. So you all developers deserv great respect and support by the user-land. so, have a nice day, let's see what happens with osgPlanet :-) Roberto ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Custom scenery integration (was: Re: [Flightgear-devel] Re: [Terragear-devel])
Hello, Martin Spott schrieb: [SNIP] Actually, I _do_ agree that having preprocessed scenery _is_ an advantage. But it does have disadvantages as well: 1.) At the current state it appears (to me) nearly impossible to inject user-contributed additions into the scenery, 2.) I don't manage to build the necessary tools on my server ;-)) Share your problems with us, perhaps we can help ;-) Maybe the way to go might be to make it easier for everyone to build the tools (and to simplify the process of scenery generation) and to add his personal scenery improvements using common open GIS file formats but keep the preprocessed scenery as we are already used to it. I'm currently working on some more detailed scenery data for the region around Lake of Constance, Southern Germany, and I still have to check on some legal issues, but I'd love to share my experience on that with you as soon as I get some more time (been quite busy in the last few months). I'm using GRASS (http://grass.itc.it) for digitising and the preliminary results are quite interesting regarding better orientation - at least for a local ;-) I had to write an additional tool to get linedata imported from GRASS to TerraGear, but actually with all the support libraries available this is far from complex :-) Most of the exporting and scenery generation tasks is automated using scripts and a single configuration file. When the legal issues are resolved, I might be able to share the digitised data with the community and perhaps we could start a discussion on how the integration of such data into the standard scenery data can be organised and automated - for Curt's convenience ;-) Oh, and not to forget: FlightGear is an astonishing piece of software! In the meantime it has totally replaced my commercial flight simulation software (don't make me say names ;-), making it possible for me to actually drop Windoze :-) Thank you to all who contributed! Regards, Ralf ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: Custom scenery integration (was: Re: [Flightgear-devel] Re:[Terragear-devel])
Ralf Gerlich writes: Hello, Martin Spott schrieb: [SNIP] Actually, I _do_ agree that having preprocessed scenery _is_ an advantage. But it does have disadvantages as well: 1.) At the current state it appears (to me) nearly impossible to inject user-contributed additions into the scenery, 2.) I don't manage to build the necessary tools on my server ;-)) Share your problems with us, perhaps we can help ;-) Maybe the way to go might be to make it easier for everyone to build the tools (and to simplify the process of scenery generation) and to add his personal scenery improvements using common open GIS file formats but keep the preprocessed scenery as we are already used to it. I'm currently working on some more detailed scenery data I'm using GRASS (http://grass.itc.it) for digitising and the preliminary results are quite interesting regarding better orientation - at least for a local ;-) I had to write an additional tool to get linedata imported from GRASS to TerraGear, but actually with all the support libraries available this is far from complex :-) Most of the exporting and scenery generation tasks is automated using scripts and a single configuration file. This sounds great, Grass is a powerful tool. IMO the most useful approach would be modifying TerraGear to use PostGIS instead of the File System. Then one could use tools like Grass and UDig directlly on the data stream. For that matter it would be interesting to investigate using PostGIS to store the FGFS Scenery directly. Hmm this is starting to sound a lot like something that osgPlanet could render too :-) Cheers Norman ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Re: Custom scenery integration
Martin Spott writes: By definition you can transform the current VMAP0 data, which comes in the so called VPF format, into shapefiles. In order to achieve this you need OGR and the OGDI VPF driver (Norman, please correct me if I'm wrong). The same set of tool scan be used to go directly to PostGIS without teh intermediary shapefile step. Once we have the landcover data in a PostGIS database we are enabled to manually adjust roads and rivers, add ponds like the one in front of the Oracle building and send everything to Curt for the scenery generation if someone adds a Shapefile or PostGIS driver to TerraGear which replaces the current VMAP0 importer. I'm currently uncertain if we really can store the _whole_ scenery in PostGIS. Our elevation data currently comes as raster data but maybe it makes sense to convert that into contour lines - which we finally can store in such a database as well. Does this make sense, Norman, or will this eliminate our ability to alter the data with 'common' tools ? Why not just store the Elevation data in a mixed record type of a Polygon with a BLOB field ? Cheers Norman ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Custom scenery integration
On Sun, 3 Jul 2005 21:51:24 + (UTC), Martin wrote in message [EMAIL PROTECTED]: Norman Vine wrote: Ralf Gerlich writes: Actually, I _do_ agree that having preprocessed scenery _is_ an advantage. But it does have disadvantages as well: 1.) At the current state it appears (to me) nearly impossible to inject user-contributed additions into the scenery, 2.) I don't manage to build the necessary tools on my server ;-)) Share your problems with us, perhaps we can help ;-) I simply chose the 'wrong' hardware: I'm running AIX on my RS6k server. A great machine to build FlightGear scenery (4 GByte RAM, 8 CPU's) but without a compiler that meets the requirements. ..stupid Q: Can this iron run User Mode Linux? Qemu? Bochs? ..emulator overhead, but allows running all the goodies. ;o) -- ..med vennlig hilsen = with Kind Regards from Arnt... ;o) ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Custom scenery integration
Norman Vine wrote: Martin Spott writes: I'm currently uncertain if we really can store the _whole_ scenery in PostGIS. Our elevation data currently comes as raster data but maybe it makes sense to convert that into contour lines - which we finally can store in such a database as well. Does this make sense, Norman, or will this eliminate our ability to alter the data with 'common' tools ? Why not just store the Elevation data in a mixed record type of a Polygon with a BLOB field ? Well, this approach certainly enables us to store and retrieve elevation data, but to my knowledge neither of both methods is suited to alter the data using the preferred tools like GRASS for example. We probably would need to build our own storage method for GRASS !? Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Custom scenery integration
Arnt Karlsen wrote: On Sun, 3 Jul 2005 21:51:24 + (UTC), Martin wrote in message I simply chose the 'wrong' hardware: I'm running AIX on my RS6k server. A great machine to build FlightGear scenery (4 GByte RAM, 8 CPU's) but without a compiler that meets the requirements. ..stupid Q: Can this iron run User Mode Linux? Qemu? Bochs? It probably would be _much_ easier to build the desired geo-tools on that machine than building an emulator :-) Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
