20,741
edits
Using OSM Vector Data in FlightGear: Difference between revisions
Jump to navigation
Jump to search
m
Using OSM Vector Data in FlightGear (view source)
Revision as of 00:55, 31 January 2014
, 31 January 2014→Random Buildings Scripting Interface (Hooray, Thorsten)
mNo edit summary |
|||
| Line 87: | Line 87: | ||
Hooray and Thorsten have some more involved dynamical city-building scheme in mind - 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). | Hooray and Thorsten have some more involved dynamical city-building scheme in mind - 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). | ||
How about instead of texturing urban areas and towns, generating "fake roads" with modular blocks of buildings and trees? | |||
For instance, in the western USA you could generate a grid pattern for cities and towns and populate the grids with buildings using a formula. | |||
* it is possible to use various landclasses to distinguish parts of a city in custom scenery | |||
* that a prototype for autogenerating a city based on these landclasses in Nasal is feasible | |||
* that both myself and Hooray would help with the coding | |||
* i.e. that there's a clear and well-defined path from a wish to reality here at the simple expense of doing it | |||
In Nasal, one could: | |||
* use random geodinfo(); calls across the terrain to find spots where the terrain is urban (or otherwise interesting | |||
* call an autogeneration algorithm from that point to fill the whole urban region by | |||
** first creating a street pattern by means of an algorithm (European cities are not much more difficult - you just take a grid and allow for random distortions of the intersections and curvature of the streets, that should be pretty good already) | |||
** sample terrain while you do this - elevation and especially the presence of rivers alter the pattern | |||
** then determine what kind of quarter you're trying to build | |||
** then place buildings next to your streets, orienting them properly | |||
** throw parks, gardens and so on for good measure | |||
* do this till you hit the edge of the urban region | |||
* then go looking for the next | |||
* have a housekeeping routine in the background which deletes models which are too far away | |||
Too large modular blocks are actually a problem, because they create floating buildings wherever the terrain isn't level. So ideally you'd design the autogeneration with just single buildings as blocks and put the information which buildings are typically adjacent and how they typically arrange into your algorithm (it's a lot like clouds actually - Local Weather could create you a slightly randomized m x n grid of buildings clipped where the urban terrain ends with a higher city center region and lower surroundings with less than 100 lines of additional code, provided you have the models - the real work would be to get it to do European placement patterns, but the functions to do that are probably not as complicated as credible undulatus patterns). | |||
=== PixelCity (Hooray, TorstenD) === | === PixelCity (Hooray, TorstenD) === | ||