Re: [Flightgear-devel] osm2city.py
James, > Could the floor-plan data be pulled live from OSM servers, or does it need to > be processed offline before hand? We have most of the infrastructure to pull > data from web-services already in place. Currently data is processed offline before hand. Basically, it parses the OSM xml, generates a list of building outlines, discards some based on their area, simplifies the outlines, clusters them into ~500x500m blocks and different LODs, then writes .ac, .xml, and .stgs. OSM parsing is by far the most expensive, easily taking 10 minutes for 50k buildings. Once that's done, the remaining parts take maybe 1 minute in total. In C++, this would be faster, of course. Are you thinking of a terrasync-like thing here, where users get OSM buildings (where available) on-the-fly? In addition to what Stuart said, this might be quite expensive in terms of bandwidth. The OSM download (buildings only!) was ~40MB for the 25x25km LOWI area. Curt, > Would this data set include airport hangar buildings as well? At the moment, the code knows only the floor plans. No streets, no runways, no land-use. But it'll certainly process such data in the future, and then could use some heuristics (some OSM buildings are labeled "Terminal 1" or so) to apply terminal/hangar textures to buildings at airports. Hadn't thought of this before, but yes, this way we could rather easily populate some airports with 'semi-generic' terminal/hangar buildings. Stuart, Thanks for pointing me at fgelev. I'll give it a try. If I had a limited number of "complex" (as in > 8 vertices per model) shared models, and place a total of 5 instances in a scene, could this be made to occupy significantly less RAM than 5 individual models? Gijs, Thanks for your comments! I'm aware that OSM building coverage is basically non-existant in large parts of the world. Street coverage is much better, that's why I also aim at procedurally generating cities just from a street network. Meanwhile, a forum user (vanosten, http://flightgear.org/forums/viewtopic.php?f=5&t=17598) who's interested in exactly that offered to join forces. Since I've already invested ~3 months here and remarkably didn't get bored (in fact, quite on the contrary), I'm confident we'll get there eventually ;) I know of bob.pl, but I just cant read perl... > When there are buildings, you'll often find that they are drawn as big blocks, > rather than individual houses. True, unfortunately. Plus, _if_ there are many tiny individual houses, they'll kill framerate (backed by some experience with LOWI now). Appropriate textures might help here. > Before I could create some sensible buildings for New York I had to add height > tags; all skyscrapers were simply lacking that data. Why not simply assume a sensible distribution of buildings heights in this case? I've played with that some days ago, and found it looks quite reasonable: http://ubuntuone.com/0X0KcYJbRgUtIldtasWyMo http://ubuntuone.com/1LaEKT6pOtf6zxXItpKmPA http://ubuntuone.com/0jsCECjmKMaooP4wrHHwH7 Thomas -- AlienVault Unified Security Management (USM) platform delivers complete security visibility with the essential security capabilities. Easily and efficiently configure, manage, and operate all of your security controls from a single console and one unified framework. Download a free trial. http://p.sf.net/sfu/alienvault_d2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] osm2city.py
Hi all, altough it looks nice around LOWI, it is not the magic solution to all problems in life. It won't (yet) work very well or not at all for large parts of the world. It's certainly promising and a nice addition to our current auto generated buildings, but no replacement yet. - When there are buildings, you'll often find that they are drawn as big blocks, rather than individual houses. You'd get big industrial buildings, where you'd expect small terrace houses etc. You can nicely see that when comparing the houses that I've added to the surrounding blocks: http://osm.org/go/0EtXwp8eH-- (for NL and some other countries this individual building data is freely available, but for lots of others it isn't) - Even "top" locations like Manhattan, Tokyo and Sydney have very little buildings in OSM. - Before I could create some sensible buildings for New York I had to add height tags; all skyscrapers were simply lacking that data. - Also see http://wiki.flightgear.org/OpenStreetMap_buildings#Challenges A related project is to map points of interest from OSM to our model, which is documented at http://wiki.flightgear.org/OpenStreetMap_import Again, that's an addition to the existing data, not a replacement. Just in case my email reads as a complaint: it isn't. Having OSM building shapes in FlightGear would be awesome (I've spent quite some time on Bob myself), but we have to be realistic and name it's shortcomings. And realise that we should not throw away existing stuff untill we have a global solution. Cheers,Gijs -- 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
[Flightgear-devel] Air-air refueling
I finally got around to fly a few air-air refueling exercises with the revised system with configurable refueling envelope. I have tested the F-16 using a 3 m envelope and the F-14b using a 10 m envelope (I figured the hose allows a bit more flexibility than the boom - I'm not completely sure about the reality of AAR...). >From what I can see, this is now very well done. With a tolerance of 3 m, one >actually has to work for fuel rather than getting the tank filled while >approaching the tanker - still this is doable. Trying to get the F-14b into >the right position is a bit more challenging (it has larger lag between change >in throttle and change in airspeed), but still doable. I started receiving >fuel just in the position where I would have expected that. So - big thanks to Stuart - this is now much better than it used to be. * Thorsten -- 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
Re: [Flightgear-devel] osm2city.py
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
