Board index FlightGear Development Scenery

osm2city.py development

Questions and discussion about enhancing and populating the FlightGear world.

Re: osm2city.py development

Postby radi » Mon Jul 04, 2016 12:18 am

Great to hear you're investing time into improving the texturing! I know what the problem is with the roof textures, I just don't have an easy solution...

I had introduced the -A option mainly for debugging when I was coding the texture atlas -- and back then, it's been very useful. I agree that it's not as important for most end-users, but I can still see a number of use cases where you'll want to re-create the texture atlas often: if you're
1. improving textures, for example by adjusting contrast, or trying different mipmap options -- I have done this a lot when I was creating the VHXX custom scenery
2. working on lightmaps (and I've got alpha code sitting around [mk_lightmap.py] that aims at automatically creating lightmaps from textures).
Plus, I don't see -A creating too much bloat, so I'd really like to keep -A.

Also (you're probably aware of this): changing the way the texture meta info is stored will break texGUI.py. I agree it may be more convenient to have it in csv for filtering etc. But then, storing all in one file (is that what you're planning?) will make it less convenient to copy textures between regional definitions. Maybe that is something we could discuss on skype sometime...
OSM buildings for LOWI, EDDC
Custom scenery for VHXX YMML
Edit .stg via the FG Object Placement Tool
radi
 
Posts: 641
Joined: Mon Aug 25, 2008 4:24 pm
Location: YMML, EDDC

Re: osm2city.py development

Postby vanosten » Tue Jul 05, 2016 3:49 pm

I guess I should have been using a bit more words. The osm2city -A version has been kept - I just have moved it to /textures/manager.py -a. I prefer more program entries with fewer parameters over the opposite.

I will build a validation function into manager.py (e.g. there is at least one roof which provides what any facade is requiring). I also want to expose some parameters to actually utilize the "provides" facilities - e.g. "age" and also "region" (as a list). Right now regions are implicitely hardcoded in catalog.py and the texture directory structure. Of course there will be an "ALL" possibility.

And to support this I will update http://wiki.flightgear.org/Osm2city.py_Textures and write out at least the roofs to a csv-files to begin with (i.e. keeping the current input format for a while and just add easier "debugging".
Maintaining osm2city. Contributing with ground attack stuff to the OPRF FlightGear military-simulation community.
vanosten
 
Posts: 410
Joined: Sat Sep 25, 2010 5:38 pm
Location: Denmark - but I am Swiss
Callsign: HB-VANO
Version: latest
OS: Win 10 and Ubuntu

Re: osm2city.py development

Postby vanosten » Thu Jul 07, 2016 9:25 pm

I have updated osm2city and osm2city-data with getting dynamic texture catalog information only. Did also some clean-up of registrations, which pointed to not available textures. The result is currently that ( a ) registrations are now only in osm2city-data and not in code as well as ( b ) that the default atlas is now more than double the size.

Next step is some more validations as well as by means of parameters reduce textures used to e.g. specific region(s).

http://wiki.flightgear.org/Osm2city.py_Textures is a bit updated. texGUI.py needs some recoding due to changes in linked libraries.
Maintaining osm2city. Contributing with ground attack stuff to the OPRF FlightGear military-simulation community.
vanosten
 
Posts: 410
Joined: Sat Sep 25, 2010 5:38 pm
Location: Denmark - but I am Swiss
Callsign: HB-VANO
Version: latest
OS: Win 10 and Ubuntu

Re: osm2city.py development

Postby pommesschranke » Tue Aug 23, 2016 11:36 am

when I make a village with 100 houses, osm2city makes 10 or 20 .ac files.
how can I avoid that ? I'd like to have all 100 houses in one ac file.
pommesschranke
 
Posts: 1104
Joined: Sat Apr 27, 2013 7:58 pm
Location: EDLM & LJCE
Callsign: d-laser
IRC name: laserman
Version: git
OS: Linux Lubuntu 18.04

Re: osm2city.py development

Postby vanosten » Wed Aug 24, 2016 2:48 pm

There are two parameters: TILE_SIZE and CLUSTER_MIN_OBJECTS. So depending on the area covered by these 100 houses, you might get more or less .ac files (assuming that you are only considering the ... city...ac files. If you are also running roads.py etc. you get more .ac files).

I cannot remember without reading the code, but I guess that different LOD classes go into different .ac files. Therefore the number of files for few houses is relatively larger than for many houses. That is depending on parameters LOD_...
Maintaining osm2city. Contributing with ground attack stuff to the OPRF FlightGear military-simulation community.
vanosten
 
Posts: 410
Joined: Sat Sep 25, 2010 5:38 pm
Location: Denmark - but I am Swiss
Callsign: HB-VANO
Version: latest
OS: Win 10 and Ubuntu

Re: osm2city.py development

Postby radi » Fri Aug 26, 2016 3:57 am

Correct for the most part, thanks Vanosten!

However, IIRC, CLUSTER_MIN_OBJECTS = 7 means that an area of TILE_SIZE with less than 7 individual OSM objects will not be generated at all. Also, different LOD classes all go into the same .ac (as different .ac objects though. Look for the name tag in an .ac, you'll find different 'LOD_" there).

So the only thing that should affect how many .ac are created is TILE_SIZE.
OSM buildings for LOWI, EDDC
Custom scenery for VHXX YMML
Edit .stg via the FG Object Placement Tool
radi
 
Posts: 641
Joined: Mon Aug 25, 2008 4:24 pm
Location: YMML, EDDC

Re: osm2city.py development

Postby vanosten » Tue Sep 06, 2016 7:31 pm

I have created a new branch "python3" and made all necessary changes to make the code compile and run against Python 3.5.

... At least that is my finding after applying 2to3 fixtures, doing some code search and running the commands known to me. I also tested all 4 elevation probing variants. There are a few other minor changes that I made, when I came across something. I did my testing on Linux.

And I have removed the calls "#!/usr/bin/env python.." from the top of some files, because they were quite inconsistent. If someone needs those, then please add them in a consistent way again.

=> I would be glad if someone could try the python 3 version and give some feedback (e.g. on Windows). Remember that some of the libraries need to be upgraded to the Python 3 versions - and if you are using build_tiles.py for batch processing, you should also update the python path parameter.

When a test by someone else also looks good, then I would suggest to merge into main and continue further development on Python 3.5+. Documentation has already been updated.
Maintaining osm2city. Contributing with ground attack stuff to the OPRF FlightGear military-simulation community.
vanosten
 
Posts: 410
Joined: Sat Sep 25, 2010 5:38 pm
Location: Denmark - but I am Swiss
Callsign: HB-VANO
Version: latest
OS: Win 10 and Ubuntu

Re: osm2city.py development

Postby oscar6662 » Tue Sep 06, 2016 7:54 pm

Oh perfect Where is the link :)??
Todo bien todo correcto? Y yo que me alegro!!!
#keepKSFO

Sir. Berenguer
oscar6662
 
Posts: 118
Joined: Thu Nov 05, 2015 5:52 pm
Callsign: AA2234
IRC name: N/A
Version: 3.4.0.
OS: windiws.7.pro.

Re: osm2city.py development

Postby vanosten » Wed Sep 07, 2016 4:35 am

Maintaining osm2city. Contributing with ground attack stuff to the OPRF FlightGear military-simulation community.
vanosten
 
Posts: 410
Joined: Sat Sep 25, 2010 5:38 pm
Location: Denmark - but I am Swiss
Callsign: HB-VANO
Version: latest
OS: Win 10 and Ubuntu

Re: osm2city.py development

Postby oscar6662 » Wed Sep 07, 2016 10:58 am

Thanks:
C:\Users\Oskar\Desktop\osm2city-python3-bd957f8b43fc1e35e260431d748c3b16c722cd28>C:\Users\Oskar\AppData\Local\Programs\Python\Python35-32\python.exe osm2city.py
usage: osm2city.py [-h] -f FILE [-e] [-c] [-a] [-u] [-l LOGLEVEL]
osm2city.py: error: the following arguments are required: -f/--file

Any clue?
Todo bien todo correcto? Y yo que me alegro!!!
#keepKSFO

Sir. Berenguer
oscar6662
 
Posts: 118
Joined: Thu Nov 05, 2015 5:52 pm
Callsign: AA2234
IRC name: N/A
Version: 3.4.0.
OS: windiws.7.pro.

Re: osm2city.py development

Postby radi » Wed Sep 07, 2016 11:08 am

RTFM. Wiki page and docs exist for a reason, and Vanosten has put a lot of effort into it.
OSM buildings for LOWI, EDDC
Custom scenery for VHXX YMML
Edit .stg via the FG Object Placement Tool
radi
 
Posts: 641
Joined: Mon Aug 25, 2008 4:24 pm
Location: YMML, EDDC

Re: osm2city.py development

Postby pommesschranke » Wed Sep 07, 2016 11:31 am

I love osm2city!

But the bug that bugs me the most for a very long time are the textures on big roofs.
I did read a lot of the code and tries some hacks, but still cannot find a way to use a different texture(-atlas) file
file for roofs than for walls to avoid seeing wall textures and windows on the roofs.

any hint maybe ?
pommesschranke
 
Posts: 1104
Joined: Sat Apr 27, 2013 7:58 pm
Location: EDLM & LJCE
Callsign: d-laser
IRC name: laserman
Version: git
OS: Linux Lubuntu 18.04

Re: osm2city.py development

Postby radi » Wed Sep 07, 2016 12:23 pm

I understand that. Currently, different texture atlases for roof and walls are not implemented, and I don't think it'd be wise to do so. It would instantly double the number of draw calls, resulting in a significant performance hit.

Here's what I think would need to be done as kind of a quick fix:
- add some huge roof textures to the catalogue, i.e. some for 100x100m, 100x200m, 200x200m, perhaps even 400x400m. For testing, just copy an existing one and change the dimension in meters. (their actual pixel size can still be reasonably small -- I recon even if they're blurry it'd still look better than what we get now.)
- in building_lib.py:analyse(), the texture that gets assigned to a roof geometry needs to be equal/larger than the longest edge of the roof geometry (which is stored in b.longest_edge_len). So one would have to pass a minimum length when finding texture candidates (currently, the call is roofs.find_matching() from within building_lib.py:analyse()).
- to this end, (in textures/manager.py) derive a new RoofManager class from TextureManager, change find_candidates() such that you can pass a min length. Luckily, FacadeManager already does this; you can basically copy most things from there. Also, look at building_lib.py:analyse():facades.find_matching() for an example.

Now, before you touch the code, try if the strategy works in principle: change the dimension of ALL roof textures to something huge, e.g. 400x400m. This should get rid of most/all roof bugs.

Large roofs should now look OK, though somewhat blurry. A clean, long-term fix would involve sub-dividing large roof geometry, but that would require quite some work.
OSM buildings for LOWI, EDDC
Custom scenery for VHXX YMML
Edit .stg via the FG Object Placement Tool
radi
 
Posts: 641
Joined: Mon Aug 25, 2008 4:24 pm
Location: YMML, EDDC

Re: osm2city.py development

Postby vanosten » Sat Sep 10, 2016 8:09 am

I have now also run the stuff on Windows 10 and corrected a bug due to default encoding on Windows not being utf8. From my point of view osm2city is ready for Python 3.5. Unless someone tells otherwise, then I will merge the changes into the main branch (and preserve a 2.7 version in a branch).
Maintaining osm2city. Contributing with ground attack stuff to the OPRF FlightGear military-simulation community.
vanosten
 
Posts: 410
Joined: Sat Sep 25, 2010 5:38 pm
Location: Denmark - but I am Swiss
Callsign: HB-VANO
Version: latest
OS: Win 10 and Ubuntu

Re: osm2city.py development

Postby vanosten » Sun Sep 11, 2016 3:25 pm

osm2city is now dependent on Python 3.5+.

I took a deep breath and hit the merge button.
The version before merge is available at last_python_2. However I would rather help resolving issues then people continuing using the old version.
Documentation is now hosted on Read the Docs. Again please tell me, if something in the docs is not clear - it might be obvious to the developers, but if you are wondering then probably others would be wondering, too.

The reasons for this change are amongst others:
  • Newer Python versions have interesting features for developers - and developers do not necessarily want to work with older versions
  • osm2city depends on external libraries, many of which might get supported only in maintenance mode in the near future
  • Speed (however I have not done any comparisons)

The wiki article will be updated later.
Maintaining osm2city. Contributing with ground attack stuff to the OPRF FlightGear military-simulation community.
vanosten
 
Posts: 410
Joined: Sat Sep 25, 2010 5:38 pm
Location: Denmark - but I am Swiss
Callsign: HB-VANO
Version: latest
OS: Win 10 and Ubuntu

PreviousNext

Return to Scenery

Who is online

Users browsing this forum: No registered users and 1 guest