Hi Tom, On Sun, May 12, 2013 at 9:35 PM, Thomas Albrecht wrote: > Dear list, > in particular Stuart, > > please let me 'officially' announce my project osm2city.py [1,2] here. This > python script takes OSM floor plans and generates 3D buildings for use with > flightgear. I'm planning to develop this into a procedural city generator > which would take a street network and then reasonably places (random) > buildings. The ultimate goal is (obviously) to improve FG's representation of > cities. > > It's at a rather early stage, and for the moment I prefer python for quick > prototyping. BUT, I know quite some C/C++, and compile from latest GIT > sources regularly. In the future, I'm definately willing to move this into > FG (in one form or another). > > Tom > > [1] http://wiki.flightgear.org/Osm2city.py > [2] http://flightgear.org/forums/viewtopic.php?f=5&t=19625
To echo what others have said - this looks fantastic, and a major step forward from the autogen buildings that we have at present. I look forward to it making my work redundant! Based on my experience with the random buildings I think that pre-generating the buildings as you are doing at present is a better approach than trying to do things at runtime. There simply isn't enough information available in the tile loader to run a complex algorithm at run-time, and even if we could, my experience has been that the perf impact is too great. For example, we generate random buildings on a per-triangle basis (which allows us to determine the position on a plane and avoid an expensive height query). They cannot overlap the edges of the current triangle, as we can't tell what the terrain is on the other side of the triangle edge. This means you can see odd "streets" leading to vertices in the terrain mesh. Very distracting when you start spotting them... As you mention on the wiki page, memory occupancy is a big issue. The original implementation of random buildings used OSG primitives to generate a geometry for an entire tile at once. IIRC that was around 10GB for the LA area, and I'd expect the more complex buildings you're generating to need significantly more. As the random buildings are pretty simple I was later able to shoehorn them into a shader approach and improve memory occupancy significantly, but I don't think that'll work with the complexity of buildings you have. Since then Matthias modified the tile loader with an LoD callback, so that model aren't all loaded at the same time as the tile - only when you get close to them. That should help a bit, and might make the memory cost palatable for large cities. I think it would be worth having a discussion with the scenery DB owners about this as part of the scenery DB, automatically generating buildings as OSM data improves and/or the scenery shapefiles are changed. -Stuart PS: There's a util in FG (fgelev IIRC) that provides a much easier way to probe terrain elevation than running a Nasal script in FG. ------------------------------------------------------------------------------ Learn Graph Databases - Download FREE O'Reilly Book "Graph Databases" is the definitive new guide to graph databases and their applications. This 200-page book is written by three acclaimed leaders in the field. The early access version is available now. Download your free book today! http://p.sf.net/sfu/neotech_d2d_may _______________________________________________ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
