20,741
edits
Using OSM Vector Data in FlightGear: Difference between revisions
Jump to navigation
Jump to search
m
Using OSM Vector Data in FlightGear (view source)
Revision as of 20:45, 30 January 2014
, 30 January 2014→Procedural Buildings & Cities (radi & vanosten): http://forum.flightgear.org/viewtopic.php?p=192380#p192380
m (→Procedural Buildings & Cities (radi & vanosten): http://forum.flightgear.org/viewtopic.php?p=192380#p192380) |
|||
| Line 136: | Line 136: | ||
Also see [[Osm2city.py]] | Also see [[Osm2city.py]] | ||
Radi | '''Zakalawe:'''A thought occurs - this is much more blue-sky, could we run a C++ version of the script in real-time? As an alternative / replacement for random-buildings. This relies on two assumptions: that the input data per tile is sensible sized (tens of kbytes, or worst case a hundred for centre of really built up city), and that the script could run in 'almost real time' on the OSG Pager thread. | ||
So we'd add the outline data as an additional file in each Objects/foo/foo/dir, and if this mode is enabled, look for the file and run the buildings creation script at that time. | |||
'''Radi:''' focused on OSM buildings/bridges in the past, but is now interested in procedural city generation in general. OSM xml data for LOWI region alone is 50 MB. Might be a bit heavy a download for some users. Radi discussed this with James at FSweekend last year: we could pre-process OSM data, extract what's useful for us, and ship the outcome with our scenery. OSM buildings for LOWI would then add perhaps 1MB or so. OTOH, if this is generated at run-time (and then cached), users could decide themselves if/what OSM features they wish/can afford. | |||
'''vanosten:''' I understand there are advantages to do stuff on the fly - it might be even faster to do calculations than reading detailed info like ac-files from the file system. However I wonder whether it really is the same thing that people try to accomplish. Together with Radi I want with osm2city make a plausible world, which satisfies also someone on sightseeing with a helicopter, who knows the area. The other is generating a plausible world. The first one needs a lot of parametrization and logic on a per object level. If the first one can be satisfied with on-the-fly processing, then I would look into porting code to C++ and learning C++. If not, then potentially we should leave the initiatives apart? | '''vanosten:''' I understand there are advantages to do stuff on the fly - it might be even faster to do calculations than reading detailed info like ac-files from the file system. However I wonder whether it really is the same thing that people try to accomplish. Together with Radi I want with osm2city make a plausible world, which satisfies also someone on sightseeing with a helicopter, who knows the area. The other is generating a plausible world. The first one needs a lot of parametrization and logic on a per object level. If the first one can be satisfied with on-the-fly processing, then I would look into porting code to C++ and learning C++. If not, then potentially we should leave the initiatives apart? | ||