Following one man's task of building a virtual world from the comfort of his pajamas. Discusses Procedural Terrain, Vegetation and Architecture generation. Also OpenCL, Voxels and Computer Graphics in general.

Friday, August 17, 2012

Here is another series of screenshots. These are also from the Canyon City grammar.

I really need to improve the lighting in this preview. I normally export the final mesh to 3ds max and render it with nice global illumination. The meshes I get out of this are so large 3ds max cannot deal with them anymore.

The mesh complexity is a problem only at this stage of the grammar edition. Once this is voxelized and optimized back to polygons, it will be fast enough even for realtime rendering.

Over the weekend I will see if I can load this into 3ds max to produce better previews and share them with you.

Tuesday, August 14, 2012

In the past few days I have been writing a grammar for a massive structure. It is some sort of water collector for desert areas. It is so big that there are buildings on top of it and acts as the center of a small, parasitic city.

I did a couple of concept sketches for it. This was painted with my fingertips on an iPad (using the Paper app). Don't expect too much detail here:

The grammars for this structure are not difficult, but there are a lot of special cases. Since it is taking so long, I thought it would be nice to post some partial progress.

Here is a preview of what I have so far. The screenshots are taken straight from Voxel Studio.

This is a teaser so I won't be showing much. You cannot fully appreciate the scale here, but this thing is so large it will have an entire forest under the main dome. The towers, which are for cooling, are hundreds of meters high.

I am building this so I can finally show all elements of the procedural world coming together.

Friday, August 10, 2012

Architecture L-Systems deal with fairly simple shapes: boxes, tubes, cylinders, prisms, some times loft and revolution operations. They define the bounding volumes where you can instance actual geometry samples, like columns, windows, doors, bricks and tiles.

These basic shapes alone can get you far. The problem arises when you need these constructs to intersect each other. In most cases they produce complex shapes for which we don't even have names, let alone a unique mathematical formula. For instance, you can create a nice dome by doing a loft operation on a tube or a cylinder. Now, if you needed to blend two domes, you would be facing an increasingly difficult problem.

In other fields this is usually solved by "Constructive Solid Geometry" (CSG), which is about combining multiple shapes into bigger or smaller shapes by subtraction, addition, intersection and other similar operations. The problem with CSG is that it outputs a soup of triangles. The little boxes, cylinders, prisms we used to have disappear in this soup. This matters a lot for architecture grammars. The rules you write are designed for these basic elements, not flat triangles.

I encountered this problem while building grammars for a Mosque. The base of the building is square, the top of the building is a dome which has a circular base. There is some kind of roof that transitions from the square into the circle. This is an element also found in Roman and Byzantine buildings.

In the next image you can see a red arrow pointing to it:

If you isolate this element, this is how it looks like:

It is some kind of curved square with a round hole in it. Not only this element is special. The side walls of the square base must be properly cut so it fits. Here you can see them:

These images, as usual, are the output of my architecture system. Which means these shapes entirely possible. They are quite easy to produce as well.

The trick again is in the occlusion rules. This time they can be combined with the recursive nature of L-Systems to great advantage.

The starting point is to define these shapes ignoring the weird cuts we will make later. This is what you get from a square base and a cone-shaped tube, both basic shapes:

Here comes the first trick. In reality, these shapes are made of smaller ones. I have reduced them just so you can see:

Using occlusion rules, we can hide the elements that are outside the box and above the roof. This produces a very coarse approximation to the shape we want:

Now comes the really important bit. The elements that are completely occluded will remain hidden, but those elements that are partially occluded we will subdivide them into smaller elements instead of just hiding them.

This produces a new set of elements. To this set we apply the same rule as before. Some will be entirely visible, some will be entirely occluded and some will be partially occluded. Once again, those that are partially occluded will be subdivided into a smaller set. Eventually the elements will be small to a point where it is not practical to subdivide again. This is where the process ends.

Here you can see the output of this method. Note that all the elements are boxes:

Obviously the cuts are not completely smooth. You still get these microscopic boxes. In my case this is not a problem at all. These volumes are sent to a voxelization phase. The tiny boxes are smaller than the voxel resolution so they are blended into straight features which later optimize very well.

I thought this was a nice technique. For sure you could use it to produce really bizarre objects. We may see some of that later.