240 likes | 254 Views
Instant Architecture Presentation. By Alvaro J. Gutierrez. Authors. Georgia Institute of Technology Peter Wonka William Ribarsky Vienna University of Technology Peter Wonka Michael Wimmer INRIA ( Institut National de Recherche en Informatique) François Sillion. Overview.
E N D
Instant ArchitecturePresentation By Alvaro J. Gutierrez
Authors • Georgia Institute of Technology • Peter Wonka • William Ribarsky • Vienna University of Technology • Peter Wonka • Michael Wimmer • INRIA (Institut National de Recherche en Informatique) • François Sillion
Overview • New method for generating building architecture. • Designed for individual buildings (more than for whole cities). • Automatic, via the use of split grammars. • Designed for versatility (wide range of buildings and styles) • Designed for flexibility (capable of being generic or accurate).
Proposed Uses • Urban Planning (traditional purpose). • Simulations • Traffic • Military • Driving • Information Visualization • Location-based Entertainment
Design Goals • High level of Detail • Start with generic (but high) detail. • Change to ‘realistic’ detail when data becomes available. • Resiliency • Use partial data when only available. • Fill in with full data to improve realism.
Design Goals (contd.) • Single database of grammar rules for all objects • Traditionally, different databases are kept. • Results in large database that needs to be handled carefully (see below). • Completely Automatic • Set initial design expectations • Use stochastic process to select rules • Use different types of grammars
Use of Grammars • Split Grammars (“simple”, but “powerful”) • Restricts the types of rules possible. • Possible to be automated, and controlled. • Control Grammars • Context-free grammar. • Not random (follows architectural principles). • Attribute Matching System • Lets the user set the high-level design goals.
Example Derivation • White shapes represent non-terminals • Colored shapes represent terminals in the split grammar
Example Derivation (contd.) • Full façade derived from derivation using terminals and non-terminals.
Derivation • Non-stochastic derivation • Essentially random • Very chaotic
Derivation (contd.) • 1. Split grammar searches the rule database for all rules that match the current shape. • 2. The attribute system is invoked to select a rule based on the attributes of the current shape and the candidate rules. • 3. Attributes are copied from the current shape to all shapes generated by the selected rule. • Therefore, attribute matching is inherited.
Derivation (contd.) • 4. Control grammar is invoked to distribute design ideas spatially. • Subject to the same attribute matching system as the split grammar. • Example: set the different attributes for the first floor of a building. • 5. The split grammar is invoked recursively on all shapes generated from the current rule.
Derivation (contd.) • Discrete derivation steps from a grammar. • Uses stochastic process. • Individual steps are colored in gray levels.
Attribute Matching System (contd.) • 6 possible window shapes to start with. • Shapes 4, 5 and 6 are excluded because they don’t match the attributes. • Shapes 1, 2 and 3 are left, unless another attribute is added that causes one to be excluded.
Detail Refinement • Use attributes to refine the kind of detail • Left: No attributes • Middle: Attributes “shop” and “color variation.” • Right: Additional attributes for vertical emphasis (first and last column) and horizontal emphasis (second and third floor).
Results • Terminal shapes (of the grammar) rendered as single boxes.
Results (contd.) • The final generated buildings
Results (contd.) • Created a example database from a grammar • 240 Rules • 40 Attributes • 10 Basic Shapes • 3 with split rules • Database creation took 2 weeks • Control grammar was used • Buildings generated: • Took 1-3 seconds (P4 2.0 Ghz machine). • Were comprised of 1,000-1,000,000 Polygons.
Issues • Complexity • Split grammars can be modified; however • Modifying an existing grammar is non-trivial. • Growth control • Difficult to target specific designs. • Large number of varying designs possible. • As the database grows, objects can grow into each other. • Not a big problem when modeling trees. • Problematic when modeling architecture. • No mention of user interaction.
Future Work • Interactive Editor • Manipulation of low-level detail through the grammars themselves. • Additional Rules • Merge Rules • More expressive rules • Use of images as training data • Photographs • Drawn Maps