Board index FlightGear Development Scenery

LOWI city buildings

Questions and discussion about enhancing and populating the FlightGear world.

Re: LOWI city buildings

Postby Hooray » Sun Apr 07, 2013 4:17 pm

radi wrote in Sun Apr 07, 2013 3:06 pm:The idea is: where OSM floorplans are available, use them. That includes quite a number of German cities, and some other European cities, as well. Where floorplans are missing, have an algorithm come up with something plausible. Plus, where OSM indicates, e.g., a gas station, insert a shared model. I thought I'd do this offline first, i.e. outside FG. Eventually I might want to do this in FG on the fly.


That does sound really promising, if you haven't already, you may want to read up on past discussions related to this, and get in touch with the corresponding people (such as Stuart) to further coordinate/streamline all related efforts here. For example, see these threads:

Subject: How to create better roads, highways, railroads?

martin wrote:
miho wrote:is there a tutorial on how to use the OSM data for creating such scenery? Just to practise and be ready to go once the OSM guys have chenged their license...


Basically it's just replacing the respective VMap0 line data with OSM and probably choosing a different width for motorways/freeways, since OSM has one track for every direction.

Note also that OSM roads is not the cure for all our road data issues since OSM, even though they're having more detail than VMap0, their coverage is smaller (as recently mentioned on this forum), and therefore needs some helping hands in order to make a drop-in replacement for our VMap0 road coverage,

Martin.



Subject: Procedural buildings in OSM before part of Scenery

vanosten wrote:So the idea would be to procedurally generate buildings based on OSM data (not uploading to OSM!) based on other OSM data like streets, area classifications, ... I thought of enriching offline OSM data with buildings - which could then in a later step be used to actually generate buildings in Flightgear (or X-Plane with http://osm2xp.com/). Due to differences in landuse patters between e.g. cnetral Europe and USA the algorithm would naturally have to be configurable - however somewhere we need to start.


Subject: Procedural buildings in OSM before part of Scenery

stuart wrote:This is a really interesting idea. A couple of thoughts based on my experience writing the current random buildings code and general FG experience:

1) I think the right place for this information is in the scenery models database, or probably some similar off-shoot of that DB. We already have the OSM data in a PostGIS DB there, so you could retrieve data from that, do some complex off-line processing and then write the resulting data into our global database. In the end I created a small number of buildings and then use specialist GPU shader code to instantiate them multiple times. That will be much trickier for you to do, and will probably require some specific C++ code in FG to handle your buildings as a special case.

I'd be very happy for my random buildings to be supersede by proper procedural buildings, and would be happy to discuss the technicalities further.



Bottom line being, we have/had several related (or even competing) approaches here, and like Thorsten suggested earlier, it would make sense, to combine certain techniques to come up with a single unified method.

It would definitely seem like a good idea to get feedback from Stuart, psadro_gm and papillon81 - because they are heavily involved in the random buildings/TerraGear department, and they should be able to directly tell you, how to proceed from here - so that your work aligns well with related ongoing efforts.

Also, you may want to use the wiki to document your project, and maybe use it as a place for brainstormings related to combining the various techniques. BTW: You may also want to add an announcement about your project to the upcoming newsletter (see my signature).
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 11376
Joined: Tue Mar 25, 2008 8:40 am

Re: LOWI city buildings

Postby Gijs » Thu Apr 11, 2013 1:52 pm

radi wrote in Sun Apr 07, 2013 3:06 pm:where OSM indicates, e.g., a gas station, insert a shared model.

We've the intention to run a global automated process for this on the scenery database. Also see http://wiki.flightgear.org/OpenStreetMap_import
Airports: EHAM, EHLE, KSFO
Aircraft: 747-400
User avatar
Gijs
Moderator
 
Posts: 9384
Joined: Tue Jul 03, 2007 2:55 pm
Location: Amsterdam/Delft, the Netherlands
Callsign: PH-GYS
Version: Git
OS: Windows 10

Re: LOWI city buildings

Postby radi » Thu Apr 11, 2013 8:55 pm

Hooray, Gijs,

thanks for the heads-up. I've added a little announcement to the newsletter.
OSM buildings for LOWI, EDDC
Custom scenery for VHXX YMML
Edit .stg via the FG Object Placement Tool
radi
 
Posts: 643
Joined: Mon Aug 25, 2008 4:24 pm
Location: YMML, EDDC

Re: LOWI city buildings

Postby Hooray » Fri Apr 12, 2013 5:27 am

thanks for doing that, looks pretty good to me as a first prototype ! Just a few comments:

you wrote:probe elevation for this area:
make elev.in
run FG: nasal console: elev.get() -> execute. Might take a long time, depending on the area scanned.
produces elev.xml (which is actually just plain 5 column data: lon,lat,x,y,elevation)


To get rid of the manual steps involved here, you could probably do that automatically via FG's telnet/props mechanism: http://wiki.flightgear.org/Telnet_usage
You can invoke arbitrary Nasal code through listeners, but you can also use Torsten's property-based terrain sampler (unfortunately not at all documented currently AFAIU) which should be a little faster than the pure Nasal route:

http://www.mail-archive.com/flightgear- ... 35525.html
Torsten wrote:The property /environment/terrain/area[0]/enables is set to a boolean
value of false on startup. This ensures the sampler is instantiated but
not running. You should set it to true when you enable local weather and
reset it to false when you disable local weather. Also, make sure to set
/environment/terrain/area[0]/input/use-aircraft-position to true if want
to sample the area around the aircraft's position.
So, No: the --prop switch will no longer be needed at startup, the
sampler is there but disabled, you can assume the system will be available.


Thorsten can probably provide additional pointers because he's using that system in his advanced weather, and because he was involved in its design.

Basically, you could link your python scripts to a running fgfs session and dynamically sample terrain as required, without requiring manual intervention.
For python/telnet examples, see: http://wiki.flightgear.org/Telnet_usage ... r_programs
And in particular: https://gitorious.org/fg/flightgear/tre ... pts/python

Overall, I would still emphasize that you should get in touch with Stuart, psadro_gm and papillon81 to see if/how your system could be integrated into the existing random buildings/scenery subsystem - even if that just means that they provide the required building blocks and hooks to allow external programs to do these things.

For example, based on Stuart's random buildings system, Torsten's terrain sampler subsystem, some OSM processing code and some property/Nasal hooks, it should be possible to provide a high level API to implement arbitrary "city generator" algorithms. For core developers that would mean that they could focus on just the APIs, whereas base package developers could contribute the algorithms to place buildings/cities procedurally.

Previously, a bunch of people suggested that such an interface would probably have "academic use" only:

Subject: Random Buildings
stuart wrote:
Thorsten wrote:it would be somewhat far-fetched to ask Stuart to make a faster Nasal interface than the existing one just because someone might eventually work on it.
Yes, it would be possible but it probably represents 10 hours of speculative development that I don't have time for right now. Given that people don't seem to making significant use of the tools already available by modifying materials.xml (at least not in a way that is making itself as far as git), I just don't see sufficient interest. That may change once these changes are available, as it'll give people a lot more scope for creating cities.


Meanwhile, we do have a bunch of related, or even overlapping, efforts here - for example, the guys from the scenery department recently talked about runtime generation of airports, too:

Subject: Scenery Draping

psadro_gm wrote:
zakalawe wrote:Pete, I don't know what you've discussed with Chris, but you should stop at exactly this point :)

The reason is, we already have all the data to generate the ground polygons, inside FlightGear - that's exactly how the airfield chart / ground-radar work. And we can do it adaptively (more bezier interpolation on faster machines) and also get airports editable in mostly-realtime (unless the airport boundary changes).

The trick is to make an OSG 'loader' which creates the airport geometry from the apt.dat definitions, which of course is exactly what genapts does - this is why I was working with Chris to make it fast enough to run inside the loader thread, in FG.

I'd love to fully generate the apts at runtime. LEMD is probably the most complex layout, and genapt currently takes about 2.5 seconds to generate. I imagine it could be generated in 2 stages for LOD. 1 for runways and taxiways, which are really quick, the 2nd stage for the line data which is slower.

Pete


So this is one of those recurring cases, where we have people working on heavily related efforts, moving into different directions (note that I didn't even yet mention Mathias and his HLA work...)

Thus, it would probably be a good idea to log a "meta issue" via the issue tracker to track all similar/related efforts, given the number of competing approaches -and interested contributors- here (Static Objects, Urban Shader, InstantCity, PixelCity, Random Buildings etc).

It's worth noting that the current fgcommand-based approach does not invoke the Nasal GC obviously, but that it causes a fair amount of property tree marshalling, especially keeping in mind the temporary nature of the data structures here.

With TheTom's recent work on the cppbind framework, exposing C++ classes to Nasal (and vice versa) has become pretty straightforward, and yes, I would volunteer to help with any efforts related to streamlining the current situation a little more.

Now, if you are able to build FG from source and know a bit about C++ and OSG, we can probably provide a bunch of pointers to move more functionality over to C++ space, i.e. using a dedicated subsystem: http://wiki.flightgear.org/Howto:Create_new_subsystems

Papillon81 and psadro_gm should be able to tell you if and how certain components could be safely run asynchronously in a worker thread, to reduce the main loop impact.

Finally, even if you are sure that you don't want to touch any C++ code, we do have people working on HLA support, including the goal to support FG extensions implemented in Python via pyHLA: http://www.mail-archive.com/search?q=HL ... eforge.net

For additional info on enabling HLA/RTI support, see: http://wiki.flightgear.org/FlightGear_H ... chitecture)

In summary, you'll probably want to coordinate things a little, with a bunch of people:
  • Stuart (efficient random buildings)
  • Papillon81 & Psadro_gm (TerraGear/Scenery guys)
  • Mathias (standalone HLA components, possibly implemented in Python)
  • Hooray (or directly TheTom) for help with using the cppbind framework
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 11376
Joined: Tue Mar 25, 2008 8:40 am

Re: LOWI city buildings

Postby radi » Wed May 01, 2013 1:14 pm

Image
LOWI city buildings now with lightmap. Download first post.

Textures come in four sizes: tiny/small/medium/high, corresponding to
128/256/512/1024 px. Default is 'medium'. For any sane flying altitude,
even 'small' is probably enough. If you want to _drive_ through the
streets (or if you've got plenty of video RAM anyway), try 'high'.
With low texture sizes, I see no framerate gain, but the loading time
improves.

The texture set residing in tex/ is used. To use a different set, copy
the respective files from, say tex/tex.high to tex/.

Night lighting currently requires ot666's LOWI models to be present (which is a good idea anyway).
OSM buildings for LOWI, EDDC
Custom scenery for VHXX YMML
Edit .stg via the FG Object Placement Tool
radi
 
Posts: 643
Joined: Mon Aug 25, 2008 4:24 pm
Location: YMML, EDDC

Re: LOWI city buildings

Postby radi » Wed May 01, 2013 1:25 pm

Hooray,

Thanks for the exhaustive input!

I know quite some C/C++, and compile from latest GIT sources quite regularly. In the future, I'm definately willing to move this into FG (in one form or another). For the time being, however, I'm having great fun toying with python. I just love how quick you get stuff done with python, and there's still some things I'd like to try. Once things converge, I'll think about moving stuff to C++.
OSM buildings for LOWI, EDDC
Custom scenery for VHXX YMML
Edit .stg via the FG Object Placement Tool
radi
 
Posts: 643
Joined: Mon Aug 25, 2008 4:24 pm
Location: YMML, EDDC

Re: LOWI city buildings

Postby LesterBoffo » Wed May 01, 2013 2:12 pm

If I can make a comment as an outside observer.

Though the effect is really, really, impressive, I'm getting the Gestalt of the scene as being more of a Central/Southern California urban spawl scene. The buildings all have too much in the way of flat roofs, and as an example, especially in older/Northern and higher altitude European cities, there would be a fair mix of older pre 20ieth and 21st century buildings with gables, crenulated, steep pitched roofs and chimneys. I was struck by how the buildings in Hawaii had more pitched roofs than you find in more older European urban scenes.
User avatar
LesterBoffo
 
Posts: 2123
Joined: Sun Oct 02, 2011 4:02 pm
Location: Oregon, USA
Callsign: LesBof
Version: 2018.3.2
OS: Win10 Pro

Re: LOWI city buildings

Postby radi » Wed May 01, 2013 2:26 pm

Thanks LesterBoffo. ATM, only simple, four-sided buildings get pitched roofs. For more complicated buildings, generating a pitched roof is no longer exactly trivial. But guess what's next on my todo list (hint, hint).
OSM buildings for LOWI, EDDC
Custom scenery for VHXX YMML
Edit .stg via the FG Object Placement Tool
radi
 
Posts: 643
Joined: Mon Aug 25, 2008 4:24 pm
Location: YMML, EDDC

Re: LOWI city buildings

Postby LesterBoffo » Wed May 01, 2013 2:39 pm

Ah very clever. Although the 3D file terms used in the Wiki are completely Etruscan to my experience, I 'get' how this would generate simple but realistic rooflines. As some of these older inner-city areas all seem to have a jumble of joined roofs running parallel to the streets they face, maybe using the roads and backstreets to define their placement by inverting their direction away from the road open space?
User avatar
LesterBoffo
 
Posts: 2123
Joined: Sun Oct 02, 2011 4:02 pm
Location: Oregon, USA
Callsign: LesBof
Version: 2018.3.2
OS: Win10 Pro

Re: LOWI city buildings

Postby radi » Wed May 01, 2013 2:52 pm

ATM, the code knows nothing about adjacent roads (or even adjacent buildings, for that matter). All it knows is one building's floor plan. In the long run, I could try to merge adjacent buidings, and possibly also simplify buildings (i.e. get rid of small features). With the straight skeleton algorithm, roofs should then come out nicely.
OSM buildings for LOWI, EDDC
Custom scenery for VHXX YMML
Edit .stg via the FG Object Placement Tool
radi
 
Posts: 643
Joined: Mon Aug 25, 2008 4:24 pm
Location: YMML, EDDC

Re: LOWI city buildings

Postby Hooray » Wed May 01, 2013 3:32 pm

For the time being, however, I'm having great fun toying with python. I just love how quick you get stuff done with python, and there's still some things I'd like to try.

fair enough, and nothing wrong about it - scripting is obviously great for prototyping things quickly.

In the future, I'm definately willing to move this into FG (in one form or another).Once things converge, I'll think about moving stuff to C++.

You may want to structure the wiki article accordingly, to help identify well-defined components, that could eventually be re-implemented as part of the FG/SG/TG infrastructure. Even just knowing what python modules you are using would be interesting to see if/how making some of these bindings available to Nasal would be helpful to make some of your work possible using integrated tools.
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 11376
Joined: Tue Mar 25, 2008 8:40 am

Re: LOWI city buildings

Postby adrian » Tue Aug 27, 2013 7:30 am

Radi, you stated in the wiki article that FG eats about 2.8 Gb RAM while loading buildings like this. Did you try with my FG/simgear patches which load detailed tiles only for the center, the rest being bare loaded? I have reduced the memory footprint on my machine by 40% with those patches.
Current random buildings have a big disadvantage: they have no collision box and can't drop shadows. While OSM buildings might be available only for 10% of all cities.
Nice work btw, my compliments.
adrian
 
Posts: 362
Joined: Wed Sep 15, 2010 2:15 pm

Re: LOWI city buildings

Postby radi » Tue Aug 27, 2013 8:17 am

Hi Adrian,

I'm lucky enough that 2.8 GB is no problem for my machine, but then I might some day try to populate larger areas... so thanks for the heads-up! No, I wasn't aware of your patches, but while I think I found the thread on fg-devel
http://www.mail-archive.com/flightgear- ... 38961.html
I failed to find a download link for the patch. Could you please point me to your latest version? I regularly compile from git (using home-brew scripts), so patching would be OK for me.
OSM buildings for LOWI, EDDC
Custom scenery for VHXX YMML
Edit .stg via the FG Object Placement Tool
radi
 
Posts: 643
Joined: Mon Aug 25, 2008 4:24 pm
Location: YMML, EDDC

Re: LOWI city buildings

Postby adrian » Tue Aug 27, 2013 5:44 pm

Right now the Gitorious web interface has changed much, so I can't really find my own stuff :) but you can try to find my clone of flightgear and simgear, the most recent code is available in the radio_next branches if you're willing to put up with a couple of oddities from my recent commits, or you can get the tile_loading branches, but I'm not sure that's the most complete. Really, radio_next is about a month behind next and compiles and runs ok here and has all the terrain code inside.
adrian
 
Posts: 362
Joined: Wed Sep 15, 2010 2:15 pm

Re: LOWI city buildings

Postby Hooray » Tue Aug 27, 2013 6:06 pm

@adrian: I suggest to send a heads-up to Stuart regarding your memory-improvement-patches, he's the developer of the random buildings code and he's shown lots of interest in improving memory occupancy in various discussions on here, so you may just need to send a reminder because most regular contributors are currently busy with other things - ideally, your patch could be made optional, i.e. a startup option - so that it would be easier to review/merge it - if Stuart doesn't respond, send a heads-up to Zakalawe and ask him to have a look.
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 11376
Joined: Tue Mar 25, 2008 8:40 am

PreviousNext

Return to Scenery

Who is online

Users browsing this forum: No registered users and 1 guest