Wild Physics: Design on the Outskirts of Town  --  Brian Boigon

Full Citation and Summary Boigon, Brian. `Wild Physics: Design on the Outskirts
of Town'. Log, no. 26, Fall 2012, pp. 77 - 85.


This article, published in Log 26 alongside articles surrounding the themes of
science fiction and virtuality in architecture, explores the potential of game
engines as architectural design tools. Boigon expands upon previous trends in
digital design which stress the simulation of physicality in the design process
(ie. BIM), the appropriation of animation techniques for architecture, and the
necessity for architecture to grapple with the flatlining of digital and
physical spaces.

Notes
- Brian argues for the necessity of "architectural engines" as a means of
 dealing with the "incoherence of living in the randomness of day-to-day (pp.
 77)
- Stresses that these engines shouldn't be thought of as technically superior
 but rather form their own design world or environment (pp. 78)
- Game engines come with their own simulations of the physical world, "Wild
 Physics" (pp. 77)
- "Wild Physics" = a wild version of the logic of the world which regulates the
 relation btwn game objects
- Come with a set of "middleware" which regulates the relation btwn the engine
 and its components (physics engines, rendering engines, etc.)
- Current design software is too stiff to respond to the physical world (pp.
 78)
- No "tactility," modelling happens through a layer of software procedures and
 routines
- "In the time it takes to change a vector coordinate and then extrude it
 through a twisted extraction, the game-scape is riddled with the digital
 debris..."
- "...are alas unable to mimic such a random reality and instead become
 systematically routinized by the very tools that make it look easy to craft a
 form..."
- Outlines the "gamer's reality" (pp. 79)
 1) The "game tag" (address of the digital proxy, one that is "anonymous"
 through the choice of tag)
 2) The wireless headset (vocal-aural interface with the game world; operates
 on the terms of the proxy address)
 3) The "virtual cellphone" (the digital client which enables in-game
 communication)
 4) Two avatars
   4a) The "out-of-the-box avatar wardrobe" (this is the visual, visible render
   of the character: what the gamer looks like in the game world [allied to
   rendering engines])
   4b) The "avatarial avatar used by the gamer to move through the game" (this
   is the backend which allows the gamer to interact with objects in the game
   environment [an object of the physics engine/main game engine and will deal
   with collision detection, animation rigging, rigidbody physics, etc...])
 5) Youtube channel playing on a physical phone (interface through a different
 kind of proxy to a different kind of media)
 6) "mild texting and social network chatter" on the physical phone (interface
 through a different proxy as well, one that is more symmetrical to the gamer)
 7) "Real breathing and food intake" (involves leaving the gaming environment
 and interfacing with or operating a series of appliances; there is no proxy
 which affects this interface)
- Brian proposes that the above is a "totalizing storage depot" which organizes
 a series of disconnected elements into a continuous environment (pp. 79)
- Not a real totality, but a series of clients that allow the environment to
 become "total" in some way or another
- Hints that this condition (separate media environments interfacing into one)
 as the contemporary condition the game-engine-as-design-tool is able to deal
 with
- "transitional objects" (adapted Donald Winnicott) as what emerges from design
 with engines (pp. 79)
- Concept responds to responsive architectures and computational (smart)
 environments
- Transitional objects are: portable and discrete, tangible, eternal, no
 attached to one specific environment (pp. 79), "a vehicle for the progression
 toward experiencing" [an interface], dependent on the game engine's regulation
 mechanisms [how it sets up the world] (pp. 80)
- To achieve this, the game engine must:
- Regulate two different kinds of reductionism (binary data flow of hardware
 simplicity of user-end interface) (pp. 82)
- This relation is affected by a middle position of complexity (the algorithm)
 (pp. 82-83)
- Be modular for the sake of efficiency (only the necessary elements need be
 present at any given moment) (pp. 82)
- Be both consistent (non-contradictory, no bugs) and low latency (the backend
 complexity must remain as close to invisible as possible to preserve the
 emulation of real experience "reality is always the goal" (pp. 85)) (pp. 83)
- Provide for interoperability between engine substrates so many kinds of
 engines may work in the same space, on the same environments (knowledge
 transfer, compatibility, the ability to produces many different kinds of
 experience) (pp. 84)

You are viewing proxied material from dome.circumlunar.space. The copyright of proxied material belongs to its original authors. Any comments or complaints in relation to proxied material should be directed to the original authors of the content concerned. Please see the disclaimer for more details.