Just came across a method of using OGLE and GLIntercept to dump geometry from GoogleEarth to the OBJ file format.  I’ve summarized the steps here, but complete and detailed instructions can be found on the EyeBeam OGLE website.

DISCLAIMER:  The following is for illustration purposes only. The following text does not advocate for or condone the commercial use of copyrighted materials without the consent of the owner(s) or author(s).  Furthermore, since this process requires changing some system libraries (dll files), the author of this text is not responsible for damages to your computer or loss of data.  Follow these instructions at your own risk.

Prerequisites:

• OGLE: http://ogle.eyebeamresearch.org/download (version: 0.3 beta)
• GLIntercept: http://glintercept.nutty.org/ (version: 0.5)
• GoogleEarth: http://earth.google.com/ (version: 5)
• 3D modeling software, such as 3DStudioMax or Rhino.

Instructions:

1.     Install GLIntercept…

2.     Copy the system .dll (C:\WINDOWS\system32\opengl32.dll) to your GoogleEarth directory (name it opengl32.orig.dll) as backup.

3.     Set GLSystemLib = "opengl32.orig.dll" in your gliConfig.ini file.

4.     Install the OGLE plug-in into the GLIntercept plugins folder.  Copy the whole OGLE distribution (i.e. the directory that contains the OGLE.dll file) into the Plugins directory for your GLIntercept installation (typically C:\Program Files\GLIntercept0_5\Plugins\), and rename the directory to OGLE (i.e. change the name from ogle_* to OGLE).

5.     Set the capture keystroke.  Navigate to and edit the gliConfig.ini (stored in the C:\Program Files\Google\Google Earth\).  Scroll down and set the keystroke to something you can remember, but is not already taken: something like Ctrl+’ …

Save and close the gliConfig.ini file.  You should be ready to capture.

6.     Open GoogleEarth.  Press the keystroke.  GoogleEarth may freeze up for a second, so be patient as it extracts the geometry.

7.     As soon as the application is active again, you should find an obj file in your GoogleEarth directory:

8.     Open Rhino, Blender, or 3DStudio (etc).  Open or import the ogle.obj …

9.     The geometry will be out-of-scale.  OGLE and GLIntercept also capture the screen components that make up the entire scene, such as terrain and application navigate toolbars.  You have to do some pruning to get the geometry you want, but it should be there (even if it’s extremely small).

10.     Now you can clean up your geometry as needed.  In Rhino, use the selective delete tools to find and prune what you don’t need.  As you can see, the geometry comes in as a mesh.  To clean up meshes, use the MeshToNURBS, ShrinkTrimmedSurfaces, MergeAllFaces, and Join tools to simplify the scene.  (You may want to turn off isocurves if you use this method).  Best of luck!

The process of converting GIS building and terrain data into a usable, 3D model, is a relatively simple (but not necessarily) straightforward task.  The general idea is to use GIS data, including non-graphical data fields like ‘apex’ and ‘elevation,’ to create a 3D model that can later be edited with various 3D modeling software.  For buildings, the method is to translate the building footprints (from the GIS shapefile), to their appropriate altitude (resting on the ground), then to extrude the footprints to their appropriate height (the apex of the building), and then export it all as a VRML geometry.  For terrain, the method is to convert a contour map into a TIN (Triangulated Irregular Network), then to a Raster image, then back to a TIN, and then export it as VRML geometry.

Prerequisites:

• ArcGIS 9.1 or better (Specifically ArcMap and ArcScene)
• Modeling software that can import VRML (such as Autodesk’s 3DSMax or McNeel’s Rhino)
• The GIS shapefiles for the buildings and terrain which you want to model (contour maps will work).

Sample Data:
You may want to try the following tutorial using this sample data, to get the hang of the process before you try another site.

Instructions:

1. Download the sample data in the archive listed above.
2. Decompress the .ZIP into a convenient location (such as a “temp” folder on the desktop).
3. OPEN ArcMap 9.1 or better.
4. Click the Add Data button.
5. In the Add Data dialog box, highlight and select both building_sample.shp and contour_sample.shp.  Both of these shapefiles will be added to the Layers Manager (on the left of the screen) and appear in the main viewing window.  You may want to drag the buildings_sample layer above the contour_sample layer so that the buildings appear above the contour lines:
6. CROP.  You may notice that the area in question is rather large.  For most purposes, you will want to crop out an area and throw away the rest.  If possible, it is best to divide large areas into smaller “chunks,” so that process of exporting and importing the VRML (see below) is manageable (WARNING: large geometries make very large VRML files).  For this example, we will focus on the campus and crop out the rest of the neighborhood.
   1. Click on the contour_sample layer.  Use the selection tool to highlight the areas you want to save into a separate shapefile, and then right-click the layer name in the layers browser.
   2. Under the ‘Data’ menu, select ‘Export Data.’ Give the shapefile a new, more recognizable name (such as contour_crop, and then save.)  When prompted, add the new layer to the current map and remove the old contour_sample layer (right-click the layer name and then Remove).
   3. Now click on the building_sample layer.  This time, you can select only the buildings that intersect the contour lines.  Under the Selection Menu, click Select By Location.  In the Selection By Location menu, select features from the building_sample layer that intersect the features in the contour_crop layer.   Once the buildings are selected, simply repeat the ‘Export Data’ instructions in step 2. (above).
   4. Repeat this process with each layer you wish to work with (if you are doing only buildings and terrain, then you only need to do this twice.)  It is important that each layer be saved separately into a shapefile (for this example, terrain in one shapefile, building footprints in another).  By this point you should have a map that looks something like this…
7. CLOSE ArcMap.  (You may want to save the map, but all you really need are the shapefiles you just created).
8. OPEN ArcScene 9.1 or better.
9. As in 4. (above), click the Add Data Button. This time, only add the cropped shapefiles (building_crop.shp and contour_crop.shp) to the Scene.  [graphic]  You should see something like this [graphic]
10. CONVERT TERRAIN TO 3D.  We’ll begin with the terrain.  This process is a bit tricky.  The general idea is to convert the contour lines to a TIN (Triangulated Irregular Network) and then to a VRML file.  However, simply converting to a TIN with ArcScene produces overly detailed geometries in which every point on every contour is connect to every other contour line.  This is unnecessary, but there is a workaround which requires converting the contour to a TIN, then to a Raster format, then back to a TIN, in the process loosing some of the detail, but preserving the terrain characteristics…
    1. Verify that the 3D Analyst Toolbar is turned on.
    2. Click and highlight the contour_crop layer in the Scene Layers manager on the left.
    3. Under the 3D Analyst Toolbar, under “Create/Modify TIN,” select “Create TIN from Features.”
    4. In the Create TIN from Features menu, check the contour_crop layer, verify that the Height source is set to ELEV, and give the tin a new name (such as contour_tin1).
    5. The resulting TIN should appear in the Scene.  Remove the old contour_crop layer from the Scene (right-click on the layer name and select Remove).
    6. Click and highlight the contour_tin1 layer in the Scene Layers manager.
    7. Under the 3D Analyst Toolbar, under “Convert,” select “TIN to Raster.”
    8. In the Convert TIN to Raster menu, set the Cell size to a setting that gives a reasonable number of Rows and Columns.  There is no hard and fast rule for this, but something that is under 1000 Rows and 1000 Columns is safe.  Generally speaking, the smaller the cell size, the more detailed the terrain.  Next, give the new raster layer a name (such as contour_rast).
    9. The resulting Raster image should appear in the Scene.  Remove the old contour_tin1 TIN from the Scene (right-click on the layer name and select Remove).
    10. Click and highlight the contour_rast layer in the Scene Layers manager.
    11. Under the 3D Analyst Toolbar, under “Convert,” select “Raster to TIN.”
    12. In the Convert Raster to TIN menu, set the Z tolerance to a reasonable setting…again, there is no hard and fast rule for this, but something that is between 5 and 10 ought to work.  The smaller the Z unit value, the more points in the TIN.  Next, give the new TIN layer a name (such as contour_tin2).
    13. The resulting TIN should appear in the Scene.  Thought this TIN is less detailed version of the original contour, the features should be accurate enough for terrain modeling.  It is possible, however, to apply some smoothing to the terrain surface in 3DstudioMax,  Rhino, etc., after the conversion process.
    14. Remove the old contour_rast layer from the Scene (right-click on the layer name and select Remove).
11. CONVERT BUILDINGS TO 3D.  Now on to the buildings.  Compared to the terrain, this process should be more straightforward.
    1. Right-click the building_crop layer in the Scene Layers manager on the left.  From the menu, select Properties.
    2. In the Layer Properties menu, click the “Base Heights” tab.
    3. Under Height, select the second radio button option “Obtain heights for layer from surface.”  Verify that the contour_tin2 (the terrain TIN) surface appears in the path below.  This will move the building footprint base heights up to the surface of the terrain.
    4. In the Layer Properties menu, click the “Extrusion” tab.
    5. Check the box in the upper-left to turn on “Extrusion.”  Under “Extrusion value or expression:”  enter in [APEX].  Apply the extrusion by “using it” (in this case, [APEX]) “as a value that features are extruded to.”  This extrudes each building footprint up to the stored [APEX] height in the shapefile.  Click Apply.
    6. Your resulting Scene should look something like this:
12. EXPORT EVERYTHING TO VRML.  Once you have the Scene how you like it, you can export it to a VRML file.  It is important that you export both the buildings and terrain as separate VRML files.  This is a simple process…
    1. Export the buildings.  Check the box next to the terrain layer in the Scene layers manager to hide the terrain.  Only the buildings should be visible.
    2. In the File menu, under “Export Scene,” select “3D”.
    3. Export the buildings as a VRML file (.WRL extension).
    4. Now turn the terrain layer back on (check the box in the Scene layers manager), and turn off the buildings, and repeat the Export steps above (2. and 3.) for the terrain.
    5. NOTE: depending on the complexity of the scene (number of vertices), the conversion to VRML may take some time.  However, if you cropped the scene as outlined here, and made sure the Cell sizes and Z tolerance on the terrain conversion (see steps 10.8 and 10.12 above) are set to a reasonable value, this should not take more than a few moments (depending on the machine you are using).
13. IMPORT INTO MODELING SOFTWARE.  Depending on which modeling software you choose to use, the process for importing the VRML files varies accordingly.  In 3DstudioMax, you simply choose “Import” from the File menu, and import each of the .WRL models separately and merge them into one scene.
14. APPLY MODIFIERS.  Depending on which modeling software you choose, you may need to apply some modifiers to get the buildings and terrain to display correctly.  For example, in 3DS, the imported terrain may have normals that point the wrong direction.  This is an easy fix, just select the Normals modifier from the Modifier panel to flip them around.  The imported buildings may also require that you apply the “Cap Holes” modifier to fill in any holes in the geometry as a result of the VRML conversion.
15. SUCCESS!  (Hopefully!)  You’ve finished the conversion process.  You might notice that, as expected, the buildings all form one giant geometry, making it difficult to drag individual buildings around.  This is a minor inconvenience, but you can work around this by converting the building geometry to an Editable Poly, and then selecting each building and moving it around within the scene.  Happy modeling.

“For seeing life is but a motion of limbs, the beginning whereof is in some principal part within, why may we not say that all automata (engines that move themselves by springs and wheels as doth a watch) have an artificial life?”
-Thomas Hobbes, Leviathan, 1660.

For sheer uncanny sci-fi weirdness, nothing tops reading the abstracts for the funded projects on the Defense Science Board’s website.  The DSB is the public face of funding for academic research relevant to DARPA – the Defense Advanced Research Projects Agency.  You may know DARPA from such projects as directed heat-ray weaponry, sub-vocalization detection, passive radar, the Internet, etc.  DARPA is not as cloak-and-dagger as it may seem from its ominous name; in the defense world, it’s the Pentagon’s way of funding those wacky little “off the wall” projects that might not otherwise receive support.  You know, those cute little defenseless defense projects?  DARPA likes to call those “strategic technology vectors.”   This year, one of the main strategic vectors being pushed forward by the Pentagon is in a field called “agent modeling” or “crowd dynamics.”  DARPA has various terms for this line of research, from crowd theory to “human terrain mapping” to “social simulation.”  You can think of this broadly as the science of individual and collective behavior situated in an environment.

Shortly after the US-led invasion of Iraq, members of the US military entrusted with coordinating crowd control and counter-insurgency measures were met with the problem of navigating and intervening in unknown social and political territory.  Models of collective human behavior were thought critical to effective planning and “logistics.”   This is not the first time that the Pentagon has decided to focus on quantitative social sciences of crowds and collective behavior.  During the Vietnam War, DARPA launched an ambitious endeavor called “Project Camelot.”  DARPA’s director, R.L. Sproul, testified before congress that “it is [our] primary thesis that remote area warfare is controlled in a major way by the environment in which the warfare occurs; by the sociological and anthropological characteristics of the people involved in the war.” (McFate, 2005).  Project Camelot was tested in Chile, but was met with such local resistance and negative press domestically that Secretary of Defense Robert McNamara cancelled the program.  Much has happened since Sproul’s time and, as of 2003, this line of research is back, with new tools and new funding.

What is in question here is simulation, more specifically the simulation of people and crowds.  Simulation of physical systems is now making in-roads into architectural practice.  The facility to simulate natural processes is greatly aided by the low cost and ubiquity of computation.  The ability to simulate lighting conditions, thermal properties, acoustic effects, and structural stability, are all becoming part of sustainable design practice.  Thermal simulation (employing software such as Ecotect) can give us an accurate picture of how a space will behave under different heating/cooling and seasonal conditions, with varying numbers of bodies occupying a space.  Physically-based rendering (using Radiance) can produce images which actually contain data about light.  But behavior of light in a space is fundamentally different from the behavior of people…right?

Simulating human behavior is nothing terribly novel.  Recently, the notion of computational simulated agents has made its way into popular culture.  The Sims by Electronic Arts – the best selling computer game of all time – casts the player as the omniscient controller of a family of simulated agents.  Massive – a software tool developed for the film trilogy The Lord of the Rings – allows the user to simulate a “massive” crowd of autonomous agents who interact and exhibit complex emergent behavior.  However, these games, tools and visualizations are making their way into design practice.  What does this mean for architecture?  Imagine your SketchUp model populated with hundreds of animated characters.  Instead of the little outlined silhouettes frozen in mid-stride, exploratory agents walk through, inhabit, use, abuse and dwell in your design.

How does this work?  Just how predictable are you?  So many theories, so little time.  Biologists have long been fascinated with collective behavior in the animal kingdom.  Flocks, swarms, schools, and herds all display the hallmarks of collective emergent organization springing from the application of simple rules to large systems.  Consider two models of your behavior: “top-down” and “bottom-up.”  The top-down view sees your behavior as a direct result of the layout of an environment.  The bottom-up approach casts an person’s behavior as the result of a variable-juggling cognitively calculated reaction to input about an environment.  Both represent you as a convenient computational abstraction.  You are not you. You are an agent, within a system.  How you behave is entirely up to the system.

This brings up a number of theoretical and technical questions: What behavior should the agent simulate?  Does the agent exhibit this behavior?  Do humans behave in the same way?  How do groups of humans behave?  Do models exhibit these group behaviors?  Can models capture something beyond simply behavior? Can they capture emotion?  Mood?  Cognitive process?    What does this have to do with architecture?  Just how predictable are people?  Should we model agents and crowds at all?  Putting aside the final normative questions for the moment, let’s first consider the top-down approach.

“Great bodies of people are never responsible for what they do.”
-Virginia Woolf, A Room of One’s Own, 1929.

Reason.  Rationality.  “Higher thought.”  For the moment, let’s pretend they are of little interest.  Even if reason tends to reassert itself – as it has a tendency to do – let’s treat it obliquely.  What we are interested in is what people tend to do in a place.  Specifically, what is of interest is what groups of people tend to do.  This approach, often called “crowd -based” simulation, works from the top-down.

Though now rather dated and a bit cheesy, the introduction to William H. Whyte’s film on the “Social Life of Small Urban Spaces” (1980) is well worth viewing.  There is something fascinating about watching the fast-forward footage of individuals, groups and crowds moving with the sun across the square of van der Rohe’s Seagram building in New York.  What is of particular interest in Whyte’s observations – as functionalist and analytic as they may seem – is the interplay of collective behavior, the built environment, and physical conditions.  Even if his conclusions were bottom-up, Whyte began his observations literally from the top-down, looking down on the plaza below.

A recent example of the figurative top-down method comes from the UW’s Computer Science and Engineering department.  Treuille et al’s work on “Continuum Crowds” can generate and simulate masses incorporating many thousands of individuals.  Many crowd simulators work from the bottom-up.  Such systems simulate the decisions and movements of each individual, which is computationally costly.  The UW team’s alternative, top-down method, can produce a realistic simulation movement of a large, retreating army, for example.  Treuille et al’s crowd-simulation system casts a crowd as a collection of particles with a specific goal – to get to a certain place. The simulation propels the “individuals” towards their goal while taking into account an ambient “discomfort field.”  Think of this discomfort field as your own personal somatic comfort zone.  This prevents the agents stampeding or crashing together.  However, in this model of behavior, there is not explicit collision avoidance built-in to the agents themselves; rather, their behavior is the direct result of the structure of the environment and the behavior of other people.  (Think of the path rain-water runoff: its fluid path is determined by gravity and the shape of the environment).  The environment is a dynamic potential field – with attractor and repeller states – pushing and pulling the “agents” through the space.  This method is computationally efficient, as is scales well to large crowds and gives visually compelling results in real-time.

There is an unashamed casting aside of the individual in this approach.  To be fair, the aim of these top-down methods is not to figure out what is going on in an individual’s head while shopping, but to produce a realistic visual representation of crowd behavior in a short amount of time.  But one can easily image how such a simulation could be applied to fire-egress (“need to know”), space layout planning (“good to know”), and crowd-control simulations (“big brother is watching”).  The top-down approach casts “us” as a swirling dance of a bubbles in boiling water.  Technically speaking, one of the short-comings of this approach is dealing with dynamic environments.  In most top-down methods, structure of the environment is “precomputed” as the parameters of the environment largely determine the resultant emergent behavior.  Changing the environment on the fly is computationally expensive as the numbers must be crunched yet again.   Tacit with this approach is the notion that behavior is a direct result of the environment and interaction those within it.  This approach – as elegant as it may seem – differs in theory and practice from the “bottom-up” method…

“L’homme est une machine.”
(Man is a machine.)            -Julien Offray de La Mettrie, L’homme machine, 1748.

As previously eluded to, many crowd simulators work from the bottom-up.  This is also known as the agent-based approach.  Such systems simulate the decisions and movements of each individual or agent.  This method gives the researcher (or designer) fine-grained control over the inner-machinations and cognitive variables of the agent system, but can result in extremely unpredicted emergent behavior.  Tweaking the variables within an agent can lead to very different results.  In the early days of the agent-based approach – when computers were slow and expensive – scale was a huge issue.  It was very important to choose the variables wisely, as the simulations could take days or weeks to run.  However, with today’s cheap, fast and ubiquitous computing resources, these same simulations can be run in real-time.  This allows the researcher or designer to employ guess-and-check, trial-and-error approach.

Paul Torrens, a geography professor at Arizona State University, has created a software toolkit for this exact application.  One can import 3D geometry, define the rules that drive each agent, and see how the autonomous “individuals” interact in a given context.  In the bottom-up method, each individual agent is built-up from many stacked levels of rules: a subsumption architecture of sorts.  Starting with the simple kinematics of bodily joints, then the physics of individual movement, then the basic navigational heuristics, followed by rules governing social behaviors, etc, the agent modeler defines these rules at a given level, then releases the agents into a 2D or 3D environment and watches how they behave.

Saunders and Gero (2001) – of the University of Sydney – have proposed a framework for modeling curious agents.  These agents are programmed to prefer certain patterns and get bored with the same stimuli if encountered over and over.  Developing this model (2004), Saunders and Gero tweaked their curious agents to perform a “situated design evaluation.”  The test case was a virtual art gallery.  The plan of the gallery has four rooms and only one entrance and one exit.  On each of the virtual walls are hung different “artworks.”   These works are actually only simple R, G, B color values…think of it as a 32-bit Mark Rothko exhibition.  Each of the curious agents is programmed to randomly prefer one or another of these colors, but is curious about related colors.  Casting glances into each rooms and moving toward works it is attracted to, the agents move through the gallery.  Simply randomly arranging the order and hanging location of the paintings causes an uneven dispersal of agents in the entry and the exit.  The agents crowd together, but don’t really move into the subsequent rooms (this would come as no surprise to a professional curator.)  However, these agents then gave feedback to the space-layout algorithm, so in the next iteration of the gallery the artwork was better distributed.  The agents were then re-released into the gallery and gave their “feedback.”  This feedback was a plotted graph of their boredom with time: the less bored, the better; the less crowded, the better.  The gallery was then tweaked again and again.  The curious agents illustrate that extremely banal parameters – a measure of curiousity and a metric of boredom – can provide strong feedback for space layout planning.  While these agents do not appear human in their basic navigation behaviors or social norms, they display a startling tendency to behave appropriately within a given context.  The mechanics of their grossly simplified cognitive process (“I like blue”, “I’m bored with green”) are completely transparent to the researcher and the designer.  Furthermore, the resulting floorplans and layouts could be construed as generative in some sense.  This is the beginning of a parametric cognitive design logic.

Recent advances in cognitive science have lead to models of simple activities (such as walking past obstacles toward a goal) that strongly correlate with observed patterns (Fajen and Warren for example).  These deceptively simple models are not deterministic – but stochastic.  They paint a picture of human behavior that is (partially) constrained by non-linear dynamics, not governed by clockwork mechanics.  These approaches can accurately capture basic everyday activities and can even account for some individual and cultural traits.  For example, several visually-guided steering models have been created that can capture behavioral difference due to shoulder-width – a football player model that makes its way through a crowd differently – or even cultural habit – a UK, Japanese, or New Zealand steering model that “prefers” the left side of the road.  In other words, higher-order variables can be captured.  For designers, this ought to be quite interesting and disquieting.

“Verum et factum convertuntur.”
The true and the made are convertible.
-Giambattista Vico, De nostri temporis studiorum ratione, 1709.

Human behavior as a cybernetic concept has deep roots in a mechanistic view of man.  Norbert Wiener, the mathematician, engineer and social philosopher, coined the word “cybernetics” from the Greek word meaning steersman.  He defined it as the science of communication and control in the animal and the machine.  The term has since fallen out of style in mainstream cognitive sciences, perhaps because of its overt control connotation.  Cybernetics arose out of dissatisfaction with the empirical psychology of the 20th century.  The rise of a mechanization view of human thought coincided with the advent of mechanized and automated computation.  Cybernetics can be thought of as an attempt to understand machines through analogies to organisms; making machines more adaptive, flexible and more in tune with given environments and operatives in order to deal with the increasing complexity of the world.  There is a notable inversion of mechanism and organism.

It is perhaps because of this inversion that agent and crowd modeling have generated a certain defensive subculture at the fringes of architectural research.  The justification behind the research thread might be captured in a question: “If we can simulate human behavior – walking through a shopping mall or fleeing a fire, for example – could it be used to aid in design and planning?”   Legion works with the AEC industry, using proprietary agent simulation software, to do just this.  Only a handful of large design firms are currently working on and with agent simulation software.  Admittedly, the current application of such software is limited to mundane tasks like space-layout planning for shopping malls and airports, way-finding in sports arenas.  However, even with such pedestrian tasks, these firms are finding it important to describe and model the higher-order processes of pedestrian way finding such as route choice, congestion avoidance, direction following, and dwelling.  At the current state of domesticated computing (read: you don’t have access to a super-computer), these systems are able to compute the decisions and trajectories of over 10,000 people (or around 700-800 in real-time).  What is interesting is that agent-modeling and crowd simulation are moving out of the realm of laboratory curiosity and into the realm of design practice.  This ought to raise some red flags within the discipline.  There seems to be a danger in assuming that human behavior is entirely predictable and mechanical.  The radical notion that human behavior might conform to such patterns and forms, and be quantified in such a way, was (and still is) one of the most troubling and powerful theoretical tenets of cybernetics.  Considering this view, there is a tendency to lapse into a morbid determinism. Even the most crude of “man-as-black-box” theories – behaviorism – did little to dissuade anyone (including some Modernists) from this mechanistic view of humanity.

As in science, as in architecture, models are a tool for communication, for testing theories, for gaining insight.  The mapping between model and construction, however, is slightly different in modern technoscience.  In architectural practice, a model of a building tells you something about a possible building, but one does not (hopefully) mistake it for the finished building.  The framework of reductionist science is simplified models of complex systems.  Modern medicine has a simplified model of human anatomy that it uses to generalize the specificity of the human body during surgery.  Epidemiology relies on a simplified model of human behavior to model the spread of disease and craft interventions to prevent catastrophe.  It is the beginning of understanding.  It is not the end, but a process.  But as teleological as modern science might seem (a large debate in itself), it is undergoing a fundamental shift.  This shift is largely due to the speed and accuracy with which models can be created and explored.  Architecture, as a practice, is increasingly employing simulation in the iterative process of design.  With increased physical simulation, major gains will be made in terms of sustainability.  However, what role ought simulation play in the process, specifically with regard to behavioral modeling?

One danger is that these models can begin to become self-fulfilling.  While this may sound strange, when the model is posited as a yardstick for measuring “normal” behavior, there is a danger that we (fallible humans that we are) will begin making the world more like the model rather than tweaking the model to fit reality.   How pernicious is a simplified model of individual behavior?    Is simulation of a physical system fundamentally different from that of behavioral systems?  What models ought we employ?  A generic model?  A cultural model?  A consumer model?  Which is more frightening, government or corporate misuse?  Again, we return to the same questions.

Much of our world is designed with group dynamics in mind.  Architects and Urban Planners are implicated in this design.  Some systems are overtly about control (traffic lights are there for a good reason) and some designs are more subtle (public spaces designed with CCTV in mind).   It ought to be clear by now that control and the circumvention of behavior presumes a wholly deterministic system.  We ought not be too interested in this issue of determinism.  Rather than lapse into atavistic arguments about the role of free will, we should seek to understand this emerging undercurrent of simulation in its entirety.  What is at stake is agency as designers, not free will as individuals.  Rather than flinch at the notion of a predictive model of crowd or human behavior, I believe architects and planners should actively engage these emerging technologies, use them, tweak them, question and critique them, shape and subvert them.

Open up shot in SynthEyes. File -> Open. SynthEyes accepts common video formats and should read all the video “meta-data” from your video if it was generated digitally. The frame-rate, interlacing, image and pixel aspect ratios should be correct. If your clip was generated with an older analog camera, you may need to track down all this information from the video capture program you used to import the clip.

Start the Auto-track on the clip.

Click the large “Auto” button in the upper-left:
This does the 2D and 3D “inverse” homography to figure out the camera movement and focal-length from the motion. This computes the cameras path through the scene relative to the tracked locations.

Create a coordinate system to snap the reference plane to the ground. Click the “Coords” button on the left-hand side of the screen. Now, in the camera viewport, click three co-planar reference points in sequence. SynthEyes will ask you if you want to Apply the coordinate system. Click “Yes.”

Refine the solution by clicking “Ok” in the window that appears. This snaps everything to the newly created X-Y plane.
Stabilization (if necessary). Save out the image sequence. Open the Image Preparation window (Shot à Image Preparation) by pressing the “P” key. Switch to the “Output” tab. This opens the “Save Processed Image Sequence” dialog. Click the “…” button in the upper-right to open a “Select Preview Output File Name” dialog. This allows you to select where you want to save your image sequence. Navigate to an appropriate folder of your choice (choose something convenient that you can navigate back to if need be) and switch the “Save as type” to “JPEG Sequence.” Click “Save” when finished. Back in the “Save Processed Image Sequence” dialog, click the “Start” button to save the image sequence to your preset folder with the assigned file names.

Change the shot images to be the image sequence. This replaces the video clip with the single image frames we saved out in step 5 above. Microstation only works with raster/bitmap images as backgrounds, not video-clips.  Navigate to Shot -> Change Shot Images. In the browser, navigate back to the folder in which you just saved your image sequence. Click the first image in the sequence. When the import dialog appears, click “OK” to accept the defaults.

SKP -> OBJ -> DGN

NOTE: This workflow used SketchUp 6 and Bentley Architecture XM.  Subsequent versions of either application may have better (or worse) performance using native SKP (h/t to SF).

There may be situations during the design process where importing SketchUp models into Microstation is necessary. For example, you may want to search Google’s 3D Warehouse for context buildings that you can reference into your Bentley Architecture model for a context rendering of the site. The best way to go from SketchUp to Microstation is through .OBJ. OBJ is the Lightwave file format and seems to be very material/texture friendly. Microstation has no trouble digesting the SketchUp assigned materials and importing them if the correct settings are applied. Follow the directions below to get (most, if not all) of the correct textures and scale.

Begin by opening the SketchUp file in SketchUp or importing it from GoogleEarth or 3DWarehouse. Make sure all the materials are correctly applied before you export.

Go to File -> Export -> 3DModel.

Select .OBJ from the Export Format dropdown. Once this is selected, give the file a name and place it in a convenient folder. NOTE: SketchUp exports the texture maps into a separate folder that must be collocated with the .OBJ file during import. After you have given the file a name and selected a folder to export to, click the “Options” button. In the OBJ Export Options dialog, uncheck all the Geometry options, check “Export texture Maps” and check “Swap YZ coordinates.” Click “OK.” Then click “Export.”

SketchUp displays a friendly OBJ Exports Results page. Click OK. Fire up Bentley Architecture/Microstation…

Create a new 3D model file holder (give it an appropriate name) from the 3D-Seed.dgn seed. You will Open the .OBJ into this file. Your first instinct will probably be to “Import” the file, since you “Exported” it from SketchUp. However, Microstation can Open .OBJ files…which is nice.

Open the .OBJ file in the empty .DGN file.

If all goes well, you should see your model appear in the viewport. You may need to rotate in order for the textures to appear on the surfaces. You may also need to change the active viewport settings to a shaded render mode.

Save As a .DGN. It is important to remember that even the DGN file needs to be able to “see” the relevant textures in order for this process to work.  However, once these textures/materials are in the correct location, you can reference your new .DGN from another master file. Simply repeat this process for each relevant context building and you can easily leverage SketchUp models in your BIM workflow where appropriate. Best of luck.

The interaction was quite fluid and the polygon count very high: somewhere around 200,000 polygons displayed at 30 fps.  Multiple stencil-buffers were employed for the lens effect (thanks to Julian Looser for his inspiration on this one).   A simple Head’s Up Display (HUD) allows the user to toggle layer visibility.  Check out this video of the basic interaction…

Check out the this video for the basic interaction…

MxR – pronounced “mixer” – is a Mixed/Augmented Reality system intended to support collaboration during early phases of architectural design.  MxR allows an interdisciplinary group of practitioners and stakeholders to gather around a table, discuss and test different hypotheses, visualize results, simulate different physical systems, and generate simple forms.  MxR is also a test-bed for collaborative interactions and demonstrates different configuration potentials, from exploration of individual alternatives to group discussion around a physical model.  As a MR-VR transitional interface, MxR allows for movement along the reality-virtuality continuum, while employing a simple tangible user-interface and a MagicLens interaction technique.