Board index FlightGear Development Scenery

Random Buildings

Questions and discussion about enhancing and populating the FlightGear world.

Random Buildings

Postby stuart » Thu Apr 19, 2012 10:09 am

Hi All,

(Cross-post form the -devel list)

I've recently been working on creating random buildings dynamically, as opposed to the fixed models that are used for the random objects placed around the scenery. The buildings are created with a random size, type, texture etc. within the FG C++ code itself, and make use of the some of the techniques we developed for the random vegetation to minimize the performance hit..

The results so far are very promising, and in particular have no frame-rate hit on my system, even at very high densities.

This should be in git shortly.

Screenshot below:

Image

Further technical details taken from the -devel list post for those interested:

At a functional level, there are three different size of buildings
(small, medium, large), with slightly different constraints (small and
medium buildings are never deeper than they are wide, small buildings
may have pitched roofs). Various parameters can be set in the
materials.xml file, such as the proportion of each building size, the
texture file (which is shared across all buildings), and the range of
sizes of each building. The actual buildings are then generated by
FG itself directly as OSG primitives.

Obviously, this would be pointless if frame-rates were hit to the same
extent as they are with a similar number of normal models. The good
news is that on my system there is _no_ fps drop from the random
buildings. I get the same frame-rate whether or not the random
buildings are generated or not. The same applies whether or not I'm
running with Rembrandt.

Of particular note - I get significantly better frame-rates with this
rather than the urban shader.

For those interested, the technical background is as follows:
- a Quadtree is used to ensure very fast culling of the buildings -
based on the work that Tim Moore did for the forests.
- a single 1024x1024 texture is used for all the buildings, minimizing
the number of state changes on the GPU
- all the buildings at the leaf of the quadtree are part of the same
geometry, so the GPU can churn through it very quickly without having
to change state.

There are still some bugs to be worked out before this can be pushed
to git, but I'm hoping to get it checked in over the weekend.

If someone is interested in spending some time creating a better
default texture, please get in touch.
G-MWLX
User avatar
stuart
Moderator
 
Posts: 1629
Joined: Wed Nov 29, 2006 10:56 am
Location: Edinburgh
Callsign: G-MWLX

Re: Random Buildings

Postby Alral » Thu Apr 19, 2012 12:11 pm

Nice, but...
1) How do they go on with custom models? Won't there be overlapping (like getting a hybrid of a random building and a scenery object). Maybe they can be somehow locally switched off (in some determined space).
2) If only they didn't appear over the roads...
http://www.flightgear.org/forums/viewtopic.php?f=5&t=9312

Over borders that divide the earthbound tribes
No creed and no religion...
(Iron Maiden, "Coming home")


Constellation in the night sky
Alral
 
Posts: 287
Joined: Tue Sep 22, 2009 7:52 pm
Location: Tallinn, Estonia
Callsign: Alral
Version: 2018
OS: Windows 7

Re: Random Buildings

Postby stuart » Thu Apr 19, 2012 12:31 pm

At present, there will be overlapping with custom models, as there is with the current random models. That's one area I need to improve, but it won't be fixed in the initial git check-in

The overlap with the road is a bug I will be fixed before checkin to git.

-Stuart
G-MWLX
User avatar
stuart
Moderator
 
Posts: 1629
Joined: Wed Nov 29, 2006 10:56 am
Location: Edinburgh
Callsign: G-MWLX

Re: Random Buildings

Postby Hooray » Thu Apr 19, 2012 3:53 pm

This looks great!
Stuart, do you have any plans to provide some sort of interface to your random buildings subsystem?

I am thinking in terms of something similar to the cloud interface that you provided (where you added a new "add-cloud" fgcommand) - just with a focus on placing buildings instead of clouds. Making the placement algorithm accessible (or configurable) would be great.

There seems to be a growing interest in populating the scenery with buildings, so having some sort of scripting/property interface that could be accessed from Nasal would be great.

viewtopic.php?f=5&t=9480
viewtopic.php?f=5&t=10016
viewtopic.php?f=38&t=8837
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

Re: Random Buildings

Postby Rickbritto » Thu Apr 19, 2012 4:10 pm

hello friends, Is possible to separate the random loading by types of buildings?

as residential areas with houses,urban areas with Great Buildings,Commercial areas with buildings commercial stores.

I separated some models I made in blocks, as shown below, and we could implement them in random loading

hugs.

Urban Zones
Image

Residential Zones
Image

Commercial Zones
Image

All City
Image

Image

Image
Rickbritto
 
Posts: 21
Joined: Fri Feb 10, 2012 4:42 pm

Re: Random Buildings

Postby Hooray » Thu Apr 19, 2012 4:17 pm

Rickbritto wrote in Thu Apr 19, 2012 4:10 pm:hello friends, Is possible to separate the random loading by types of buildings?


That's a great idea, and it was apparently also discussed on the mailing list: http://www.mail-archive.com/flightgear- ... 37003.html

This was also discussed in the "Instant City" thread a while ago: viewtopic.php?f=5&t=10016

Your screenshots are really impressive, and it will be great to see how Stuart's code could be made more configurable, so that non-C++ developers can help populate the FG world with such 3D models of buildings or even cities. This is exactly what happened when Thorsten picked up weather development using Nasal - this might also happen for autogen cities once the interface is flexible enough to be accessible from scripting space.
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

Re: Random Buildings

Postby stuart » Thu Apr 19, 2012 4:49 pm

@Hooray: I don't have any plans to add a Nasal interface at present. I'm planning to make the materials.xml format flexible enough to allow people to specify building sizes, types and textures, but not define complete buildings at the vertex level. That should provide enough flexibility that a scenery developer can create a realistic city-scape, though the complexity of buildings will be limited.

A Nasal interface would be tricky to add, as a lot of the efficiency gains arise from combining all the buildings into a single model.

@Rickbritto: Yes - different types of buildings are be mapped to different terrain types, so urban areas have more tall buildings than residential areas.
G-MWLX
User avatar
stuart
Moderator
 
Posts: 1629
Joined: Wed Nov 29, 2006 10:56 am
Location: Edinburgh
Callsign: G-MWLX

Re: Random Buildings

Postby Hooray » Thu Apr 19, 2012 5:36 pm

stuart wrote:A Nasal interface would be tricky to add, as a lot of the efficiency gains arise from combining all the buildings into a single model.


I think it depends on the nature of the interface - as you undoubtedly know, there are at least 3 different ways to make something accessible to Nasal, and all 3 methods have different advantages and disadvantages.

So the question is what your C++ code looks like - it might be easier to add a bunch of Nasal extension functions than using an fgcommand or a listener-based subsystem, depending on the underlying C++ code.

Assuming that you have 2-3 different methods which prepare, combine and then update/render the buildings, these could be exposed in the form of different (and separate) helpers - either as fgcommands or as Nasal extension functions.

I am just thinking there's probably lots to be gained by enabling base package developers to contribute to this part of FG, we've all seen how this approach made really complex weather simulation possible, just because Thorsten was able to do this without writing any single line of C++ - and because people like you, Torsten and Erik implemented the requested changes.

From a resource management point of view, that's probably an ideal scenario - because core developers could not have possibly implemented such things on their own without such a short amount of time.

Just imagine for a second what that could mean, if some skilled Nasal coder were to contribute to autogenerated scenery the same way Thorsten did for the weather system...
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

Re: Random Buildings

Postby mr_no » Fri Apr 20, 2012 12:26 am

For this random code to work better cities should probably need a few land layers like centre, midtown, suburbs then the code would generate buildings with appropriate height.
Mosquito-XE JT-5B-autogyro Extra-300s STOL-Ch701
User avatar
mr_no
 
Posts: 360
Joined: Thu Jan 19, 2012 3:20 pm

Re: Random Buildings

Postby kyokoyama » Fri Apr 20, 2012 12:35 am

Could it also be possible to arrange the layout of the buildings based on the actual OSM road layout? (i.e. -line each random building according to where and how the roads are laid out)
Look for "B-BIRD" "N127KY" or "AVA0004" -that's me.

Despite having over 1700 posts here, I am not even close to being the most skilled guy here... I'm just words and bad drawing, not experience. :P
kyokoyama
 
Posts: 1981
Joined: Sun May 03, 2009 3:16 am
Location: Earth
Callsign: B-BIRD, N127KY
Version: 2.12.1
OS: Windows Vista

Re: Random Buildings

Postby Rickbritto » Fri Apr 20, 2012 3:20 am

kyokoyama wrote in Fri Apr 20, 2012 12:35 am:Could it also be possible to arrange the layout of the buildings based on the actual OSM road layout? (i.e. -line each random building according to where and how the roads are laid out)


I'm working on a project that downloads a file with xml extension. osm this file contains information from cities like position of streets, sidewalks, height of buildings and building this type of map http://www.openstreetmap.org/

see the video below and you will better understand the process
[youtube]http://www.youtube.com/watch?v=Su0kdgOgd8E[/youtube]

I do not know if it is possible to aggregate into FlightGear.
Rickbritto
 
Posts: 21
Joined: Fri Feb 10, 2012 4:42 pm

Re: Random Buildings

Postby Thorsten » Fri Apr 20, 2012 7:28 am

I am thinking in terms of something similar to the cloud interface that you provided (where you added a new "add-cloud" fgcommand) - just with a focus on placing buildings instead of clouds. Making the placement algorithm accessible (or configurable) would be great.


We have that - it's called geo.place_model() or so. Any Nasal city-builder could start demonstrating how his subsystem works from there today.

The probem is that (as usual) people pull into different directions.

* Stuart has a 'random with certain moderately simple rules' algorithm with the aim to be as fast as possible without generating nonsense like overlapping or floating buildings. This probably means you can't have fancy night illumination, too much individual configuration or realistic arrangements beyond a point, and all placement info is encoded in the texture sheet (that's not a bad feature, because that means random buildings stay in sync with the underlying sheet!)

* Rickbritto has buildings pre-arranged in blocks. That idea isn't new per se (in fact it has been in 2.0.0) where village-like building arrangements were part of the random distribution. This looks great as long as it works, but as the buildings are more involved and individualized, it has larger impact on framerate. Moreover, blocks have other pitfalls: The center of the block needs to be inside an urban landclass, but the edges can be outside in random placement. This has led in the past to situations that when urban landclass was close to a runway, buildings ended up on the runway (!) which is a big 'no'. Likewise, when the urban landclass has a slope (San Francisco is just an obvious example), placing a whole block generated buildings floating and buildings vanishing in the ground if the block center is placed correctly. These problems mean that pre-arranged blocks are not suitable for us, blocks need to be arranged dynamically taking into account the actual terrain.

* 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). But such an algorithm has never been demonstrated to work or give good results, so it would be somewhat far-fetched to ask Stuart to make a faster Nasal interface than the existing one just because someone might eventually work on it. Also, it would probably be slower due to the heavy need to probe the terrain (which is much faster now than it used to be, but not so fast that we can allow wasteful use).

So despite all three techniques being designed to populate urban landclasses with buildings, they are not the same thing, they are actually very different, and there is not much overlap, neither in the models to be used nor on the algorithm side.

For this random code to work better cities should probably need a few land layers like centre, midtown, suburbs then the code would generate buildings with appropriate height.


But in more detailed scenery, that's all there.
Thorsten
 
Posts: 12490
Joined: Mon Nov 02, 2009 9:33 am

Re: Random Buildings

Postby Gijs » Fri Apr 20, 2012 8:58 am

kyokoyama wrote in Fri Apr 20, 2012 12:35 am:Could it also be possible to arrange the layout of the buildings based on the actual OSM road layout?

You can even do it so you have "real" building shapes. See for the work in progress: http://wiki.flightgear.org/OpenStreetMap_buildings, though these are no longer random ;-)

Stuart's method is excellent to get nice looking scenery for the entire word, including those places where there is no or poor OSM coverage. When there are roads in OSM, you can place those roads on FlightGear, leading to smaller patches of " city". I expect that automatically leads to some sort of " orientation".
Airports: EHAM, EHLE, KSFO
Aircraft: 747-400
User avatar
Gijs
Moderator
 
Posts: 9544
Joined: Tue Jul 03, 2007 3:55 pm
Location: Delft, the Netherlands
Callsign: PH-GYS
Version: Git
OS: Windows 10

Re: Random Buildings

Postby Hooray » Fri Apr 20, 2012 12:40 pm

@Thorsten:
Yikes, obviously I wasn't referring to geo.put_model(); :-)

Sorry, don't have time at the moment to respond in detail - but basically I agree with you.
Obviously, building cities dynamically isn't just about probing terrain (geodinfo) and placing 3D models (put_model) - additional information needs to be accessible (think road layers) and Stuart has come up with some really nifty scheme to keep this very efficient, much more so than simply instantiating hundreds of static 3D models.

So, yes - actually, I was thinking in terms of the cloud interface, because that's also much more efficient than doing "the same thing" from Nasal space via geodinfo() + geo.put_model().
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

Re: Random Buildings

Postby Hooray » Fri Apr 20, 2012 7:39 pm

7 hrs later:

Thorsten wrote:This probably means you can't have fancy night illumination, too much individual configuration or realistic arrangements beyond a point, and all placement info is encoded in the texture sheet (that's not a bad feature, because that means random buildings stay in sync with the underlying sheet!)


Regarding night time texturing, that could probably be addressed by using two different textures: one for daytime texturing, one for dawn/night time. As long as this is made configurable, so that two different textures are automatically used, it would be up to modelers to come up with a texture map for night time, it would just need to be based on the daytime texture, so that they match.

Thorsten wrote:These problems mean that pre-arranged blocks are not suitable for us, blocks need to be arranged dynamically taking into account the actual terrain.


I agree with this, it would be great to have a way to dynamically assemble buildings and blocks of buildings and then combine them into a single geometry, so that the performance hit is decreased. But that would obviously require exposing some more hooks to Nasal scripts. A while ago, we actually talked about using Nasal to create 3D models procedurally: viewtopic.php?f=5&t=10016&start=15#p101815

And that's also the approach taken by the PixelCity project:



So that would definitely be possible. From an interface point of view, one would need to extend the put_model() routines such that models can be loaded not just from the file system, but also directly from string contents in the property tree. That would make it possible to use a Nasal routine to come up with the 3D model, write it to a property and then instantiate/place the model in the scenery.

Now, what Stuart has done already addresses the needs in C++ space.
Adding a C++ interface to existing C++ is much easier that way, and certainly easier than creating the whole thing from scratch.

Thorsten 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.


Yes, that's basically correct: As you know, I am aware of geodinfo() and geo.put_model() being available to scripting space. However, in order to be able to procedurally create and instantiate 3D objects and textures in scripting space, a bunch of new hooks would need to be provided.

And then, like you correctly mentioned, better access to the placement heuristics, or rather the underlying criteria would be great. That's not just related to "materials" anymore, but also access to "ground networks", such as roads, rivers, railways.

A Nasal script that may query a scenery tile and get detailed information on these properties, could come up with the heuristics to place models realistically.
Coming up with the models procedurally would be a different matter.
But it seems, Stuart has addressed this already in OSG space. So the really difficult work has probably already been done.
Coming up with an interface to access his code from scripting space should be simpler than writing his code from scratch.


Thorsten wrote: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 don't disagree at all. But as can be seen by other related efforts (e.g. PixelCity) creating 3D geometry and textures procedurally is definitely possible. And Stuart's work seems to suggest that optimizing such models is indeed much simpler than just having a library of standard models and placing those.

The truth is, procedural content creation could even be done asynchronously - only the optimized and combined 3D model/textures would need to be passed to the main thread.


Thorsten wrote:But such an algorithm has never been demonstrated to work or give good results, so it would be somewhat far-fetched to ask Stuart to make a faster Nasal interface than the existing one just because someone might eventually work on it.


I agree again, but the idea was not to provide a faster interface, but just provide an interface to the new code (which happens to be faster), so that it's accessible from Nasal space. For example, Stuart's code creates buildings procedurally on a vertex-level, that's something which simply isn't currently possible otherwise. Imagine this were exposed to scripting space: You could create 3D models with configurable dimensions and apply custom textures.
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

Next

Return to Scenery

Who is online

Users browsing this forum: No registered users and 5 guests