1 / 24

Instant Architecture Presentation

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.

eboss
Download Presentation

Instant Architecture Presentation

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Instant ArchitecturePresentation By Alvaro J. Gutierrez

  2. 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

  3. 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).

  4. Proposed Uses • Urban Planning (traditional purpose). • Simulations • Traffic • Military • Driving • Information Visualization • Location-based Entertainment

  5. 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.

  6. 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

  7. 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.

  8. Example Derivation • White shapes represent non-terminals • Colored shapes represent terminals in the split grammar

  9. Example Derivation (contd.) • Full façade derived from derivation using terminals and non-terminals.

  10. Derivation • Non-stochastic derivation • Essentially random • Very chaotic

  11. 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.

  12. 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.

  13. Derivation (contd.) • Discrete derivation steps from a grammar. • Uses stochastic process. • Individual steps are colored in gray levels.

  14. Attribute Matching System

  15. 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.

  16. 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).

  17. Results • Terminal shapes (of the grammar) rendered as single boxes.

  18. Results (contd.) • The final generated buildings

  19. 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.

  20. High Variety of Buildings

  21. High Variety of Buildings (contd.)

  22. High Variety of Buildings (contd.)

  23. 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.

  24. 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

More Related