City Generation

[Ramon]

Monster!

[Chris_TC]

I have now begun making rules based on Google street view images. This is a first rough building type. There are no proper ground floor and top floor rules yet (they are both crudely adapted from the middle floor rules, and I just noticed that the top floor height is wrong).
Of course everything is still completely procedural and adapts to building footprint, height and all the parameters that are specified.

[mattmos]

I'm amazed how quickly you've progressed. Its great seeing it develop!

[Rork]

indeed... massive steps instead of baby ones ;)

Chris, did you see the new videos on the SI Youtube channel about building creation in ICE? Are you following the same rules/setup, or are you on a different approach all together?

Interesting to see how you going to integrate this into the map to create city blocks

rob

[Chris_TC]

Chris, did you see the new videos on the SI Youtube channel about building creation in ICE? Are you following the same rules/setup, or are you on a different approach all together?

I did watch that, and what I'm doing is completely different. They pre-modeled three entire floors (or two floors and the roof). They then copy/paste these elements, which gives them control over how many floors there are. That's pretty much the only parameter they have for controlling the look of the building because the floors are pre-modeled.
I build all floors and its elements parametrically, which gives a huge number of possible combinations. It will soon become apparent how much control this gives, because I'll build a bunch of randomized buildings when all rules for this building style are done.

I must soon look into a texturing workflow because I think that every rule needs to pass on UV and material information for all its elements. And right now, I have no clue how to this because so far I've only done modeling in ICE. Hopefully the manual will help.

Interesting to see how you going to integrate this into the map to create city blocks

This should be pretty easy, I've already got the theory worked out. I'm a bit worried about the performance. It appears that my building generation is not properly multi-threaded and can take a while. Must see if I can speed things up. I might post the building compound for others to look at, since performance ought to be as fast as possible.

[Rork]

I have to admit I just grazed the videos to see what was going on ;-)
But they look nice as well though.

Regarding UV's, the Vimeo video's from Fabricio on his PowerExtrude tool might have some clues? Not sure though....

rob

[Chris_TC]

But they look nice as well though.

They look great indeed, but for a city you need more variation than number of floors* There are some excellent papers out there that describe the workflow of making random buildings for a city.

I must re-iterate that you don't need to be a programmer or mathematician to do these things. When I first read the papers I barely understood what they explained. But it's really not that hard if you build everything step by step, plugging nodes and trying things. You remember how I started out this process by making a silly L system that turns letters into other letters. My entire building generation is based on this exact compound. I don't need to think it through anymore because I know that the compound makes it all work.

*I appreciate those videos very much, ICE modeling has barely been covered yet in tutorials.

Regarding UV's, the Vimeo video's from Fabricio on his PowerExtrude tool might have some clues? Not sure though....

Thank you, will take a look.

[Chris_TC]

Same test building. But now it automatically generates UVs and materials for all elements.

[fabricio.chamon]

Pretty decent stuff, nice job Chris !! hope we can see this evolve into a final fully procedural city builder.

[claudevervoort]

That's really amazing Chris! I'm quite bluffed actually that you could actually pull that off in ICE alone and keep your sanity That got me reading a bit about L systems too. Really nice!

Claude

[Chris_TC]

I'm quite bluffed actually that you could actually pull that off in ICE alone and keep your sanity

Haha, frankly so am I. But it turns out that ICE works really well for this sort of stuff. I'm not using any crazy workarounds or hack jobs. ICE feels right at home with it all.
At the moment I'm doing a lot of reorganizing and restructuring. Not only have I been able to make the tree much smaller by using some different logic, but it's also much faster than originally. I'm working all of this stuff out before I start making more rules. This way I won't have to worry about it later.

I also want the workflow of adding rules to become as straightforward as possible.
The commercial product CityEngine uses a grammar called "CGA Shape". Users define rules through a syntax. For instance, to split a facade into a ground floor (height 3.5) and two upper floors (height 3.0), the syntax may be:

Code: Select all

FrontFacade -->     
    split(y){ 3.5 : Floor | 3 : Floor | 3 : Floor }

This removes the shape (FrontFacade) and replaces it by three shapes (Floor, Floor, Floor).

In ICE, split(y) is simply a compound with inputs for height/width and a checkbox to do vertical or horizontal splitting. When you "write" a rule, you just bring in all the shape compounds you need and define the inputs. You don't have to type numbers for those inputs of course. You can connect ICE tree logic to use relative values or whatever else you like.

[grahamef]

This is really great stuff.

Chris, I assume one of the papers you've looked at is http://www.vision.ee.ethz.ch/~pmueller/ ... ersion.pdf? If not, take a look. I'm not proposing implementation of a CGA Shape language parser in ICE, but it has a number of interesting ideas and references.

EDIT: We must have been posting at the same time -- I see that you're familiar with CGA Shape.

[Chris_TC]

Thank you Graham, this is indeed one of the papers I've read. I've got a whole collection on my hard drive now. The one thing I haven't looked at yet is procedural roof generation. But I've already downloaded some papers in anticipation

[dominikmk]

Really great stuff Chris, I'll follow your work on Procedural city for sure! We have just switched to si 2012 and i'm really a newby to ice modeling. Seam pretty solid!

Thx for sharing!

Doum

[Chris_TC]

Alright, I've finally got time to continue working on this. Nothing new to see at the moment, sorry.

I have a question regarding matrices, maybe somebody can help? For all building elements I am storing a 4x4 matrix that contains scaling, translation and rotation data (I use the "SRT to Matrix" node). Now I will need to store additional information for some elements, such as extrusion length, floor type etc. I would like to store all of this additional data in the same 4x4 matrix because that would keep things neat and clean.

It appears that the LAST COLUMN of this matrix always says 0,0,0,1 - regardless of what values I choose in the "SRT to Matrix". Am I right in assuming that I can simply use these 4 slots to store scalar data without EVER destroying the SRT info?

[grahamef]

I have a question regarding matrices, maybe somebody can help? For all building elements I am storing a 4x4 matrix that contains scaling, translation and rotation data (I use the "SRT to Matrix" node). Now I will need to store additional information for some elements, such as extrusion length, floor type etc. I would like to store all of this additional data in the same 4x4 matrix because that would keep things neat and clean.

It appears that the LAST COLUMN of this matrix always says 0,0,0,1 - regardless of what values I choose in the "SRT to Matrix". Am I right in assuming that I can simply use these 4 slots to store scalar data without EVER destroying the SRT info?

I suppose you could as long as you are very careful to set those values back before using the matrix as a transform in any way because once you change those values, the matrix no longer represents a valid transformation. However, I don't think that all the packing and unpacking of matrices that would be required is any more "neat and clean" than storing separate attributes -- quite the opposite in fact.