Re: [Flightgear-devel] osm2city.py

2013-05-13 Thread Thomas Albrecht
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

2013-05-13 Thread Gijs de Rooy
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

2013-05-13 Thread Renk Thorsten

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

2013-05-13 Thread Stuart Buchanan
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