XP Scenery Generator [WIP]

[PilotBalu]

It seems missing  artwork is the main issue .

 

That's it! Missing artwork stopped me to add regional buildings. At least, LyAvain and me made the "European Library" to change standard XP houses in Europe (with help of R2_Library) to European style.

 

To generate a nearly real looking scenery out of OSM, we need this artwork, and I would be glad with the help of some users this could be achieved.

Edited January 29, 2014 by PilotBalu

[tonywob]

What about a spreadsheet holding the dates of possible objects and feeding it in your tool.

A line could look like this:

type width length height  dx dy dr (origin deltas to center)  object-path

This indeed would quite easily be achievable, but someone would have to calculate all the origins. The big problem I have at the moment is getting the origin and size of objects. Sometimes models are listed as 10x15, and this position I can give the program, I can also tell it that I know the origin is in the bottom-right, and it will estimate the centre point of rotaton. If the origin, or XxY size is unknown, this information can be seen by opening the model up inside WED. Otherwise the program just places the object at the models (0,0) point.

 

 

That's it! Missing artwork stopped me to add regional buildings. At least, LyAvain and me made the "European Library" to change standard XP houses in Europe (with help of R2_Library) to European style.

 

To generate a nearly looking scenery out of OSM, we need this artwork, and I would be glad with the help of some users this could be achieved.

Indeed, I went through the R2 library and added as much as possible to my config file, after generation, the program managed to remove around 10,000 facades and replace them with will real buildings in a 1x1 square north of Berlin. The results are impressive and are shown in the below screenshots:

 

 

 

 

 

 

It really does make a huge difference to rural areas. In cities and larger towns, it's generally a mixed bag of objects and facades, however generated coloured/textured facades from OSM, and custom models does improve the situation. It certainly seems the way to go, but we need a community effort to fill out the OpenSceneryX library with custom buildings. Preferrably each model should have the (0,0) coordinate at it's center, and it should be modelled without any internal rotation, and include specification for a width/height.

 

Edit: Since I'm blocked on x-plane.org, I haven't been able to reach out to users on there for help. But if anyone fancies organising a community effort, then it would be very helpful

Edited January 29, 2014 by tonywob

[alpilotx]

And a few more, important constraints on "auto-placed" buildings:

• they should always have a "basement" attached (a grey block etc.), which goes below the (0,0,0) origin! This way you will not have "floating" / "half floating" objects, when they are placed on sloped terrain!
• try to have as much objects as possible use as few as possible texture files (rather use a few 2048x2048 ones) ... always try to put as many texture elements in a file as possible

And about the size .... I think, you could avoid the need for "object size calculations", if there would be a naming scheme which has the dimensions already included. I think, its overall an important factor to have a sane naming scheme, which already "represents" the main characteristics of the building (footprint dimension, height in levels, color, type, main form, etc.). This can vastly improve possibilities to automate the scenery generation.

 

The longer I think about it, the more I would say, that maybe it would be time to create an "own" new object library, which is focused on OSM scenery generation. Would have facades, a wast amount of default house types, a few other, more specific objects (like churches, petrol stations, wind turbines, light houses etc ... the classic OSM entities you would find on all maps) and also vegetation stuff (forests and single tree objects).

[JohnMAXX]

To add to that a set of generic Skyscrapers would help the plausibility of major metro areas.....Pretty please with sugar on top?

 

Great work Tony

[tonywob]

I think, you could avoid the need for "object size calculations", if there would be a naming scheme which has the dimensions already included. I think, its overall an important factor to have a sane naming scheme, which already "represents" the main characteristics of the building (footprint dimension, height in levels, color, type, main form, etc.). This can vastly improve possibilities to automate the scenery generation.

 

Yes absolutely. It's a chore at the moment having to open each model up, measure it, calculate where the centre is, and then add a new rule. If the program could just scan a folder of objects and create rules based on correctly named objects, it would make life easier, and also would make it easier to add new models in.

 

So who's up for starting a scenery pack? ;-)

[MrIch]

It would be great to have a solution for this issue too:

http://forum.osm2xp.com/index.php?topic=136.0

Gesendet von meinem GT-I9300 mit Tapatalk

[tonywob]

It would be great to have a solution for this issue too:
http://forum.osm2xp....php?topic=136.0

 

The problem is with the OSM data and facades. Many people choose to map buildings by placing multiple buildings inside each other, each with different heights. When edges touch you will get the noticable flickering. The problem is the min-height tag, which says that the particular building part is 3 places of the ground. X-Plane facades can't be suspended in mid air, hence this isn't possible with facades alone.

 

You could either create a filter to ignore all these buildings parts, or I could add do an intersection test on all buildings in a tile, and join intersecting buildings (This would slow generation considerably).

 

The situation is even more difficult when you mix objects and facades together. In my tests, some buildings which have separate parts have a real object placed inside the footprint. So, I need some way of detecting this (I can't always rely on tags).

 

Generally though, if you see a flickering building, you can go and fix it in OSM. Some of the data in OSM is quite messy, especially forests and buildings. When I generated Switzerland, there were lots of forests with self-interesecting polygons, which is not a valid polygon and causes all manner of problems. Generally, if I find such an item, I have to skip it for now (I may come up with some way of fixing them, i.e. Removing the interesecting node). There are also lots and lots buildings that have been added twice, one on top of the other. JOSM normally detects these, so you could download the offending area into JOSM and run the "remove duplicate ways" validation and reupload to OSM :-)

[Colin S]

Just a general question to make sure I'm not wasting my time doing a ton of OSM stuff for my local area (at about 400 houses/barns/buildings so far), building:levels is the tag for building height, right?

[tonywob]

Colin, that's correct, building:levels indicates how many stories the building has, e.g. buildling:levels=2 for a two storey house. Also, you can height=, e.g. height=10, to indicate a building's height in metres.

[Colin S]

Colin, that's correct, building:levels indicates how many stories the building has, e.g. buildling:levels=2 for a two storey house. Also, you can height=, e.g. height=10, to indicate a building's height in metres.

 

Thank you. What about roof type? Will your utility be caring whether it has a sloped roof or not?

[tonywob]

Thank you. What about roof type? Will your utility be caring whether it has a sloped roof or not?

 

That's up to you :-), you will be able to configure it to make sloped roofs if it finds that tag. At the moment in the default config, it picks up the roof:material and roof:color tags and makes a texture for it. Sloped roofs are a bit funny, as it requires the building to be simple and all sides orthogonal. The program can be told to simplify the shapes if it needs to.

[Leporello]

Hello, while doing my small scenery of a GA airport in Piedmont, Italy I run into trouble to find regional houses to put into the scenery. I was about starting to create my own library of obj models so I can definitely help working on a common library to better render rural zones specific for Italy. I think we need a project coordinator to write down what you need and allocate work to available people.

[tonywob]

Thank you Leporello. If you decide to make some objects, try and follow the guidelines, i.e.

 

• The origin (0,0,0) should be on the ground center of the building, so it can be rotated correctly
• Add an underground area on the z axis, so that objects placed on the side of slopes don't float (Thanks to Andras for this suggestion)

As for a list of required buildings, I guess it's simply a case of the more the better. As long as we stick to a common naming convention, I would suggest:

- XXX_YYY_HEIGHT__REGION_INDEX, e.g. 10_14_3_IT_1.obj, 10_14_3_IT_2.obj for two random houses which are Italy themed, have an area of 10x14, and 3 floors. The region codes can be further divided if needed, as long as we stick to some rule, so the engine will know.

 

The problem is we need someone to host it and coordinate updates. At the moment I so busy with the application, that I don't have the time to set anything up. If anyone wants to volunteer, then that would be great

[JohnMAXX]

Tony I hope you do get some community participation for this project,  it is coming along very nicely.......

[Leporello]

Thank you Leporello. If you decide to make some objects, try and follow the guidelines, i.e.

 

• The origin (0,0,0) should be on the ground center of the building, so it can be rotated correctly
• Add an underground area on the z axis, so that objects placed on the side of slopes don't float (Thanks to Andras for this suggestion)

As for a list of required buildings, I guess it's simply a case of the more the better. As long as we stick to a common naming convention, I would suggest:

- XXX_YYY_HEIGHT__REGION_INDEX, e.g. 10_14_3_IT_1.obj, 10_14_3_IT_2.obj for two random houses which are Italy themed, have an area of 10x14, and 3 floors. The region codes can be further divided if needed, as long as we stick to some rule, so the engine will know.

 

The problem is we need someone to host it and coordinate updates. At the moment I so busy with the application, that I don't have the time to set anything up. If anyone wants to volunteer, then that would be great

 

Yes, some rule is exactly what is needed to avoid duplication and time consuming revision. But I think those rules must be set by you who is fully aware of how OSM is coded and working. I will follow your guidelines for further work. 

 

Underground area is mandatory for a decent look of most houses especially in hilled area as the one I'm dealing with, where half if not all are detached house on sloped terrain.

Edited February 1, 2014 by Leporello

[tonywob]

But I think those rules must be set by you who is fully aware of how OSM is coded and working.

 

Many thanks for getting the ball rolling with some models.  I presently use the following from OSM and the generated geometry for buildings

• Area (width/height) m2
• Residential/Industrial/Commercial/Unknown
• Height (in metres, or in levels)
• Roof type and colour, e.g. Sloped, Dome, Red Tiled, Flat, etc..
• Wall color and material, e.g. red brick, glass
• Whether the buildings is round or square
• Its position (i.e. Longitude/Latitude)
• Number of sides

What maybe a better idea is that we just keep a master list, e.g. a CSV file with columns that list all the information and which model to use. If more information is discovered inside OSM later on, or new tags are added  (as they frequently are), or features are added to the generator, then we can just add a new column to the CSV instead of renaming every file. I can come up with this CSV file, and write an importer to read it in automatically.

 

One of the problems with data in OSM is that outside of cities, it's more or less guess work with most of the tags, since you'll find most buildings are just tagged as "building=yes". So I use the area of the building to determine it's type, i.e. small buildlings are more than likely residential, larger industrial. 

 

What I may do at a later date is record the underlying landuse tags (i.e. Residential/Commercial/Woodland). This will slow down generation a little bit, but will give generically tagged areas a better appearance.

[alpilotx]

Hi Tony

What I may do at a later date is record the underlying landuse tags (i.e. Residential/Commercial/Woodland). This will slow down generation a little bit, but will give generically tagged areas a better appearance.

Well, this is another approach I wanted to "recommend" since a long time .... namely, using some "external" (and not just OSM landclass info!) data as a "hint", when deciding about buildings which otherwise only have building=yes ... Indeed, landclass information can be a help .... sometimes ... sometimes not. It always depends on the data quality, resolution and what classification it brings (or brings not) .... For example in Europe, you will find information about industry areas in the CORINE landclass data (which I also use in all my X-Plane work since ages) .... Its not super detailed with its 100mresolution, but neither is it that bad (maybe combined with footprint extent, it might work halfway sanely) .... Or for example in smaller cities, which don't have detailed building infos either, one could use some "density" information to decide, where you would see "family" houses or a bit larger city blocks etc

 

.... Just some ideas.

 

PS: and by the way, I think (I know!) if you work with raster landclass data instead of polygon data (for lookups), you might get much faster results ... of course, the price you pay is, that raster data has an inherent "resolution" limit.

[tonywob]

Hi Andras

 

Thanks for the idea, since the scenery generation is already starting to slow down due to all the geometry checks and "fixing" I need to do on the OSM data to make it compatible (e.g. Self-intersecting polygons, splitting multipolygons, relations with missing members), I'm reluctant at the moment of adding the landuse checks using OSM data, since it will require me to process and preprocess more data, making the generation even slower.

 

It's something that is needed, because the object-footprint placer (whatever it is called) is placing buildings into places that aren't correct, e.g. It's placing a family house in the middle of an industrial estate because the building footprints match. If I set it to only insert the building with residential tags, it leaves villages full of facades because they are using generic tags, so it's a no-win situation.

 

I guess it's a question of whether the program should be runnable by average simmers or not. If I decide to include extra data, it would have to be as an option in the config file and can be skipped, but it's something I know is going to be needed to make the scenery more convincing.

[tonywob]

Having looked at the 3D information inside OSM, it's actually much more advanced than can be handled with facades alone, e.g. The Fernsehturm in Berlin, consists of several cylinder buildings, which start at different levels (i.e. min-height tag). Since facades can be offset from the ground, the 3D effect falls over with buildings like this. The effect isn't bad, but it could be much much better.

 

Additionally, other buildings have domed roofs, sharp roofs, etc, none of these can be rendered as a facade. After stabilising what's currently in the application, I might put it on the list for the program to actually generate a proper 3D model based on this information. The .obj file would just use a simple repeating texture, but it would still look much better than the default facades

[scotchegg]

Looks really promising Tony!!

 

BTW Andras I know you thoroughly deserve a break from XP, but thinking of any other projects at the mo?

[alpilotx]

BTW Andras I know you thoroughly deserve a break from XP, but thinking of any other projects at the mo?

... yes, indeed I am currently not as active as at some other times (but really need some break from time to time, with family, real life etc. etc.) ... BUT  I also have started work on my next little project. It wont be something entirely new, but it will be a welcome (I think, very welcome) update of a well know project. It will be the "X-Plane 10 Tree Lines and Farms v2" ... I will extend the coverage of the old project a bit, tune a bit here and there, and add a new (and I think this will be the most noticeable update) feature, namely tree lines along water features ... But don't ask me for timing, as i don't know. Something between a few weeks and a few months ...

[AeroPictor]

 

Take your time, family life is very precious and every body should respect this.  

[scotchegg]

Sounds great Andras. Trees along waterways can really add to the visuals.

[tonywob]

Andras, I added something I call a "line rule" into the generator, and it will place repeating random objects along a way (or perimeter of an object). It can be used, e.g. To surround fields and farmland with trees, or as in treelines along rivers, a rule could be created to run lines of trees alongside a way tagged as drain/stream, etc. 

 

It needs some work though, as it will actually place the object on the line, which means the trees will be in the water. So it needs to offset it somehow. I think such rules can be quite powerful, but the problem is the potential for a collision with another object. e.g. I also have a rule which fills out an area with random objects, so for example, it puts cars in a car park. However, I tried it with putting trees into residential areas, and in some areas it looks really good, in others not so much, as the tree ends up inside the house

[alpilotx]

Hi Tony,

 

Yes, thats exactly what will take most of my time ... doing a halfway sane removal of parts of the tree lines, where it would collide with something else. Though, if you want to accomplish it in a finite time, you will always need to accept some compromises because some geometric operations are anything but cheap (when it comes to processing time - or you own sanity). Well, I will see how it works (but will take some time until I see first results :-) ) ...

 

By the way, in what "language" are you coding / scripting your way? Most of my - current work - is done in PostGIS ... which already makes it less accessible for average users, as you need to run a PostGIS (effectively a PostgreSQL with PostGIS extension) database. But when its running, then PostGIS is a mighty powerful set of GIS functions, which helps to solve a lot of problems (but not necessarily always easy ) and one can work with a database approach (which I like, as I am used to big databases anyways).  ....

 

PostGIS is also my main tool to extract all the necessary data for Laminar and/or my HD Mesh Scenery v2 ... And it works quite nicely with a complete planet OSM export (as long as you can use a big and fast SSD to stoe the database on).