Saturday, March 26, 2011

Seriously, Google, seriously

I apologize for going off-topic, but I find this rather amusing.

It seems Google's AdSense cannot figure out what this blog is about. For a long time now it has been showing ads about real-life construction, churches, Christmas trees, family trees, prune your trees. I just took this screenshot:


The funny thing is Google has all the information it needs to discover what the people who read this page care about. It seems they are just matching words and hoping for the best. If they were paying attention to the comments, all the posts, the links, they could figure it out. This blog is also hosted by Blogger, which is owned by Google. They could make sure there is good metadata for their engine to discover. There are even tags to associated to each post.

They say their algorithm is intelligent. I agree, only it is same level of intelligence that allows a dog chase its own tail for hours.

Saturday, March 19, 2011

Writing Architecture

If you were the last person in the world, would you build a parser?

It is only me using this engine at this point. There is no UI for any of the things you can define for the virtual world. Not even configuration files, XML, INI, etc. It is all a  big soup of C++ code. To me it is the same to change a value in a C++ file than to edit a configuration file.

Then I started working on the architecture L-System. Soon I realized that writing grammars in C++ was not very good. They were extremely verbose and hard to read. It would be better if the grammar was written in a language designed just for that. For the first time in this project, I started considering parsing from an external file.

Luckily I remembered an old trick. I saw it long time it in ancient UI systems to define menu structures. The trick is to define functions that always return the state you are building, so you can chain their calls.

For instance, you can have a construct like:

begin("house").
divide_y("80% 20%", "living_area roof").
end();

It is really three functions being chained one after the other, but it looks like an structured construct. The "begin" function returns a new rule object with the specified name, in this case "house". Then the "divide_y" function is called in the rule to specify a house will be divided in two spaces, the living area and the roof. The function also returns the rule, so if we wanted to add more instructions we could do it right there. Then the "end" function returns the grammar object so a new rule can begin.

It is quite simple to use, the grammars are easy to read and you get all the help from the C++ compiler. Even the intellisense kicks in and gives you hints about function signatures. Also it allows to move into a different format in the future, even a dynamic UI. What changes is how the grammar objects are created, nothing more.

Just so you get a feeling of the written grammars, I leave you with the rules that define the church of my earlier screenshots. This is just the main module for the church. It references other modules that I did not include here. In a future post I will explain what these functions actually do.


begin("church").


// main space
push().
occludes().
center().
scale("90%", "100%", "70%").
box().
select("face_x", "nave_walls").
select("face_z", "nave_facade").
push().
move("0", "100%", "0").
loft_box("80%", "100%", "0%").
select("face_x", "thin_wall").
pop().
pop().


// transept
push().
move("10%", "0", "0").
push().
occludes().
center().
rotate_y("90").
scale("70%", "100%", "50%").
box().
select("face_x", "transept_walls").
select("face_z", "transept_facade").
push().
move("0", "100%", "0").
loft_box("80%", "100%", "0%").
select("sides", "thin_wall").
select("prism_sides", "prism_cap").
pop().
pop().
pop().


// towers
push().
move("0", "0", "100%").
push().
scale("tower_width", "300%", "tower_depth").
move("0", "0", "-50%").
module("tower").
pop().
pop().


push().
push().
scale("tower_width", "300%", "tower_depth").
module("left_tower").
move("0", "0", "-50%").
pop().
pop().


// apse
push().
move("20%", "0", "0").
push().
occludes().
center().
scale("130%", "100%", "130%").
ngon("18").
select("sides", "nave_wall").
push().
occludes().
move("0", "100%", "0").
move("0", "0.5", "0").
loft_ngon("18", "100%", "0%").
select("sides", "thin_wall").
select("prism_sides", "prism_cap").
pop().
pop().
pop().
end().

Monday, March 14, 2011

Little Blue House on the Prairie

This post will introduce the L-System I used for the architecture generation. My system is still far from complete. While it is fairly good at producing the outside of many different types of buildings, it does very little about what is inside. That is the big next step for me.

If you remember an earlier post, an L-System was a set of rules that described how one thing could be replaced by other things, which in turn are replaced again and so on. This resulted in fairly complex structures which went beyond the apparent simplicity of the individual rules.

L-Systems are often associated with trees and botany, but they really apply to anything showing any sort of structure. For instance you may say any book is a series of chapters, each chapter is a series of paragraphs, each paragraph is a series of sentences, each sentence a series of words, each word a series of characters. If you were to write these as rules it could be something like:

Book = repeat(Chapter)
Chapter = repeat(Paragraph)
Paragraph = repeat(Sentence)
Sentence = repeat(Word)
Words = repeat(Character)

Then a Character would be just one instance of multiple choices:

Character = instance("A"..."Z")

Of course there are other rules at play. The structure of the sentence includes other symbols like spaces between words, there should be titles for chapters, etc. Our basic set of rules could be extended to:

Chapter = Title + BlankLine + repeat(Paragraph + BlankLine)

Sentence = repeat(Word + Space)
Title = Sentence
Space = instance(" ")
BlankLine = instance("\n")

You will see that these rules use two special commands: "repeat" and "instance". What they do should be evident by now. Repeat can be extended so it will include a minimum and maximum number of repetitions. That way you can hardwire some boundaries into the rules so for instance words and paragraphs will contain a natural number of elements.

What if we want to have a table of contents at the beginning? A new command could be helpful: "split". The book rule could be rewritten like this:

Book = split(TableOfContents, Contents)
Contents = repeat(Chapter)

In most books the words and sentences actually make sense. We will ignore that for now. Note that given enough time and processing power, even this simple system will inevitably produce Tolstoy's War and Peace. It deserves some respect already.

But this accomplishes only one half of the task. So far what we've got is the "definition" of a book. Somehow these rules need to be expressed into something you can read.

The expression algorithm would execute the "instance" commands and produce something tangible. It could be very simple: just output the character to screen.

Any L-System will show the same dichotomy. One side of it deals with the representation of the rules while the other side deals with their manifestation. It actually helps to keep both sides as independent as possible. In the book example, you may later devise very nice and ingenious ways to visualize the book, or maybe read it aloud. This would affect only they way the instances are expressed, but would have little to do on how books are represented or even generated.

Now let's say you want to adapt this system to produce architecture. Instinctively you may say that a building is a series of spaces, each space is delimited by a series of walls, a wall is a series of elements like doors, windows, ledges, ornaments. Will it work?

It may seem simplistic at first, the trick lays in the definition of "space". A very simple house can be defined by two main spaces: a box for the house and a prism for the roof:
So the simple house rule could be something like this:

SimpleHouse = split(Box, Prism)

Then for each space, we could target each one of its faces. We can choose to replace each face in the box by a new rule that we will call "WindowedWall":

Box = split_faces(WindowedWall)

Note there is a new command here: "split_faces". This is like split, but it will operate on the faces of the volume. This is a very powerful operation, it is what allows the rules to move from the generic spaces and start targeting the different facades of a building.

Then WindowedWall can be defined as a repetition of windows:

WindowedWall = repeat(Window)

The "repeat" command will fit as many windows as possible in this space. It will look like this:
The split_faces command could assign a different rule to different faces in the current volume. This way one of the faces could become the entrance of the house:

Box = split_faces(
  Entrance, 
  WindowedWall, 
  WindowedWall, 
  WindowedWall)

Entrance = split(WindowedWall, Door, WindowedWall)

So our little house would get a door:
What about a roof? For that we would need to select the faces in the top prism:

Prism = split_faces(Roof)

Actually by providing several rules to the prism split, we could add a chimney and a little attic window too:

Prism = split_faces(RoofWithChimney, Attic, Roof, Attic)
So far you may be thinking this can only produce the same house. Well, depending on the initial sizes of the box and prism you will get a different number of windows. The door may be placed at a different position on each case. Then you may have different angles in for the roof.

But you are right, there is little room for variation here. The L-System becomes very powerful when you add randomness to it. For instance, you could either choose to have a chimney, no chimney or a UFO landing pad:


This is probably enough for an introduction. The system I'm using is actually a lot more complex and I intend to cover it in future posts. Still it is based on the principles described here.

For additional reading, I really recommend: Procedural Modelling of Buildings