World Building [RELEASED] CityGen3D | Procedural city generation from map data

Ok great. I've added VerySmall terrain size option for 128 metre terrains ahead of next update, so let me know how you get on with that once it's out.

 

I don't know what problem will be solved with eightmap so I report mine.
-To avoid too bumpy road in big city, I set pic height at 0 and nadir at minus 1. I wanted to play only with modifiers to draw river ocean and other small modifiers.(I didn't manage to apply height modifiers if terrain was 0 for both)
After 2 hours I think, map came out but with 25 terrains flat. I had to select each terrain manually, apply height, then apply modifiers.
- Water generated has strange flickering, do you know the reason ? have strange flickering

 

Hi,

Thanks for your message.
The Peak and Nadir settings control the range of the terrain. Therefore the altitude of the terrain at any point will always be within this range. So I recommend having a bigger heightmap range than just 1 metre.

For example, you could have a Peak of 100 and Nadir to be -20 and still have the entire heightmap set to 0 height for a completely flat terrain.
It just gives you more flexibility if you change your mind later on and want to add water or a hill, you'll have that range to play with.
Without the range to increase or decrease terrain, you'll be stuck with what you have.

Please keep in mind that if you don't Apply Heightmap in CityGen3D, your terrain will be flat, but crucially it will all be at the lowest possible point within the range, not giving you any room for digging out terrain later on.
This is true of any Unity Terrain, but it's very easy to change using the Terrain Tools.

So if I wanted a flat terrain I'd do something like have a Peak of 100 and Nadir of 0 (giving me the flexibility if I need it).
I would then use the Flatten button on the Unity Terrain tools to set the height of terrain to something in-between these two values, so my flat terrain has room for both positive and negative adjustments later on (whether they be manual adjustments of terrain using the Unity tools, or automatic using CityGen3D modifiers.)



I wonder if the issue with the water you are seeing it linked to the shallow water and low range of heightmap.
If you still have problems with the water after resolving the heightmap issue please send me a video if possible so I can see exactly what's happening.

Please let me know if these tips help or if you need any further clarification.

 

thank you. This will be usefull with my next terrain.
The reason for flickering was another: in 2D map from openmap and from coastline there was a water shape and an ocean shape at same place. in 3D both plane were at same level.
I uncheck water shape and there is no more problem

 

I have another question. I seems the 2D map, even if not visible in camera and not containing collider has some physic as when moving to elevated highway I collide with invisible plan, then can drive above this plan.
If I desactivate in citygen3D folder all 2D map objects there is no more collision and no more invisible plan.
How at 2D map generation create 2D map higher or below sea level to avoid problem ?

 

Thank you for this information. Yes that makes a lot of sense, you would have been seeing z-fighting between the two meshes causing the flickering.
I will make a note of this and try to address this programmatically in future so that water meshes can't overlap.
As you found out, the workaround at the moment is to ensure there is no overlap of water objects on 2D map.​

 

I think that's fixable by ensuring the layers prefixed "Map" that relate to 2D map objects (eg "Map Road", "Map Surface", etc) can not collide with 3D physics objects in your scene by editing the Layer Collision Matrix.
This can be found via Project Settings->Physics in your project.
More info on the topic here: https://docs.unity3d.com/Manual/LayerBasedCollision.html

Thanks for bringing this up, this is a good tip to add to the documentation

 

I've got one small usability request. On the Data tab when navigating around with the map, I'm frequently working with a manually typed in lat/lon pair. Often I'll want to drag and reposition the map view, but then I'll forget and left-click and the pin/selection square will get repositioned, and I have to type in my values again. To make this easier and safer to use, would it be possible to add:
1) A little lock icon or a button or something to freeze the lat/lon at their current values, so that they can't be overwritten by an errant click and will stay fixed until you unlock them again. This is also important for my use case when doing multiple passes with the tile +1 arrows from a starting origin point
2) When I click Refresh Map, it would be nice if the map would refresh such that the centre of the refreshed map window is centred exactly on the pin. Or if that's not possible due to some other use case, then a second button to Recenter Map or something would be great. That would save a bit of hassle trying to pan/zoom things just right

 

Thanks for the feedback, both really good suggestions.
The location map does need a bit of work to remove some of the niggles with it after v1.0.
I'll definitely add these to my todo list, so hopefully it wont be long before you see improvements here.

 

Great. That'll be handy later on.

Do you think for 1.0 (or soon after) you will be able to provide HDRP/URP friendly shaders for the half dozen custom shaders you have, such as the water, details, and line markings ones?

Oh by the way before I forget, a tip for anyone doing coastlines: I was using mapshaper.org earlier to work on the coastline data, and the bounding steps can be done in the interface without the console commands referred to in the doco. First click the arrow and then "select features".



Now all you need to do is hold shift and drag with left-click over your area.


This will grab all the little islands and everything, and no need to muck about with magic numbers in the console. Then just click "keep" to save your selection, and export as normal. Hope that helps!

 

It's on my todo list to look into properly while v1.0 is in submission, so I should have a better idea of an ETA for the HDRP/URP shaders in a few weeks.
Certainly the plan is to have downloadable packages all setup for the newer SRP's so it can work "out of the box" for all pipelines as soon as possible.
How quickly it happens will be both based on user demand (relative to other features) and how complex a task it is. I imagine some shaders will be easier to port than others.
But I'll let you know when I have more concrete info to share on this.

Thanks for sharing your tips on MapShaper!

 

Just for fun, here's a little comparison overlapping GIF I made between a 3D textured GIS model I found for Melbourne Docklands and the CityGen3D produced version of the same area. I just used the default settings for a quick trial run on this one, so there's things like grass where pavement should be, most of which could no doubt be fixed by some layer tweaking, and of course the building footprint quality is dependent on the OSM quality. But all in all, it does a pretty decent job for a first cut scene, right?

 

This might be a minor bug to report. When editing building footprint nodes, using undo doesn't redraw the footprint correctly. If after the undo you then move another node (or add/remove one with NP+/NP-) then it'll redraw it accordingly; just the undo doesn't seem to do it. Also when zooming in or out on a footprint it can disappear from view at certain zoom levels, but that's probably normal Unity scene view clipping weirdness I would imagine.



^^ In the above example, I dragged a corner inside, and then did undo. The node snapped back to where it was just fine but you can see the gray outline hasn't redrawn.

 

Looks great!

Yeah the Land Surface is set to Grass by default on Location panel. This setting controls what surface is assigned where there is nothing specifically mapped in OSM, which you can change before Processing.

So in more heavily built up areas I often use a different surface type for Land Surface (eg Residential, or something else that maps to concrete). This ensures grass will only appear where it's specifically mapped in OSM for parkland and such like.

Whereas in less built up areas you want the opposite, where its best to assume grassland (or some other natural surface) for unmapped OSM areas, so only areas specifically mapped as Residential (etc) are paved over.

 

I've seen that undo bug, but had forgotten to note it down, so thanks for the reminder. I will address that as soon as possible.

Regarding zooming in and out of 2D Map View, you may be able to avoid unwanted near/far clipping by ensuring the Scene View is properly focused on the map. I find that pressing F Key while CityGen3D object is selected is a good way of resetting the near/far clip planes appropriately. At high zoom-in levels, you may instead want to select MapEntities child object and press F for better results. (Please let me know if these tips help, because if they do I'll add them to the documentation).

 

Quick API question: I am playing with a version of your CreateBuilding sample script that loads a bunch of polygons from a file I've read into a set of List<GeoCoord> points per polygon (building footprints in this case). The file however is for the whole city and I need to be able to crop the polygons processed to be only those within the current map's bounds. What call(s) might I be able to use to filter out only those within the desired range? I would assume there has to be one from the way you're processing OSM data within the range, but if there isn't an exposed method for that right now, then is there one where I can source the map bounds in GeoCoord min/max at least and crunch it myself?

EDIT: Never mind, I managed to roll my own in the end just by going through an intellisense hunt through the API.

 

There are clipping functions in CityGen3D but they aren't very easy to understand at the moment because there's no wrapper to simply take in a list of points.
I will tidy this up a bit in a future, but happy to hear you got something working yourself in the meantime.

I really appreciate your feedback with these API questions, because very few people have used CityGen3D in this way up to now, so it really helps me understand where the API needs specific attention to simplify it or make it clearer.

In the future I can see it being a really powerful part of the tool, so it's great to hear you making progress in using that side of it!

 

v0.94 is out now:

• Fixed height-mapping on multi-terrain environments.
  
  
• Improved Perlin Noise heightmap generation.
  
  
• Fixes for Generator interface on Location panel.
  
  
• Auto assign Data & Generator child object references when required.
  
  
• Removed Bing & MapQuest heightmap sources to focus future development on improving NASA SRTM integration.
  
  
• Very Small terrain size option for 128 metre terrains.
  
  
• Moved CreateBuilding example script so it's omitted from standalone builds.
  
  
• Fix for duplicate buildings at terrain edges.
  

 

Hi, just wanted to let you know that copying self-made objects on the 2D map (in my case houses) gives some errors when copying those created Gameobjects and changing the rotation.
[V0.93]

 

Thanks, I'm glad my feedback can help make the tool better in some small way.

At the moment, I've got my data reading in just fine and generating footprints for buildings from the government open data which is higher quality than OSM. I'm even grabbing the jetty footprints and have put those in as features, with the sleeper prefab used for them for now. Check it out: jetties!



For the buildings, I'm doing some basic type switching between the data source building/roof types and the OSM ones you've got hardcoded in the defaults, which I'll continue working on improving and adding my own blueprints for those. OSM is slightly better than the government set for that part at least, but as long as I can get the structures more or less correct then I can always manually rebuild the building with the right panels later.

The last major query I have for now is with the levels. On this map, there are a number of buildings with multiple tiers, i.e. overlapping polygons that represent a given tier where the building shape changes significantly enough. I can see that on the MapBuilding class there's .levels, .levelheight, .minlevel and .totalheight I can see in the inspector and get at via my script. However I have tried a few combinations of setting these and not yet figured out the right way to do it, as you can see from these floating monstrosities:


Could you please advise what's the relationship between these four level fields, and how I might arrange them to get the tiering to work. It seems like every time I set .minlevel higher than 0 it produces a weird result, but no doubt I'm missing something obvious.

 

It mostly seemed to work for me just now, although I did get this:
"transform.position assign attempt for '(Building)' is not valid. Input position is { NaN, NaN, NaN }."
on one occasion.
Is that the sort of error you saw too? (If not please post the errors you see)

 

Yeah its that Error
Therefore the buildings are set to their probable default rotations and not like that on the map.

 

Thanks for reporting this, I hadn't seen it until you mentioned it.
As you can see v0.94 is out now, but I should be able to drop a fix in for this in next update.

 

Nice work!
This OSM wiki page is quite helpful in understanding some of the terminology and it has a nice diagram: https://wiki.openstreetmap.org/wiki/Key:building:levels

CityGen3D parses the OSM data and infers a building height (and y-axis position) from one or more of these values, depending on what is set in the OSM database:

levels = how many floors in the building.
levelHeight = in metres how tall each level is.
minLevel = if building is touching the ground this will be 0, otherwise its the starting level number of the building.
totalHeight = the actual height in metres of the building.

Note that when it comes to generating 3D buildings, CityGen3D only looks at mapBuilding.GetHeight(), which is calculated from the above data (so it knows how tall the building is), and the minLevel setting so it knows where the y-axis position should be.
This because you are given flexibility in generation of floor height via the Blueprints, in that the building will just be filled up with levels as per the building rules and the actual 3D floor height is therefore controlled via Façade Size setting on each Blueprint.

Hope that helps, but let me know if I can clarify anything further, or you think something isn't working as intended.

 

Procedurally generated buildings are good for filling in a lot of buildings quickly but they obviously lack the detail of a handcrafted prefab building.

I've been thinking about how to blend the best of the two. Would be cool to have a database of a large number of different prefabs that could be inserted in place of a procedurally generated building.

There are good models for gas stations, fast food restaurants, etc. I was playing with reading the dimensions of the CityGen3D in C#. Maybe a way to put in dimensions for a prefab and a matching criteria. If the OSM building is between 45' to 60' x 90 to 120' and 2 stories and type = retail randomly replace with one of these 3 prefabs.

Or click a procedurally generated building and a dialog comes up that shows if any other prefabs would fit in place?

 

1. Try to speed up processing of OSM data.
2. Stop Unity 3D from popping up on the screen when generating buildings. I was watching a TV show on Amazon Prime Video.

 

Hmm, I am spot checking my test map and seeing some odd cases with the building generation. Some of these might be designed behaviour, but I thought I'd list them here in case it helps. I should add that these issues are present in the OSM data used by the base CityGen3D (0.94) and aren't related to the external data source stuff I've been tinkering with.

Case #1) Junk entities. These appear to be junk in OSM with either a zero area size or a very small size usually between 10 and 20. Judging by the points shown on the Map, some of these might be retaining walls incorrectly labelled in OSM - in fact I went on the OSM website and verified these by query feature. Example https://www.openstreetmap.org/way/711024218 looks like a retaining wall for a flowerbed, but is marked as building. In CityGen3D Map extract it shows as size 5.56 and 2 levels by default. Now when you Generate, an empty stub for this ID is created (with LOD Group component) but the stub has no corresponding roof/LOD meshes under them. I assume that under the hood CityGen3D has correctly detected (presumably by the area size) that this is junk and should not be meshed, however in that case I would suggest that the stub should not be present either.

One entity that got culled, however, was a sky bridge between two buildings from minlevel 9. That one I would have liked to see created.

Case #2) Buildings that do have a suitable point plot and area, but aren't getting picked up by Generate due to some off-map overlap threshold. These footprints and their MapBuilding level data and points look very similar to buildings that did work just fine. For example Shed 14 came through okay in this example, but Shed 9 right next to it did not, even though in OSM and the Map data they look almost identical.



I suspected that perhaps some of them were too close to the edge of the map, as the Shed 9 corner sticks out slightly more to the right and both were close to that edge. To test this I created a new scene with those two sheds right smack in the middle of the selection square, and presto the missing shed did then appear. It's not a huge problem, but it'd be nice if there was some way to know ahead of time which plots will get culled.

---

I'm not sure how feasible it'd be, but one suggestion I have for a way to mitigate these issues, is that on the MapBuilding (and other MapXXX) component, you might include a label in the inspector which shows the result of some sort of "pre-approving" of the entry. So if CityGen3D has determined through its formulas and weights that something looks like a junk retaining wall and should be culled, for example, the label might read "This building will not be generated due to its area size being below the threshold of X, meaning it is likely mislabelled data in OSM." or something like that. Even more powerful would be an override checkbox near the label which you could check to force the dodgy looking entity to get generated anyway, bypassing the checks manually (or alternatively, use the same toggle checkbox to switch OFF a dodgy entry that the formulas did let through).

Perhaps all of those checks are over in the Generate code and it would be too hard to add in such a feature to the Map scripts at this point in development, but I feel it'd definitely be useful to give users more visibility of what decisions CityGen3D Generator is making around the including or rejecting of various entries from Map, and also the ability to override those decisions to account for special cases, and let users choose to turn on/off which entries they want to see, with the understanding that they are then accountable for cleaning up the scene afterwards.

 

For sure, I think some specialized building types are more easily represented with prefabs.

But do keep in mind that the current implementation of procedural buildings is still on it's very first pass, there'll be lots more detail added later on such as chimneys, balconies, satellite dishes & air con units.
I also need to document the system so artists can create their own materials for the system more easily.

At the moment you can either have real world building shapes with procedural buildings (Buildings interface), or randomly distributed prefabs (via the Roadside interface).
What's missing is more easily being able to take real world building positions and assigning a prefab to that location based on building type/size.
I'll give this a bit more thought and try and come up with a suitable interface for it based on your suggestions.

 

Okay, after more tests, I do believe there might be some odd behaviour in the build/rebuild logic related to minlevel/levels/levelheight combination. Some of this may be expected behaviour that I'm misinterpreting, of course.

To reproduce: take a basic default building and set it to minLevel=0 and levels=40, accepting default levelHeight of 3 and generate or rebuild from blueprint. I counted the number of visible levels (i.e. windows and lines etc) and it wasn't 40 - at least not until I changed the default levelHeight from 3 to 5. So I'm not sure if that's a mistaken expectation on my part, but I would have thought each level would be distinct and stacked on top of other levels, and the levelHeight only changes how high in metres each floor of the building would be. Have I got that wrong?

Next try setting minLevel to 20 in the mapbuilding inspector and regenerate from blueprint. I would have thought it would basically shunt the building up, to be starting from where floor 20 used to be and now rising up by the 40 floors to where floor 60 would be. But instead it seems that .levels is the floor number to stop at rather than the count of levels, so the outcome is a 20 floor building starting at where floor 20 used to be. Maybe confusing field naming there? And again, that's only if levelHeight is 5. If it's the default of 3, then it becomes really wonky - the bottom floor (minlevel=20) comes up really high and the top floor (levels=40) is barely higher than that, leaving a squashed box:


from:



That's what was puzzling me about the behaviour, as I kept getting those squashed boxes from the data and couldn't work out how the fields hung together until you spelled it out. If .levels is actually "level to stop at" then ok, I can adjust to that, but as you can see from the example here, the levelHeight appears to be skewing the calculations somewhere in there for cases where minLevel is non-zero.

Anyway, hopefully that will give you some data that will be useful in tracking down whether or not there's a bug there, and if there isn't and it's just my misunderstanding, then please let me know.

 

1. There were fairly substantial processing optimizations made recently, so you should notice quite a big improvement in newer releases on areas with lots of buildings. Also remember to have as small coastline file as possible and to switch coastline processing off if in-land. I'll continue to look at further improvements in this area.
2. Possibly my favourite bug report so far. Sorry for ruining your programme! I'll see what I can do.

 

Once CityGen3D identifies a building from the key/value tags during Processing, it will attempt to generate that building in 3D.
The only reason it wont do that is if it can't find a matching rule on the Generator-Buildings window.
It looks at them in order to find a match. I suspect what you are seeing is it not finding a valid rule for the building type due to Size Range minimum setting.
(The default setup has the last building distribution rule at min size of 100. If you change that to 0, everything should show up, because all objects will fallback on that if none of the preceding rules create a match).

The empty gameobjects are created before it realises that its not going to build something.
I'll fix that up when I can so it removes redundant gameobjects.

I think it would be good to have some indication on 2D map about objects that don't currently pass any 3D generator requirements. I'll give that some more thought.


There was previously a bug where buildings that overlapped terrains would be duplicated for each terrain.
Now buildings are only generated on the terrain at which the building's position is calculated to be (average of all nodes). I think this explains what you saw there.
Thinking about this a bit more, confusion arises because they should also be omitted from the 2D map in these circumstances, so I'll address that.

 

Thanks for the feedback here. I'll run some tests and get back to you.

Edit:
Yes you are right in your analysis. minLevel should not be reducing the height of the building it should just be controlling its y-axis start position, and it seems the generator always stops adding to the building as if minLevel is 0 even when it isn't. I'll be putting a fix out for this fairly soon, hopefully in a few days.

The levels and levelHeight mapBuilding settings are purely used to calculate an actual height for the building in absence of an explicit height being set in the height field.
They don't have any direct bearing on the actual floor numbers and sizes because this is defined by Façade Size on a per Blueprint basis (which allows us to do things like have larger ground floor and smaller other floors in same building).
I will consider in this case whether its better to therefore just have two editable fields on MapBuildings: height and minHeight. (ie how tall is it, and where should it start on y-axis).

 

I went to Open Street Maps website and used "Query Features" on Hylan Blvd and found out that some sections are missing the "Lanes" tag. That is why some sections have 2 lanes instead of 4 lanes.

 

A few things that may help:

• You can change default number of lanes for different road types on Data-Roads panel (requires reprocessing of data)
• You can edit lane numbers yourself via the Inspector after clicking on a road instance (before generating in 3D)
• OpenStreetMap is free to edit, so if you have real world knowledge and are able to improve the map with additional detail you can change the actual OSM map itself to reflect this, then CityGen3D will get this updated data when you download the data.

 

Thank you for those explanations, that does help clarify much of what I wasn’t sure about. Now that I see how the facades work together with the levels/heights that should be enough that I can apply it to my supplementary data - and yes if you do decide to add explicit fields for setting height/min height that would be perfect as that is literally the exact format the data set I’m using comes in, and I can subsequently derive floor numbers via the facades after that.

 

Is there a standard way to have different types of buildings have different Land Surface materials?

If I select Grass for the Land Surface it looks good for residential houses but like the attached picture for commercial where instead of a parking lot it has a small road (due to how OSM draws it). Or it's the other way around. Maybe I can do this under Buildings/Construction? But it's unclear to me.

 

v0.95 should now be available with changes to Map Buildings so they are defined by height and start height as previously discussed.
The bug regarding 3D building height in situations where the building doesn't begin at ground level should now be fixed.

 

Land Surface setting is just to set a default in the absence of a mapped surface.
So if the 2D mapping from OSM doesn't differentiate between different areas to give you the detail you want, then you can manually plot a new surface on the 2D map using the Map Toolbar, and link this surface type to whatever terrain texture you want.

If you wanted to automate this by procedurally creating surfaces in script that cover an area around every building to pave it over, then that should be possible too. I'll see if I can give that a go once I'm in Asset Store submission, if you think that would be useful.

 

i have a question: Is it possible to create a group of four terrains, save the scene, save the scene under new name, delete the group of terrains, create new group of terrains, and repeat?

 

This is where I'm at now. I'm looking for turn lanes, lane markers, etc. CityGen3D is great for initial mockup but I'm trying to get as realistic looking as possible. I'm playing with the free version of EasyRoads3D. It seems they have an API but it's not documented yet. Has any work been done yet to integrate EasyRoads3D? I see they also import OSM. Maybe use CityGen3D for terrain, buildings, roadside entities and let EasyRoads3D handle the entire road network import and generation. Getting the overlay alignment might be tricky?

 

EasyRoads is a great tool and very well supported by Raoul. He recently commented on the status of OSM import as follows:

So you just have to bear in mind that complex real world intersections can require a bit of manual work and wont necessarily be automated. With CityGen3D you can draw any road combination in 2D (or get from OSM) and it will automatically create the road network.

Having said that, EasyRoads does things CityGen3D doesn't do yet like bridges. So as I say, I think a lot of projects will likely use a combination of the two assets depending on project/location specifics.

Let me know how you get on and if there's anything specific you'd like to see me add in CityGen3D to help with the workflow here, I'll see what I can do.

 

The crucial thing to remember is that if you want to use CityGen3D's built in scene streaming then each Landscape (Scene) should be named appropriately (as explained in the documentation), and this is done for you.
Other than that, you can really manage the terrain and scene generation how you want.

 

Thanks, that seems to fix the issue. I've still got some other issues with height placements on buildings with multiple tiers, but I am still investigating whether or not that's an issue with my data or not.

As far as when you're generating the buildings and placing Y height positions, does startHeight of 0 raycast to the terrain (with some fitting for the basement) or are you using datum information anywhere in the calculation? Just from observing the placements I would assume the former, but it would be good to know in case I need to do any reprojecting.

I've been keeping notes of other minor bits of feedback as I play around, so here they are in no particular order:

1) Roof type - currently only flat and hipped in enum. Will there be more types from OSM Key:roof:shape added later, such as gabled and so on?
2) Internal "roof" planes inside meshes - when I fly through the buildings, and sometimes from outside on certain angles (presumably due to normals), I can see where the floors all have a roof plane where the multiple floors presumably have been stitched together. Can these internal faces be culled to reduce polys/artifacts?
3) When I click Rebuild on a generated plot, it seems to place the start height differently (i.e. a floor or two higher) than Rebuild from Blueprint. Could you please explain why this behaviour varies?
4) I am seeing some weirdness with some of the blueprint created plots, with a dodgy floor or possibly basement placement. Here's one mesh - you can see the gap between the bottom of the facade and the lower plane:



and here I've moved it up in the scene so you can see the bottom plane has its normals facing downwards:


This may tie in with my earlier point about the internal floor/roof faces, I'm not sure. I wasn't able to identify a pattern for when this floor gap appears, as it doesn't always on every blueprint type.
5) Again on the topic of tiered heights and Rebuild/Rebuild from Blueprint. Here's an example of a two tier building. The first has a start/height pair of 0 and 62. The second has 62 and 3.5. As you can see, the second one digs into the first one somewhat:



If I click that second one and do a Rebuild though, it's fine, and the placement between tier 1 (still on from-blueprint build) and tier 2 (now on Rebuild button build) looks flush:



However if I then Rebuild the first tier, it will come off the ground (leaving a gap down there) and again cover most of the second tier again. This happened even if I turned off the create basement toggle and/or removed floor -1:



So again, this could be me misunderstanding how the Rebuild vs Rebuild from Blueprint is supposed to work, or it could be indicative of another height setting issue, I'm not sure. But hopefully I've given you enough info to be able to look into it.

6) I haven't yet started tinkering in depth with the Plot and Level components after buildings are generated, but one idea I've had from an API point of view is that I'd like to be able to write my own "post generator" scripts that could loop through all of these and apply particular changes I've stored, and then Rebuild that plot. In that regard it would be really useful to have as many fields as possible in Plot and Level exposed in those classes, and ideally to be able to have overrides for the Blueprint and Plan field values for that particular building's values respectively. Currently you can drag a new Plan facade into a Level and that's it, and the Plot has a select number of fields from Blueprint only. So there's a limit to what can be altered.

I'm thinking then, for example, maybe default as you're doing now but have an "override" checkbox or something, which takes a clone of the (Blueprint for Plot, and Plan for Level, I'm assuming) default values from those prefabs, but then lets an advanced user overtype all of the possible fields or pick new dropdown values which will apply instead. And to have that available in both the inspector and via public setters in Plot/Level would be ideal, as then users can tweak their buildings individually via inspector or script and not be tied to the predefined blueprints.

Lastly on that topic, at the moment, I see you have your Blueprint and Plan data as monobehaviours sitting on otherwise empty gameobject prefabs. Would scriptable objects be a tidier way of storing that data? Particularly if going down the path mentioned above, where Plot/Level could simply instantiate a copy of those scriptables if you need to override the values, and those clones would just show up in the inspector as a serialized field. Just a thought.

Anyway I guess that's all I've got for now. I'll keep making notes as I go and keep you posted. I have to say I'm really pleased with how flexible this asset has been in terms of being expandable to allow for other external data sets, and I think the way you've structured it has been really intelligently thought out. So well done!

EDIT one more minor UX thing I forgot to mention:
7) The new Generator button to do bulk steps all at once seems to be missing a small number of the available button options, for example the one for Apply Highway Leveling and Texture Custom Surfaces. There might be some others too.

 

For anyone who's interested in why I've been mucking about with external data sets, here's some comparison shots for my Melbourne Docklands test scene, between the building data available in OSM versus the building data in the government council open data I found versus a 3D textured model from the same council site.

OSM footprint data:



Council footprint data (note some differences in edge-of-map cutoff compared to previous image):


And to compare against the "real world" city view, here's a textured model from same council site generated from a point cloud (which obviously looks great from a distance like this, but up close quickly becomes inferior to proper meshes such as generated by CityGen3D, due to point cloud jagginess in the faces):



As far as the mesh generation goes, the differences should be self evident from these images. I'm not saying all OSM data is bad, but in my opinion it's certainly worth the time where possible to look for alternative data sources that may provide better accuracy.

My eventual goal with all this is to get decently shaped models generated by CityGen3D using my footprints instead of OSM's, and then manually go in and eyeball each building and assign the closest match to a suitable facade/blueprint texture set using the 3D model (and probably also Google StreetView, which I've also written scripts for aligning panorama rotations within the scene view) to tweak things and then Rebuild the building. The more of this I can automate, the less time I'll need to spend getting things perfect, and of course I'd only really spend time on the more iconic buildings and just leave the majority of less important ones to the generator. And as I mentioned earlier, I intend to write post-generation scripts to go in and automate a lot of other small details and decals beyond the point where CityGen3D generation stops. It's all great fun, worldbuilding with real world data!

 

Thanks for all the feedback on building generation, its very helpful.

Procedural buildings are vertically aligned against the highest point of the terrain underneath (or at least best guess from several samples). A startHeight over zero will just add an additional gap of said size.
If startHeight is zero, then an additional floor (basement) is also created to fill in any gap between the terrain and the bottom of the building.

Note that its deliberate for the lowest floor mesh (bottom of the building) to be facing downwards. This is so that if you travel underneath a building you can see a solid object looking up.
This screenshot demonstrates it quite nicely where a building with startHeight greater than zero creates an underpass next to two buildings aligned to terrain. (If its floor faced up it would be invisible and you'd see into the building).



However, I believe there is a bug with the Rebuild option which is currently under investigation, so it should be improved in next update.
The unwanted gaps and positioning issues you refer to may be all related to this bug, so I'll see what the state of play is once that's sorted.

I hope to add in more roof types during the update cycle.

I'll be adding more info to the manual regarding the Buildings module (re Blueprints/Plots, etc) over the coming weeks.

I will certainly consider your other points about organization of data and workflow for future changes.
(As I said the other day, the buildings module is still in its infancy at the moment and will see lots of improvements in the future, so having an understanding of how people want to use the tool is really good for shaping future development).

 

Another possible bug report. I've encountered some odd behaviour with some of the building meshes. Here's a capture so you can see the building flickering in/out of view:



It only seems to occur at certain distances and not on every mesh either.

I have eliminated the following as not being the cause:
- Doesn't seem to be the normals of the mesh, or other mappings - I exported to Blender and checked and they look fine
- It's not the camera far/near settings as I ensured these were appropriate
- LOD group appears to be configured as it should, however this might still be implicated.

So finally I swapped out the Facade and FacadeSimple shaders on the relevant mats for Standard just to check, and that did seem to resolve it. I couldn't see any obvious errors in the .shader code calcs, although I'm pretty terrible at reading that stuff, but it's possible the issue might be in there, perhaps in the tesselation?

 

This seems to be an issue with the frustum culling in the tessellation shader.
I'm not entirely sure why it's happening at the moment, but I suspect it may be linked to mesh bounds on buildings not generated via OSM.

So please can you confirm whether it's happening on procedural buildings generated from OSM data as well, or whether this is only happening to buildings generated using a new building added on the 2D map (or via scripting)?

 

All right, I’ll run some tests when I get my computer back from my lad and let you know. Your theory does make sense to be the likely culprit, particularly since the issue hadn’t shown up before. Maybe the OSM bounds have some geo datum assumptions baked into them or something.

 

Thanks. When I implemented custom buildings I tried to fix it so the pivot point of the building was local to the building and not always at [0,0,0] in world space. (This makes it easier to copy/move/rotate the building).
But I never got round to applying that change to the OSM generated buildings.
So there's likely something amiss with that new functionality there, causing the shader to misinterpret the mesh bounds, which I can look into.

 

Okay, I can confirm that the issue does not happen with the regular buildings generated from OSM, only to ones added via script using the API or manually drawn using your visual node tool in the editor. And yes the main difference seems to be the pivot point is more locally positioned for the custom ones, while still at zero for the OSM ones, so your theory looks pretty promising.

By the way, as I was prepping the test, I decided to do a lightmap bake as well, and discovered that the CityGen3D game object created by the Data tab is set to static and so all of its children created when you process the map are as well. This caused the bake to be considerably costlier as it's going through all of those 2D objects from the Map view and doing lightmaps for those. Is there a requirement for why that object has to be static, or can it be turned off when you generate it in the hierarchy - for the baking static at least, if not entirely. I only noticed it now because I don't bake often and I usually disable the CityGen3D object when I go into play mode, so it surprised me why it was taking longer than usual.