Future City: Update 11 - Block Interfacing

Progress on Future City has been slowed by web-site and release preparation work at the moment.  I've split my time about 2:2:1 between Web site, Future City, and Alpha Release preparations.

January push towards Web Site, City demo, and Alpha Release.

This split in attention as well as the pressure of the approaching alpha release means blog posts have been slower forming.  Let's just squeeze out a quick update on the Future City progress...

Future City

At the moment I've been focusing on the support of variable elevation across the city, with each city block having its own height.

Example of blocks with shared connectivity but height discontinuities

This feature results in rather complicated requirements at the interfaces between blocks as well as complicating the process of sub-dividing up the space within them.  As such, it's been quite slow progress working out (a) exactly what is required, (b) how to perform this, and (c) how to implement this.

Requirements

Based on the previous connectivity work which sub-divided the city up into districts/zones and finally blocks, we have already decided on what the connectivity between each block looks like.

Now we need to decide on what the content of the block should be such that it is possible to guarantee that adjacent, separately generated content aligns properly, functions as a seamless transition, and looks plausible.

Inputs

We have the following information about each block boundary:

• Block location/bounds/size.
• Access along each side (left/right of opening within any barrier present).
• Follow the underlying landscape shape, or both share flat ground level at a given height.
• Connectivity via each side (to the outer most city sides).
• Variation seed to drive arbitrary design decisions.

Outputs

From this we need to populate the block with rectangular sub regions.  The main problem we are trying to solve here is to transition from a boundary with zero, one, or two accessibility transitions along each side into spaces for content to go that all have single accessibility along each side, these being simpler requirements to satisfy.  Thus the outputs are of the form of Content Spaces with the following properties:

• Bounds size, orientation and location
• Surface height within the space (or if we are to follow the landscape)
• Is it an interfacing piece, i.e. responsible for handling transition to neighbouring block interface? (Edge - one interface along block boundary, Corner - two interfaces along block boundary, Side - three interfaces along block boundary)
• If not an interface, then an interior piece, with same type all round (flat or landscape)
• For each boundary interface: Specific flat elevation or landscape following. Do we 'own' this side (are responsible for interfacing geometry). Is this a barrier, i.e. will access be blocked? Is there a barrier to the left/right that we may need to provide transition geometry for?

Test Rig

Since there are a lot of combinations to test in forming this system it is worth generating a set of 'unit tests' with clear visualisation of the inputs and outputs.  By creating a hierarchy of test procedures we can quickly generate tests for all the major side and access combinations.

• Ownership - all, none, adjacent, opposite
• Surfaces - all landscape, all flat, mixture
• Access - Closed corners, all open, all closed (bar one), some on left, some narrow, mixture

Unit tests for a lot of the block interfacing cases

For cases where a specific issue is being resolved there is the option to switch out all but one test scenario.

Example test rig showing corner results produced

Algorithms

I spent a lot of time in Excel playing with block boundary examples and possible approaches.

Playing with block algorithm ideas in Excel

From this I've come up with a lot of ideas, but they seem to be heading towards this sequence of calculations:

First pass at the content space and interfacing algorithm

There are bound to be some changes as implementation proceeds, but this is a good starting point.

Lists

Structured Data

The amount of structured information and variability in generated output finally became too much and I had to stop to add some functionality to help support this.  Previously where several properties about a single thing needed to be conveyed through several procedures it had to be passed individually, and explicitly.  This leads to this specific flavour of spaghetti:

A specific flavour of spaghetti: arrays of connections

The algorithms that were forming to perform the interfacing and content-space generation were heading towards an awful lot of this.  From the requirement analysis above we can see each block has at least seven properties that go together, and each potential output content space has at least six.

Traditionally these would be encapsulated in structures, where a single type is used to express an explicit collection of typed data.  This is something that Apparance will natively support in the future, but it's quite a lot of work, especially on the tooling side where composition/decomposition of structures needs to be handled elegantly.

Variable Quantities

Another aspect of the block interfacing implementation problem is that there are several places where we need to pass a variable number of structures.  At the moment there is no concept of this and we would have to pass a fixed (maximum) number of structures (as individual properties) along with an additional flag expressing whether it was in use.  This forms a very, very unwieldy situation where all sorts of operations, such as combining two variable sized collections, become incredibly complicated, expensive and error prone.  We really need some form of list or array to handle this.

Solution

Both these prospects are really going to cause too much of a headache to work on the already complex problem, so we need support to help this.

Looking at other language for inspiration, we find that both these problems can be addressed by using lists of dynamically typed objects.  If a list happens to contain all the same type, then it is effectively a traditional list or array, i.e. a variable sized collection.  If a list happens to contain a fixed number, of different typed elements then it can be used as a structure.  Adding support for lists as just another base data-type to Apparance is fairly straight-forward and then means we can have lists of lists, or put another way, lists of structures.

Implementation

The List data type was added along with an initial set of basic operators to support what we would need, as follows:

• Append - take a list and add another element (any type).
• Get - index a list, returning the element value (any type).
• Set - replace a value at a specific index with a new value (any type).
• Count - query how many elements are in the list.

Part of the implementation that took a bit of effort was that I wanted type information to be maintained with them as the lists are constructed.  With this, a lot of validation can be performed during synthesis that would catch problems that would otherwise be very difficult to diagnose and have potential to crash the engine.

Whilst a bit tricky to implement, lists are proving very useful so far and make a lot of the block interfacing problem much more pleasant to work with.

Passing structures and collections around as lists

I am even now using them in the web site building procedures for all sorts of things.

Progress

I'm about half way through the Block Boundary -to- Content Space processing system and have promising results so far.

Some of the content space generation results so far

I'll post more results as I progress.  In the mean-time I have an Alpha Release to get out!

Future City: Update 10 - Progress Gallery

Not many words today, just a quick rundown of the new and improved aspects of the city.

Aerospace

A quick space-port/airport cobbled together from other city parts to just get rid of the last placeholder zones.

First pass aerospace district, the black will be landing areas for ships.

Parks

Time for some low level detailing, quickly knocked up and assembled a variety of simple small-scale park features; benches, bins, flowerbeds, huts, and a stepped plinth.  I even added a simple tree model that can be refined later.

Parks and recreation, now with 'furniture'

More green space in our cities

City Green Spaces

Plugging the park 'furniture' into the business district open spaces instantly improved the sense of scale.

Business district park areas, a nice spot for lunch

Adding a sense of scale to the large skyscrapers

Residential

My multi-celled apartment complexes and various street/terrace configurations lends to a nice residential area feel.

Residential areas, lots of apartments, terraces, and streets

Example street layout, with variable back-yard spaces

Detail Boost

Some time spent tweaking parameters and diagnosing detail problems has seen a nice boost in detail levels, meaning we can start to see the promise of the system even more.

Overview of various city zone types, now in even more detail

10 kilometres of city in view from on high

Next

Now I'm finally going to get on to height variation and simple terrain modelling for the surroundings and green areas of the city…

Future City: Update 9 - Apartment Construction

Apartments

I've been thinking about how to build interesting residential apartment buildings, that look more futuristic than just boxes with windows.  A few ideas come to mind:

• Surface objects  - balconies, air-con units, ducting, etc.
• Surface projections - bits that stick out, and in-turn have windows/etc.
• Multi-part buildings - intersecting parts in a cluster, at different heights.
• Non-right-angle intersections - should be do-able.
• Buildings on buildings - large rooftops can recursively have smaller/similar buildings on top.
• Styling - design seed can keep same style among a cluster but different between

We'll see how far this gets us.

Building Units

I started on the apartment buildings by properly subdividing a building block into obvious parts: windows, faces, friezes, separators, corners, parapets, roof, etc.

Procedure injection points on a general building structure.

This can later have a variety of proper alternatives and parts switched in and out to give them their final look.  I wanted the buildings to support intersection, so I added 'opening' parameters on each side, spending some time getting the various combinations of opening needed working.

Rig to test support for openings in the sides of buildings. 'Unit testing for procedures' in a way.

Two main ways to intersect building faces occurred to me:

1. Clipping - Intersect, working out where the join is and just filling each part with the usual facade (window grid, etc), making some changes to the edges to fit better.
2. Culling - Intersect, but this time just cull any windows that would become split where the join should bee (replacing them with basic wall).

Clipping has the limitation that you need to intersect at quantised positions otherwise the windows beside and above the intersecting building won't line up, but Culling means you will get areas with no windows.

I thought I'd try clipping first, and with some calculation I was able to get the intersection working.

The clipping approach in action.  Windows scale to fit space.

To support arbitrary angle intersections though the quantising requirement is going to be really hard to meet, so I also implemented the culling approach for comparison.

The culling approach in action.  Windows are removed when not enough space.

Seeing these in operation show's up the main pro's and con's.

The main differences between the clipping and culling approaches to building intersection.

On balance I think the culling approach will be less messy, especially with proper surface materials and objects.

Proper Facade

Switching the placeholder geometry for more interesting design produced some promising results:

Basic design variation examples

Next

 Now I need to look at arranging these together in interesting ways for use in the city:

• Generating building clusters to fill the city blocks.
• Populating the surfaces with proper features.
• Adding some LOD support for full city use.

Future City: Update 8 - A Mixed Bag

I haven't managed to write anything this last week (or two) due to other things going on in my life (shock!), and not really feeling like I've been focused on one particular thing.  Instead of a themed post let's just have a look through what's been going on.

Refinement Fixes

Spent some time tidying up the city a bit.  There are a few places where detail refinement was being blocked so I investigated those.

• Empty Stacker recursion procedure leaf nodes were not ignored.

Stacker Merge appears as leaf when no further content needed, but should be ignored as not a geometry producer itself.
(excuse low-res image, Cairo scaled it down because the GraphViz output was too large)

• Temporary general triangle fill added for rooftops didn't support refinement.

Roof triangle refinement - before and after

• Bolts had bounds that were too large, needed to be pre-shrunk.

Bolt bounds blocking refinement - additional re-size in procedure to fix

• Mesh primitive operators were not being counted as geometry producing (which broke the fix for the Stacker recursion issue above).

Post load checks to classify operators by whether they modify/produce geometry or not.

• Unnecessary deep refinement of surfaces meant a deluge of synthesis when you strayed very close to a surface. This was slowing things down a little so I added a limit check in the sub-division process.

Adding a refinement limit test, whilst also abstracting out the recursion check to make it more re-usable.

To help track down some of these I added a bit more error diagnostics information:

• Capture errors show in view panel for selected node
• Error filter slider for when too many to display at once
• Any bounds information in the error messages is visualised in red

Additional error diagnostics - better messages, error select, and bounds rendering

More Girders

Couldn't resist more girder improvements as this has become a bit of an 'extreme detail' test case.

• Washers under nuts
• Proper facets on bolts
• Threads on the bolts (hacky, but fine for now)

Washers, faceted nuts, and threads.

• Added cross bracing to girders
• Fillet pieces for cross bracing

Cross-bracing and attachment fillets

• Added rolling fillets to I-beam section
• Added welds to fillets and fixing plates

Welds and I-beam section forming fillets

All a bit excessive, but some good tests of the detail management refinement systems.  Several issues and bugs were surfaced from this work.

The Wilderness

To make the city more interesting, and provide more of a 'setting' for it I decided to surround it with a Rural district type.  Currently just green/grass, this breaks up the city tone and gives it a rounder appearance.

Rural district type now surrounds the city.

This will provide something to have as the backdrop, or vista, when height support is added and we can have hills and mountains in the background.

This was implemented by re-purposing the commercial district type and giving it a negative gradient along it's radius instead of a positive one like the central districts.  I also parameterised the location, sizes and weights of the district types so we get much greater city layout variance as we vary the city seed values.

Some parameterised city examples

Demo Planning

I'm aiming to have my first-pass city demo-able by the end of the year, and so far I feel like I'm on track for that.  I thought I'd better make a clearer plan though so I spent a morning breaking down the things I have left to do and thinking about the timings.  Here's the to-do list:

• Finish filling out the placeholder zones (1) - I really need to fill in the residential and leisure areas as they will lend a 'more human' aspect to the city (business and industrial so far).  I'm postponing commercial and spaceport as there are more important things to focus on.
• Implement first-pass landscape support (1) - A big thing this city doesn't have yet is elevation.  It was always something I wanted to do to add richness and interest to the city.  So we need support for a height function (of some sort), blending (to interface with flat parts), and placing of blocks on landscape (giving them the appropriate elevation).
• Height integration (1) - Once supported, the natural areas (leisure, surround, and business in-fill) and the interfaces between adjacent elevations need content to provide pleasant and realistic transitions.  This will need to take into account block boundaries, height, and importantly; access ways (or lack thereof) between blocks.
• Detail pass (2) - Another pass is needed to add more detail to the low-level city, that you will see when 'walking around' at street-level. This includes features like doors, windows, pavement, as well as assets such as bins, streetlights, benches, planters, and maybe trees.
• Navigation/viewing (1) - To demo this city properly I need people to be able to control the camera in the standalone player.  This would start with basic is keyboard/mouse (FPS) support, with controller support coming later, and then maybe an attract-mode camera mode if there is time.  This would be quite involved as it will need to 'explore' the city to find good camera positions and paths (for some definition of 'good').
• Lighting (4) - I'd really like to try out my lighting ideas, they should really bring the city alive.  This would also include some fogging/haze/sky work, and maybe some simple clouds for fun.
• Bonus: Transparency and reflection - If I get time or want a break for something more adventurous I'll try and get some transparency and reflection support in to allow water and glass effects to be added.

Timings (in brackets) are estimated weeks.  We'll see how it goes as I am already a little behind and am still due to have some time off.

Next

I need to get the residential parts populated as soon as I can, so I'll be looking at more 'house-like' buildings and how to create them.

Future City: Update 7 - Building a Better Skyscraper

Sorry for the late post, a few mad things going on at the moment.  One of which was the Rocketjump event in Bournemouth which @dannyt of @Moov2 invited me to, to showcase Apparance.  A lovely little event with some great speakers and games to see, where I got to show Apparance to a few more people.

Skyscrapers

Last week I decided that the stand-in skyscrapers were too dull and not nearly futuristic enough.

Temporary, non-futuristic, skyscrapers.

I was looking for things like these:

The sort of futuristic skyscrapers I was after
(Sources: source 1, source 2, source 3, source 4)

Spaceships

I knew I wanted interesting angular surfaces and chamfering so as a starting point I imported some old hull surface triangulation procedures I made for my spaceship construction experiments.

Ship hull built by connecting triangulated pieces.

The premise behind these is that we can build up large and interesting building hulls out of simpler parts that connect rectangular and angled edges together.  However we also want to make sure we can use shapes that map well to the frame construct used to model within.  Rectangular sections are easy, and right-angled triangles aren't too much of a stretch either.  In most of the cases I wanted these were sufficient to build interesting shapes.

Hull triangulation procedures

Cross Section

To limit the complexity of the models built I decided a cross-sectional form where each side can be in-set and corners chamfered independently would still provide sufficient flexibility to give interesting models.

Example of a skyscraper cross-section (two matching chamfered corners and an inset side)

This information is passed around encoded in Vector3's (like the connectivity information), one for each side, defined as follows:

Side inset/chamfer encoding for skyscraper cross-sections.

This will be used to describe the outline of the building at various elevations, with hull triangulation providing us with frames to build the surface geometry to fit.  The cross section will be mutated at random along the way to make the shape change and evolve as the evaluation proceeds skywards.  The changes we can make are:

1. Leave it the same - a straight vertical sided section
2. Chamfer any un-chamfered corners - introduce triangular sections.
3. Inset un-chamfered sides - introduce slopes and overhangs.
4. Remove any chamfered corners - return to square corners.

These can be applied in various combinations and quantities, some examples shown here:

Example cross-section mutations

The requirement for this building section triangulation exceeded the original hull construction primitives so I created a new one specifically for this, based on the various techniques employed before.

Diagnostics display for building section surface triangulation

Building It Up

By iteratively segmenting the skyscrapers into sections, potentially mutating the cross-section at each intersection we get all sorts of building shapes.

Example skyscraper shapes

Surface Noise

Initially I filled in the surface spaces with the general purpose smooth gradient rectangle and triangle procedures I had to hand.  These however had consistency problems at their edges.  Even though the sub-division they perform to add detail does maintain coherency internally between new triangles and rectangles, there was no way to maintain this between adjacent instances of the procedures.

Incoherent detailing, particularly noticeable on triangular sections.

A change of approach was needed to fix this; instead of choosing corner variations at random and then using midpoint noise to sub-divide, a simpler approach is turns out is to use the 3D noise distortion algorithm I was already using for landscape and wobbly building experiments.

Experiments with 3D noise mesh distortion

Adding an operator to do single samples in space for this allowed me to use the output to modulate the surface detail.  This had the advantage that the noise function was based in world space and so any two evaluations that happened to be at a coincident vertex, and hence the same position in space, would result in the same modulation effect.  This produced the effect I was after and improved the look of the buildings no-end.

Moving from a mid-point algorithm to world-space noise algorithm for surface detail sub-division.

Roof

A quick triangulation hack later and I had the geometry to cap off the buildings too.

Temporary roof tops for the skyscrapers

I will re-visit this later as it will be great to add intermediate roof pieces between building sections so we get stepped in parts and mid-level terracing.  This complicates the roof calculation though as we need to in-fill between two cross-sections, as well as potentially generating railing frames around the perimeters too.

Windows

For some extra finesse I also knocked up a 'window' filler for the rectangular sections, giving a much better sense of scale as you 'walk' around them. Oh, and I've been playing with grass for the plaza areas that break up the city space a bit.  Some level of success was obtained, more work to do on that though ;)

Simple surface window detail increases sense of scale

The City

These new buildings, with a bit more tweaking and polish give a very pleasing look to the business district and are far more in-keeping with the direction I was intending the city to go.

Business District, now with added futuristicness

Design choices can alternate up through sections

Bigger and better business buildings