Some of the recent paper's I've browsed on procedural urban modelling and tangential subjects.
Detailed Building Facades ( doi | pdf | ieee | 2008 )Dieter Finkenzeller
This is a procedural system that uses two separate geometry trees, one for the course model and one for the style.
The course system starts with a floorplan - this comprises a concave set of abutting polygons that represents the main building, a wing or a balcony. Apparently the concave condition is required when generating the roof. These are combined using union operations.
A floor plan like this is created for each floor of the building. At each height the user has the option to add, remove or subdivide one of these polygons (to add a balcony for example)
Cornaces (decorative moulding strips) are extruded from a sequence of paths and curves. Consoles are blocks placed along the Cornaces, that you can stick arbitrary meshes (gargoyles!) onto. Cornaces-cross sections are defined use a turtle-like grammar. This is also used to define the perimeter of doors and windows.
Roofs are either flat, or constructed using a ridge-placing algorithm. The single, central ridge is defined, and each corner of the floorplan is connected to the nearest end of the roof. The straight skeleton is rejected as it is unique (not that I'm biased towards that skeleton or anything ;) however all the shapes described could be produced using the weighted straight skeleton, and it would have worked on concave shapes).
The second hierarchy of geometry is for the style, the finer components, such as wall subdivisons or windows/doors (
windoors) (I've visited this several times, and the abstracting is going to be quite useful, and can be extended to the general idea of a border/frame). The different components of the windoors are created by a multitude of cornice and frame elements.
After the entire semantic tree is produced, it is traversed by a geometry engine that creates polygonal output.
Inclined walls aren't supported, and a lot of use input is required to define the features of each floor of the building.
Affective scene generation ( pdf | doi | acm | 2006 )Carl Hultquist, James Gain, David Cairns
The idea here is to infer from adjectives, the parameters to a procedural system.
Merry et. al.
apparently couldn't get it to work (but didn't show any results), and there's a thesis by Polichroniadis (cl@cam.ac.uk) that describes a similar method for animation.
There are two massive spaces involved
- The descriptive space - a set of adjectives, one for each axis of the space, and a value for each axis.
- The model space - one axis for each parameter, and a value for each axis
The game is to find a mapping between these spaces. It's likely that the mapping is different from person to person.
The approach to solving this is via learning algorithms, in particular a neural network (of the radial basis network function variety - a one perception deep network).
The procedural world is generated using:
- Landscape: Perlin noise
- Trees: meshes
- Sky: Coloured based on time of day
- Clouds/Rain - Perlin noise clouds.
Current controlling adjectives are
wet, sparse, tropical, cloudy, light, mountainous and
undulating. Users are shown images and have to assign a real (0..1) value to each adjective for a set of test scenes. This trains up the neural network. This seems to work reasonably. There wasn't much more to this paper, except the results, above.
It's a afrigraph paper, and there's an interesting emphasis on technologies for developing nations with lower skill sets.
3d modeling for non-expert users with the castle construction kit v0. 5 ( pdf | vast | 2005 )Gerth, B, Berndt, R, Havemann, S, Fellner, D W
These guys build a nicely interactive castle editor. Particular emphasis is placed on the internal representations used.
- GML is a postscript like way of describing 3D models using a stack. It's a nice description because it's so flexible - functions can take an arbitrary number of inputs from the stack etc...
- Open Scene Graph is another scene graph engine, with a decent feature list - it represents geometry as number arrays etc...
The two packages were combined in the expected way - GML is used for the local descriptions, and fitted into the scene graph as components. There's a little munging of data types between the two packages, but they seem like a reasonable fit.
There's an reference to an excellent looking book about churches and cathederals by Kotch (
Baustilkunde : das Standardwerk zur europäischen Baukunst von der Antike bis zur Gegenwart). After recognising that castles are often on hills, they proceed to make castles on flat-ground.
Wall editing takes place via a set of handles (red things in the above images), one for each corner. The need for constrains on the handle positions is discussed - angles on walls shouldn't be too large, houses shouldn intersect walls (but be aligned to them) etc...
Out of context quote-of-the-day:
As it turns out a whole number of objects can be suitably represented by polygons.
Finally they say that they want to advance the work towards
non-flat terrains and castles. This is actually a remarkable uncluttered topic in the literature, and looks like a promising area of research.
Here's a
thesis talking about GML (in German).
The FL-system: a functional L-system for procedural geometric modeling ( pdf | doi | springer | 2005 )Jean-Eudes Marvie, Julien Perret, Kadi Bouatouch
The paper presents a variation on the theme of L-Systems and applies the result to architecture.
There are a couple of useful additions to the parameterized L-System
A(n) → for(i = 0; i <= n; i + +) B
Describes a repeated element. This replaces the decreasing-parameter trick used previously. It's only syntactic sugar, but given how twisted L-system grammars become it's quite welcome.
The terminals of the grammar are functions that can evaluate to geometrical primitives (window/door meshes). These can be modified by the parameters of the system at a given time.
The system outputs geometry at many grammar depths (rather than the tradditional post-evaluation using a turtle) . Because of the implicit evaluation order of L-Systems it's relatively simple to stop evaluation early to construct different levels of detail (LOD). These LODs are made more efficient by sharing geometry.
The system is integrated with the VRML97 standard, using embedded scripts.
An example grammar is constructed that creates a town house using standard façade decomposition techniques.
The above image shows a few result - the three buildings on the left are procedurally derived from the same grammar, with different texture sets.
The more I read about these system, the more I'm convinced that traditional formal grammars are very much the wrong way to go. There's no way artist's will use these grammars, and artist's can't be limited to domain specific languages.
Creating models of truss structures with optimization ( doi | pdf | acm | 2002 )Jeffrey Smith, Jessica Hodgins, Irving Oppenheim, Andrew Witkin,
The idea here is to construct truss structures (think Eiffel tower) by taking a set of contact points (above, left, cones) and load bearing points (above, left green balls) and finding an optimal (for some meaning of the word) mesh (above, left, green and brown mesh). The system is given an arbitrary set of input beams, and then iterates under user guidance to find an optimal solution.
Truss structures are meshes of connected beams designed to hold a certain load. They're used in bridges, towers etc... The fun thing here is that while physical constraints are used to converge on a solution, a physical model isn't the primary goal. Rather these guys aim for a graphically pleasing representation. There is a large body of engineering work given to engineering trusses dating from the early 1900's, using various forms of numerical optimizations.
The optimization starts with a "rich" (overly generous) set of beams (above - top, left shows how a generous configuration (left) is whittled down (middle) to an efficient structure, in this case mirroring the standard solution (right) in this case of a Michell truss). There a set of build in fudge constraints to specify beams above or below the load bearning nodes, or to constrain beams to a vertical plane.
The optmization uses a simple physical model of the forces involved, and work to minimize some function, typically the total weight of the structure. This constraints (apparently) make the problem non-linear, so the chosen solver is of the
sequential quadratic programming variety.
There are a misc. set of other constrains, such as obstical avoidence (above, bottom right, shows a truss holding the small green sphere, but avoiding the large red sphere in it's starting state (left) and two solutions (middle, right)), or max beam length.
After the system is solved, very short beams or those carrying no force are removed. The user then decides if the solution is viable, and the process is repeated until a desirable truss is produced. The results tend to look very similar to those of engineered trusses. In the case of some of their Eiffel tower models, almost too good to be true! - great results for a numerical solver.
