Thoughts

Purpose of this Work

Define an algorithm or a framework for procedural building of 3-dimensional voxel architectural structures, such that:

• Structures can have clearly defined style, e.g. consistent usage of certain elements (columns, long corridors, parapets etc), building materials (cobblesone, sandstone etc) and geometrical shapes (square arches, round arches, protruding roof etc);
• Structures have multiple floors, which can be connected with rooms several floors tall;
• Structures analyze and make use of underlying terrain, e.g. a castle can have towers on mountain peaks, bridges over ravines or uneven rough ground.
• Buildings can have complex corridor systems.[?]

The program can be used for procedural building in many applications, especially recreational ones such as Minecraft and its clones.

TODO: explain the concept of voxel used in this work, how it is related to voxels in general and blocks of minecraft. Perhaps replace the word "voxel" with "block".

Implementation Notes

Formal grammars could be useful in generating such structures. The architecture of the program should be general enough to allow specific implementations to define the format in which to store the voxel data and paste it into actual voxel worlds. The Bridge pattern could help make the program abstract from implementations.

Decomposition of Buildings

Let's assume that architectural structures generally consist of 3-dimensional regions of space which have physical or imaginary walls between them. Consider an orthodox catholic cathedral: it has a large cross-shaped hall, and along its perimeter columns are placed at regular intervals, separating the main hall from the galleries. There are 2 clearly outlined areas of interest here. Let's call them "domains". Often inside a cathedral near the altar or a grand cross there are boundaries usually in the form of little fences, i.e. separated domains within a larger domain. Almost always such domains will have a strictly horizontal floor and vertical walls. Furthermore, they often have rectangular shape. To simplify the decomposition, let us assume that separated domains are always rectangular boxes. In fact, the aforementioned cross domain can be easily separated into 5 box-shaped domains (the center and four wings). This assumption allows us to easily procedurally generate a framework of a building as a hierarchy of boxes within boxes. On the highest level boxes could represent whole buldings within a temple complex; on the lowest, parts of a room segregated by their intended purpose of use. As far as architecture is concerned, a box has a floor, a ceiling and four walls. Walls usually have the same appearance, but sometimes they differ, e.g. if the room serves as an intermediate chamber between rooms of different size and level of significance. Our domains too have physical or imaginary walls. To give an example of the latter, a colonnade is not a wall in the strict sense of the word, and our imaginary subdivision of the main cross-shaped hall of the cathedral creates imaginary walls as well. It is quite logical for domains-within-domains to have transparent or non-existent walls, as it makes it possible to visually identify the larger room, and at the same time adds a lot of interesting detail to its inner structure. Walls between domains on the same level of hierarchy are usually solid, e.g. apartments stemming from the same corridor or detached buildings in a temple complex.

Notice how walls between rooms may be rather thin and have minutely detailed decorations, while outer walls of the building are usually much more massive, with larger features. Also notice how a building usually has a distinct style of wall decorations within itself, a style that can be different from neighboring buildings of a large complex. This leads us to the idea that architectural style of walls has its own hierarchy that in some way mirrors the hierarchy of the building, i.e. the order in which the "boxes" are nested. It also resembles CSS and may even have some concept of cascading.

Aesthetically pleasing buildings are often exhibit mirror symmetry, e.g. in the way larger domains are subdivided into smaller domains within. This feature should be utilized by the algorithm.

So far we've only considered rectangular boxes. Obviously[?] it would make for a much easier algorithm to have the boxes aligned to the coordinate axes. However, this imposes a limit on the architectural design, making the structures singificantly more "blocky". Perhaps this limitation can be lifted. Consider a domain that has floor in the shape of an arbitrary convex 2D polygon and has strictly vertical walls of equal height. Such elementary structure can be modeled fairly easily as a collection of vertices and walls between them. Then we could have the same rectangular boxes, but rotated around the vertical axis. A question arises however: how do we connect a rectangular corridor that has been rotated at a non-right angle to a wall of a room? The solution certainly requires a way to cull the segment of the corridor that partially intersects with the room due to rotation. This problem can be solved for the general case of intersecting convex polygons.

Also at the point where 2 walls connect some corner-defining decoration may be required.

When generating a gate between domains, it might be necessary to create a hole in a solid wall for passage; other parts of the wall should not be touched.

Structure of the Program

Infrastructure so far:

• Utility classes for working with vectors and transformation matrices, all of them unit-tested.
• Interfaces for block storage of fixed or inifinite size (i.e. a Minecraft world); some implementaions, most of them unit-tested.
• Data structure for storing block information: block id, metadata and rotation.
• Abstract arcitectural plan consisting of nodes such as Room, Corridor. At the time of actual generation of the structure in blocks they should be separated into elementary primitves, i.e. walls, floor and ceiling -* Interfaces that define aspects of architectural style: general geometry of nodes, shapes of elementary nodes and bulding materials. This part was designed with grid alignment in mind, which is now considered a limitation. To be amended.
• Position transfromer that acts similarly to OpenGL view-model matrix. It encapsulates a block storage to make placing blocks at arbitrary offset and angle easier.

Node origin point should use fractional coordinates, because it would be impossible to centralize corridors that are odd number of blocks wide.