LOWI city buildings

[radi]

https://dl.dropboxusercontent.com/u/24846517/fg/osm2city/LOWI_OSM_buildings_20140928.tgz
NEW: I no longer include Terrasync models in my .stg. The readme.txt in the above archive describes how to install this as an overlay along with existing scenery.


Does anyone have Austrian style facade textures handy? Or wouldn't mind taking pictures?

[Hooray]

That looks great, but please keep in mind that we do have the random buildings feature, and there's been talk on providing region-specific textures: http://wiki.flightgear.org/Random_Buildings

[penta]

I've some pictures taken at Innsbruck:
http://www.flickr.com/search/?w=3917460 ... =innsbruck

Let me know if there is something useful. I don't mind licensing them to allow use in flightgear.

[ot-666]

Looks amazing
I have to admit that i really like the random buildings feature and it does wonders in most places, but this is so much closer to the real thing.

Oliver

[F-JJTH]

I'm curious to see the result with OSM road (mostly "residential")
Good work !

Cheers,
Clément

[Thorsten]

I have to admit that i really like the random buildings feature and it does wonders in most places, but this is so much closer to the real thing.

Can you point to the differences?

The way random buildings are distributed isn't god-given, and algorithms can be improved once we know into what direction. Having a scalable solution for the whole world is always preferable over having a solution for a particular place.

[penta]

Can you point to the differences?

IMHO the most noticeable difference is the alignment of buildings with streets (you can clearly see blocks sorrounded by empty spaces where streets should be). But, if I recall correctly, this was already discussed for random buildings.

[radi]

What's the point of posts like that, Thorsten? I very much appreciate your constructive input on FG-devel (yet failed to say thank you for that so far -- Thank you for that!) or in other posts, but I don't see how this post helps the FG project. And I wouldn't mind if you were some random forum user.

I can easily spot the difference between current random buildings and OSM derived ones for the area I live in. As penta pointed out, It's the alignment with OSM roads. The particular shape of some buildings I recognize. The clustering of some hi-rise buildings that makes me recognize a particular quarter. Of course it'd be more difficult to judge for areas I don't know IRL. Or if random buildings would for example follow OSM roads. ATM, however, they simply don't.

Having a scalable solution for the whole world is always preferable over having a solution for a particular place.

That would apply here if the scalable solution would produce the same quality as the particular one. See above: it just doesn't ATM. And the fact that the algorithm could be improved does help exactly zero for those how'd like to fly around an urban landscape just now.

It's perfectly fine if you prefer cross-country flights where average scenery quality matters, but there are others who occasionally happen to enjoy flying around areas they know and/or are very well modeled. Individual modelling a few (on a global scale) buildings like Oliver does for the LOWI area scales equally bad. Yet FG has infrastucture (the scene models DB) to foster exactly that. Why is that? Some people seem to be attracted -- scenery wise -- by peak performance rather than global average performance.

BTW: My long term plan is indeed to improve random buildings placement/random scenery generation. I'm learning here, and I thought I wanted to share what I produce along the way.

[radi]

I've some pictures taken at Innsbruck

Penta, thanks for the offer, these are great shots from an artistic point of view. However, in my experience, or for my work flow, the best photos for texture extraction are the pale, boring ones: shot orthogonal, in overcast conditions, insulting the artistic eye

[Thorsten]

What's the point of posts like that, Thorsten? I very much appreciate your constructive input on FG-devel (yet failed to say thank you for that so far -- Thank you for that!) or in other posts, but I don't see how this post helps the FG project

The point of this particular post was to get for instance this answer:

IMHO the most noticeable difference is the alignment of buildings with streets (you can clearly see blocks sorrounded by empty spaces where streets should be).

Which confirms that I'm thinking into the right direction - if we could come up with an algorithm which creates a virtual European-style street grid first and then places buildings aligned with the street grid, we'd generate better cities in Europe (OSM is a red herring for the purpose imo - once it's random, we need something plausible and fast, not something exact).

The answer could also have been 'the relative distribution of large and small buildings' or 'the presence of non-rectangular buildings' - all of which refer to different knobs in the random building scheme.

It's a no-brainer that actually modelling a city is better than random buildings - but the world is a big place, and 99.9% of it are autogen scenery and will be for a long time, so I happen to be interested in autogen scenery problems. I know where I think it could be improved, but I am interested in if others see the same things, or are bothered by something completely different.

Do you now see how the post helps the FG project?

[radi]

OK, so I got that wrong. When I read your post initially I swear it was saying "Can you point the difference?", as in "Wo ist der Unterschied?" with a deprecative connotation. This got me slightly offended. Sorry for that.

Still, here's another no brainer

Having a scalable solution for the whole world is always preferable over having a solution for a particular place.

and wording like

isn't god-given

sometimes can trick people into believing you're being offensive. Leaving out the two, I would have gotten your point right away. But I start nit-picking here.

[Hooray]

Which confirms that I'm thinking into the right direction - if we could come up with an algorithm which creates a virtual European-style street grid first and then places buildings aligned with the street grid, we'd generate better cities in Europe (OSM is a red herring for the purpose imo - once it's random, we need something plausible and fast, not something exact).

I agree, the key is coming up with a region-specific grid that can be used to align individual buildings, i.e. to have a "city generator" algorithm, like you mentioned earlier here:

Subject: Random Buildings

Hooray has (probably) some more involved dynamical city-building scheme in mind (so have I actually) - finding an algorithm which dynamically generates a street pattern and places a plausible mockup of a city dependent on its knowledge of the underlying terrain. Much of the performance here depends on what models are placed - if models without an xml wrapper are used, it's going to be relatively fast, if not, then not. That's different from the situation with weather where we could never use models without xml wrapper, because the rotation effect needed to be declared there (merging the models to a whole block is also important though).

I do still believe that the current random buildings code may be trying to be, and to do, too much here: it would already be helpful to strip it down, generalize it and expose it to scripting space (Nasal), so that placement algorithms can be prototyped there, instead of being confined to C++ space.

Frankly, just implementing placement algorithms in C++ simply doesn't scale too well, because we have a very limited number of experienced C++ contributors who know how to build from source. Like you said: scalability is the key.

We have all seen the power of making such hooks accessible to base package contributors, i.e. in examples like the local weather system, but also in the AI system - where features ended up being implemented that were never conceived by core developers in the first place.

With TheTom's new cppbind framework in SimGear, exposing C++ classes to Nasal (and vice versa) has become pretty straightforward, and there's no need anymore to use the property tree or marshall all your data into properties (unlike fgcommands like add-cloud etc).

A while ago, we also talked about porting PixelCity to be used in FG:
Subject: [Proposal] Autogen Cities using PixelCity

It really looks cool from the distance and close up.
Implementing it into FlightGear requires porting the OpenGL calls to be OpenSceneGraph compatible, probably by implementing osgDrawable.
The current implementation only shows night-time views, so this has to be tweaked, too.
Another issue to take care of is interaction with existing scenery models, so the generated buildings do not interfere with our scenery models. The same is true for our landcover, roads and elevation data.
Definitely worth some thinking. Probably as a google summer of code http://wiki.flightgear.org/index.php/GSoC project?

Meanwhile, I now believe that it would be better to only identify building PixelCity blocks that could be useful in FG, and reimplement those using Stuart's approach instead - so that all the placement heuristics can then be realized using base package code, rather than C++.

And Stuart repeatedly expressed his support concerning procedural scenery:
Subject: Procedural buildings in OSM before part of Scenery

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.

Good luck!

-Stuart

We do have enough skilled people interested in working on this, we only need to find a common set of goals - and focus on accomplishing those, rather than debating controversial ideas

[Thorsten]

OK, so I got that wrong. When I read your post initially I swear it was saying "Can you point the difference?", as in "Wo ist der Unterschied?" with a deprecative connotation. This got me slightly offended.

Um, yes, looking back I can see how you got the impression... Sorry about that.

I do like the potential of this very much - it seems it doesn't take you exceedingly long to generate a city layout, and it catches some features random buildings don't get, so I that got me the idea that random building technique can learn from the difference.

[radi]

Download now available: http://ubuntuone.com/28rp8VTc42fzxRzVNzM5Nm
There is sill some overlap with Oliver's static models, I will look into that.

it seems it doesn't take you exceedingly long to generate a city layout

I've scripted most of the work now, but some manual steps still remain. Will streamlinie that further until I have a fully automated process where I specify a region, and end up with a populated objects/ folder along with a release tar.gz.

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.

So our goals are very similar.

Many buildings from OSM are just rectangular, so they basically look like random buildings. I wonder if a mixed approach would render any faster? Where an OSM building is rectangular, place a random building of similar footprint instead?

[Thorsten]

Many buildings from OSM are just rectangular, so they basically look like random buildings. I wonder if a mixed approach would render any faster? Where an OSM building is rectangular, place a random building of similar footprint instead?

I'm not sure if they would render faster as such (well, depends on if your buildings have an xml-wrapper), the actual shader workload is pretty similar, and if the static buildings are organized in blocks, it should be just as efficient.

The memory footprint of random buildings may be much cheaper due to the instancing - essentially a random building needs just one coordinate triplet, whereas a static model needs a coordinate triplet for each vertex.

Also, another thing is that in the current FG structure, you can't turn static models off - so a large number of static objects may create a no-fly zone for users with low end graphics cards (I've heard that about Paris a few times) whereas you can always turn random buildings off or reduce their density.

So a mixed approach would have some appeal - also preventing overlap of static and random buildings is something that needs to be addressed.