Thorsten wrote in Sat Apr 06, 2013 11:52 am: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 BuildingsThorsten wrote: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 PixelCityTorsten wrote: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 Scenerystuart wrote: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
