download: Oracles, draughtsmen, and agents: the nature of knowledge and creativity in design and the role of IT

Bryan Lawson

Automation in Construction. 2005;14(3):383-391.

• Abstract
  • we’ve used the term CAD for 4 decades now!
  • The contribution that the computer has made to supporting creative design[1. I consider creative design to be tautologous] remains patchy & uncoordinated

1. The computer as oracle
   • Many early CAAD projects were far more optimistic than we’d consider undertaking today
   • single criteria optimisation is useless if there is no tradeoff between searches
   • optimisation is powerul, but experience often beats it
2. The computer as draughtsman
   • all above examples are pre-computer graphics
   • Great quote: “once we discovered the computer could draw we have become mesmerised by this capability.We still admire computer graphics in almost the same way we that are amused by animals trained to perform human-like tricks”
   • Computer drawings are less expressive than hand drawings
   • littel had been enables by computer drawing, Gehry and F+P are exceptions
   • now we see (generally) expensive buildings using complex geometry enabled by computers. eg marina bay opera house
   • this form of architecture sets itself hard problems to overcome that were not in the brief to begin with
   • Computers; tail wagging the dog?
   • parallell drawn between contemporary student projects and early DTP projects with large numbers of fonts in them.
   • Great quote: “Recently a student in my University gained only a borderline pass for his final thesis design and then won the national CAD prize for the same work!”
   • I disagree with:
     • “There is a real danger here. Before computers, the student architect had to learn to draw in order to design and also in order to see and record. It was of course possible that very poor architecture could be presented so beautifully that one was deceived. But the sensibilities needed to draw well and to design well are sufficiently similar for this to happen seldom. Not so now with computers. We are in danger of creating a generation of young architects who are highly skilled with computer software and yet have little visual sensibility.”
       This implies that the tutors of acrchitecture are so stupid or out of touch that they are incapable of interpreting the representations that they are presented with.
     • “If the computer software was really well designed and helping us, if it was really computer-aided design, then it would not be necessary to be highly skilled in it.”
       You must be highly skilled in doing something, even if it is telling a group of people to do whatever is required to realise your idea, if the computer is a partner in design then you would need to be highly skilled in working what that partner.
   • B.R. Lawson, CAD and creativity: does the computer really help? Leonardo 35 (3) (2002) 327–331. looks like it is worth a read
3. Problems developing a more creative role
   • • Computer still leads to thinking as an object not as a whole (systems thinking?)
     • Stand alone packages with different input requirements are already available
     • holistic model/analysis not yet available for big and small reasons
     • Time to input all details is too great during design, only once design is finished is it practical
     • Good quote: “This then is not computer-aided design but computer-checked design or computer-visualised design.”
   1. Design modalities
      • multiple mental models are held unselfconciously while designing
      • he defines mental model examples:
        • Spaces
        • components
        • systems
        • layers
      • when designing we switch without noticing between modes
      • Problem: we think generic→specific, computers require specific from the start
      • A. Stokes, The Stones of Rimini, Faber and Faber, London, 1934. makes the distinction between carving and modelling, maybe we ought to be carving!
      • designers run multiple models as well as multiple modes – different representations of different options
      • this seems similar to source control forks and branches
   2. Design problems and sollutions
      • We now know more than we did about the design process and design thinking
      • This hasn’t influenced CAD systems significantly
      • CAD paradigm is to solve by procedural knowledge
      • human paradigm is to solve by reflective practice and episodic knowledge (what does this really mean?)
      • “Conversation with the drawing” Donald Schön (how does pask fit into all of this?)
      • CAD doesn’t support convergence on an “integrative idea”
      • “the design process can never be one of sub-optimisation”
      • There is no obvious mapping between brief and product
      • Design rationale capture system (ADS)
        • logs model state to record choices
        • histories of design – I haven’t read much about these, but I think that it fails in that it doesn’t record what or why, simply that.
   3. Semantic and episodic knowledge in designing
      • “Research shows us that expert designers are distinguishable from novices not because they know more about problems but rather because they know more about solutions”
        • B.R. Lawson, Cognitive strategies in architectural design, Ergonomics - Does this actually support this? It is an interesting claim.
      • “They understand their problems, in as much as they ever actually do, through trying out solutions rather than through abstract analysis” – this seems to imply sketching rather than analysis. Could/would it be better to attack problems from both ends?
      • What is the cognative psychology definition of semantic knowledge
      • internet searches as a source of ‘knowledge’ to support ‘experience’ may well be more useful than CAD at supporting design
   4. representations during the design process
      • Design = periods of reflection → periods of sketching
      • CAD too slow to allow a creative conversation
      • Sketching is personal but also communicative
      • Sketching is similar to natural language
      • Small sketches retain focus
      • Precedents form design experience, i.e. ideas are mixtures of precedents
      • Experts in physics solve problems by recognition, not from first principles - The nature of expertise - This is not unique to physicists
      • Architectual design has very little theory to call on, but lots of examples.
      • Cross-domain examples are useful as a knowledge store
      • Drawing is not an end, but a means making it the output of CAD may be bad. (But drawing may stand in for exploring)
   5. Design conversations
      • Design communication is prediminantly verbal
      • Teams develop their own vocabulary
      • computational team members coudl have different roles; learner, critic, collaberator, initiator
      • linguists are studying design conversations (P. Medway, R. Andrews, Building with words: discourse in an architects’ office -  but I can’t find this paper online)
      • (T. Kvan, J.T.H. Wong, et al., The contribution of structural activities to successful design, International Journal of Com- puter Applications in Technology 16) shows text and, by extention, language to be important in design thinking (verbal descriptions of things)
4. The computer as agent
   • “real” CAD is about supporting and extending design, not about drawing
   • Oracle/agent needs to access pool of precident – users own, and examples in the world (training to make the agent understand what the user thinks of these is probably important too)
   • Design is about ideas, not drawings
   • Agents as ems em comunication to develop idea? (ems here and here)

Lee J-kook, Eastman CM, Lee J, Kannala M, Jeong Y-suk.

Environment and Planning B: Planning and Design. 2010;37(4):628-645.

Abstract

• Universal Circulation Network (UCN) is a plugin for Solibri Model Checker
• Pedestrian circulation in buildings
• UCN←Topology+geometry
• shortest, easiest and most visible paths – shortest is easy, but easiest and most visible could be much harder to do
• useful as a review tool

1. Circulation
   • circulation assessment is interesting to many parties
   • regs define requirements, but not methods of accessing those requirements. (we should check the BCA, USA and UK regs to compare their wording)
   • Navigational knowledge is acknowledged but not addressed (it might be worth talking about ‘fog of war’ type navigation)
   • metric graph used to encompas geometry and topology
   • object classifications
     • Agent (this paper seems to only refer to walking. Bed pushing, wheelchairs etc should be mentioned)
     • Space - unit of traversal, room or bounded area. (discuss dificulties in defining a space here?)
     • circulation environment, the whole thing, doors, rooms, lifts etc.
2. Approaches
   1. Circulation representaiton and graphs
      • graph based approach is well established
      • BIM→UCN
      • we should talk about out double graph optimisation (adjacency trimming and then vis graph)
      • conventional dist measurement is centreline or medial axis, but too many edge cases exist for it to be generalisable for analysis
      • Kannala M, 2005, “Escape route analysis based on building information models: design and implementation”, MSc thesis, Department of Computer Science – looks interesting, but can’t find it anywhere
      • The UCN is an implementation of Kannala’s algorythm in the Solibri software (both Finnish I think)
      • what does “intuitively correct path” mean? Is that the route that an observer would mark out on a plan? intuitively correct may not be optimal at all!
      • a good path matches the one that people, not animals (rats I suppose), robots or computer game AIs would take.
      • fig1 is quite idealised, they only have one possible path (as opposed to a range of choices of path)
        Figure 1.  Various computer-aided circulation graphs: (a) spaces without graphs; (b) topological graph; (c) topological graph with door vertices; (d) center-line-based metric graph; (e) Kannala’s (2005) metric graph; and (f ) metric graph as a preview of the universal circulation network.
      • only metric graphs support distances between spaces. Topological graphs only provide connections

I’m still reading these, and will flesh this post out when I have, but if you wanted to read them, here they are all in one place . Read the rest of this entry »

Today we wrap up the first development cycle of the spatial analysis tool (prototype) we’ve been developing over the past several months here at BVN Architecture. Packaged in the form of an Autodesk Revit addin, this tool allows one to query Revit building models for information related to connectivity between rooms and spaces and the possible paths between arbitrary locations within the models.

Screenshot of the path-finding tool prototype in action.

As the development cycle designation suggests (‘Pre-alpha’), the tool is still very much in the early stages of development with many potential improvements to be made in terms of functionality.

Notably lacking in this version is support for traversibility across model separation lines, navigating around obstacles, multi-level connectivity and multi-level path-finding. We aim to incorporate most of these features during the next phase of development.

This post is a short progresss report. It really should have been posted about 2 weeks ago. Sorry about that:

The prototype is now functional after quite a bit of a rewrite to allow smoother integration of polygon offsetting code as well as to allow for more complicated queries. The rewrite involved a better design for representing doors and their relationship with their parent rooms. Doors have also been separated from the room polygons. This give them equal status to other navigation markers so a lot of code won’t need to handle the special case of doors separately now.

The navigation graph has also been rewritten to take into account this new model for doors, rooms, and markers. This has made it easier to implement one-to-many point queries (now working).

The downside to the new door model is that when the door actually falls on the room polygon, unpredictable things begin to happen in several of the algorithms. For instance, it is no longer clear that the door is on the “inside” of the room, which affects visibility graph construction. However, the introduction of polygon offsetting has mostly made this problem irrelevant – the room is offset, thereby almost always leaving the door distinct form the room polygon.

The new door handling also means that generating visibility graph is slower. Doors navigation lines need to be considered after the room navigation graph is built and is currently found in an extremely inefficient manner. This is less problematic as navigable door lines only need to be calculated once when loading. There are also inefficiencies in checking for visibility lines between markers and doors.

The prototype can also work with models of several levels of elevation. However, navigation is still on a per level basis (that is, you can find paths within a single level, but not between levels). Theoretically, if stairs/elevators can be simplified to a single point (like a door), than we could easily represent the full floor plan with all the levels as a single navigation graph in memory, but displaying that one the GUI will require some thought.

The polygon offsetting has been integrated, but this can only be changed programmatically at the moment – realtime changes to offset won’t be possible at this stage. It’s a fairly computationally intense process.

Some optimizations were made to allow faster path queries. Essentially, the results of djikstra’s runs are cached and are reused whenever possible. Clearly this is a space-time tradeoff, but the change does make the prototype smoother to use. The cache is invalidated whenever the room’s navigation graph changes in any way.

After a bit of a chat today, this is the current state of things. We’ve decided that it’s worth pausing on the pursuit of a perfect system to get a functional prototype into people’s hands to see what they make of it.
There is still a load of stuff on the pile of things to be done afterwards, but for the moment:

• basic obstacles
• a menu / legend of key presses
• some initial documentation
• some tweaks to the UI (adding a better visualisation of doors)
• make the visualisation window modeless, so that the model can be viewed at the same time
• make the offsets adjustable.

once they’ve been ticked off the plan is to package it for easy distribution and get testing!

Separation lines pose a bit of a problem for our visibility graph. Revit reports such lines as room-bounding elements, and so they form edges of a room’s boundary polygons along with walls. However, the spaces adjacent to separation lines should be open to one another along these lines, and therefore we need to deal with removing or excluding these edges from the Visibility graph construction.

A separation line in Revit, delineating a conceptual boundary between rooms 13 & 15.

It would be nice if we could just remove these separation line edges from the room boundaries and merge the adjacent room polygons into one polygon. Alas, it turns out that some room boundaries in Revit can intersect other room boundaries along wall edges, not just separation line edges, which complicates merging since this could produce parallel edges (in the graph sense) in the resulting polygons. Our code does not support polygons with such features. Even if it did, these edges would produce walls with zero width, which is an oddity in itself.

Adjacent rooms along separation lines (shown in blue). The room boundaries coincide at some edges, such as the wall edges between rooms B and C, and the separation line edges between A and B. Coinciding wall edges produce walls of width zero, which we don't want!

Exploded view of the set of adjacent rooms. Here we can see the individual edges that comprise each room boundary.

Our solution to this dilemma is to first offset all room boundaries by a small amount, thus preventing the room boundaries from overlapping one another. We then remove adjacent portions of the separator line edges that originally coincided among the room boundaries, and insert edges appropriately to connect the room boundaries together, forming one merged polygon, perhaps with interior holes.

First we offset the room boundaries by a small amount, perhaps a few inches. This eliminates coinciding edges, but also means that separation line edges no longer coincide.

After offsetting the room boundaries, we remove portions of separation line edges that originally coincided, and heal the polygon with edges between the now "loose" vertices.

To prevent a situation where the merged polygon has polygonal holes within holes, we first determine each set of separation-line-adjacent rooms, and merge each set of adjacent rooms separately. For this we can reuse the code that determined separation-line-adjacency from the room adjacency graph portion of our project.

The paths computed using a visibility graph have a tendency to hug the corners of walls, much like one is stretching out a rubber band along the path taken.

Path computed with the visibility graph. (Note the "wall-hugging")

In order to compute more natural-looking paths—paths more representative of the way people move through spaces—we must consider things such as wall and obstacle clearance, and perhaps gentle (as opposed to sharp and angular) turns along paths.

A more natural-looking path. (Note the wall clearance and gentle turns)

Visibility graphs do not naturally support offsetting paths from the edges of polygons, nor do they yield gentle turns in a path. However, by offsetting the polygons by the desired wall clearance amount and computing the visibility graph on the result, wall clearance can be emulated rather nicely.

Furthermore, by smoothing out the corners at concave vertices with tessellated arcs as we offset the polygon edges, we can achieve a more gentle turn in the paths around such corners.

Path computed on the wall-offsetted polygon. The original polygon region is shown in light grey, the offset region in dark grey. The path computed on this region is shown as an overlay.

One has to be careful when offsetting polygons. Offsetting the edges of a polygon may lead to self intersections and multiple polygon regions. The polygon may even disappear entirely if the offset is great enough.

A sinister-looking polygon with holes.

The same sinister-looking polygon with offset regions (shown in blue). Due to self-intersection of the raw offset polygon, multiple distinct regions have emerged.

There are several approaches to polygon offsetting, keeping in mind the possibility of self-intersections and multiple polygon regions as a result. One approach is to decompose each polygon into a set of convex polygons, offset each convex polygon individually, and then combine the results using set boolean operations such as union and exclusion to form the final offset polygon.

Polygon decomposition into convex polygons and boolean operations on polygons are non-trivial tasks, in that they are fairly computationally complex and tedious to implement effectively and accurately.

A conceptually cleaner and relatively straight-forward approach is to first compute an offset convolution curve, compute the winding number for each region within the curve, and then use the winding numbers to extract the polygons of the resulting offset regions (if any). This is the approach we chose to implement.

A polygon with directed edges.

An offset convolution curve computed on the polygon.

The computed winding numbers for each region enclosed by the convolution curve. The remaining interior regions of the offset polygon are shown in green. Such regions will have a winding number of one.

The original polygon and its offset polygon regions (shown in green).

(For the geometry geeks out there: this method essentially computes the Minkowski Sum of the polygon with a circle of diameter equal to the offset amount.)

This is the video of the tech review presentation.

The panel is: Prof Peter Eades, Dr Taso Viglas, Dr Andrew Burrow, Andrew Metcalf, Chris Tate & Barry Dineen.

I tried to use two cameras to film both sides of the table, but unfortunatly messed it up, sorry guys.

We’ll be presenting our material in a more or less chronological order, i.e. the order in which we approached the analysis of, and the solutions to the various aspects of the problem. Here’s an overview of what we’re presenting:

• Aim of the project
  • There is need for computational analysis of architectural designs, particularly for topological and spatial analysis.
  • The development of a tool for the analysis of architectural floor plan layouts, in terms of connectivity, accessibility and path distance between spaces.
• Potential types of queries we may desire of the system, and the queries we aimed for.
  • Queries such as:
    • “Can I get from room A to room B?”
    • “Can I get from room A to B in a wheelchair?”
    • “Show me the shortest path from room A to room B”
    • “Show me the shortest path from room A to room B, avoiding room C”
    • “Are there any rooms breaching the maximal allowable distance from their nearest fire escape? Show me such rooms”
    • and more!
• Possible discrete representations of architectural layouts, evaluating their suitability given the various spatial scenarios and types of queries to be supported.
  • Room adjacency graph
  • Navigation mesh
  • Visibility graph (not actually about visibility!)
• Our choice of discrete representation, with justification and descriptions of construction and complexity analysis.
  • Hybrid approach, using both a room adjacency graph and visibility graph, with auxiliary door-to-door graph (as an optimization).
  • Visibility graph complexity is \(O(n^2)\) but is nevertheless justifiable!
• Possible choices for algorithms, evaluating their suitability given the spatial requirements, types of queries and floor plan representations.
  • General geometric algorithms (e.g. self-intersecting polygon detection, interior detection of polygon with holes, etc.)
  • Geometric plane sweep algorithms (general plane sweep algorithm; optimal plane sweep using ‘horizon trees’ algorithm)
  • Visibility graph construction algorithm
  • Graph search / path-finding algorithms (Dijkstra’s; A* search algorithm)
  • Polygon offsetting algorithms (polygon decomposition method; convolution curve with winding number method)
  • Polygon simplification algorithms
• Our choice of algorithms, with justification, descriptions and complexity analysis.
  • General plane sweep algorithm in \(O(n^2logn)\). (‘Horizon trees’ method is \(O(n^2)\) but nontrivial to implement)
  • Visibility graph construction algorithm in \(O(n^2logn)\). (Can be done in optimal \(O(n^2)\) given an \(O(n^2)\) plane sweep algorithm)
  • Dijkstra’s algorithm for path finding. (Fast enough for our purposes.)
  • Convolution curve with winding number method for polygon offsetting in \(O(n^2logn)\). (Can be done in \(O(n^2)\) given an \(O(n^2)\) plane sweep algorithm. Also conceptually cleaner and practically easier to implement than the alternative.)
  • Polygon simplification: (Is it worth it?)
• Software implementation: the programming interface, choice of programming language, software packages, etc.
  • CAD software: Autodesk’s Revit programming interface and .NET environment.
  • Use of the .NET C# language conforming to the programming interface.
  • Microsoft’s ‘QuickGraph’ graph package for graph construction and algorithms.
  • ‘Graphviz‘ graph visualization package for quick-and-dirty graph visualization.
• Live demo of the prototype we’ve developed to query the architectural layouts.
  • Fun! =)
• Issues:
  • Shortcomings in the CAD software’s programming interface
  • Geometric issues related to the architectural CAD models
  • Numerical accuracy in a discrete environment (esp. with regard to handling geometry).
• Potential future work and improvements.
• Questions, suggestions and discussion!