We had a lot of fun working on this bridge concept:
Unfortunately, we didn’t win the competition. However, I still think the idea is pretty cool. Here’s some text:
ZwerverBrug, or literally, Wanderer Bridge, is both a means and an end. Inspired by traditional two arch stone bridges, the Zwerver uses primary steel tubes and secondary webbing clad in pre-finished steel panels to support a stone clad deck. The structure and form work together, creating two unique experiences. First, an elevated direct route across the river providing the necessary height to allow the majority of river traffic to pass underneath. Secondly, a stepped and lowered boulevard housing a cafe and affording conversations, seating, lounging, and strolling. In order ensure accessibility, the steps in the deck are flattened when the slope of the underlying surface is safely transversible by wheelchair, stroller, walker, and of course bicycle.
So, Wanderer, which way are you going?
One of the interesting challenges was creating a GH definition for the squashed steps. The idea is that given a a surface contoured by height intervals (a process that has been nicely componentized…), the definition grabs the surface normal at a bunch of points along each contour curve. If the surface normal varies from the z-axis by more than a preset amount, the curve pops up, creating a step.
Crazy as it looks, this thing might actually work:
- Gap between glass gaurd and stone wearing surface for drainage
- Cast-in anchor for glass guard connections
- Cross slope to exterior for drainage
- Precast concrete deck panels
- Stone wearing surface
- Setting bed
- Continuous stainless steel pipe
- Laminated glass guard
- Intermittent patch fittings
- Primary curved pipe
- Pre-finished metal panel cladding
- Web openings for distribution of services
- Intermittent transverse members rigidly coupling primary pipes
This release features a major reworking of the component set. Yes, we managed to break all functionality during the refactoring; No, we couldn’t figure out how to fix it for a quite while…..In the end, it all came together, though. The biggest change is that we combined the Static and Dynamic Integrators into one. This means you can toggle between the two modes on the fly. Beware, though, if you leave the timer enabled and switch to the static integration, you’ll rebuild the solution at every time step (i.e. crash)!
We have also decided to release our code for the dynamics. This means that if you adhere to structure, you can build your own dynamics.
- Acceleration component has been removed. By default, the simulation assumes all vectors are forces. This can be toggled in the settings if you simply want to integrate.
- The settings component has been broken out into three components and a few menu options.
- Inter-particle forces have been added. This is meant more as a prototype for future developments (flocking has been done many times before…more on this later). These dynamics are SLOW!
- Dynamic Emitters! These are really fun…
Surface Attraction: Turns any list of surfaces into gravity attractors or repellers.
Surface Flow: When particles are close, they flow along any list of surfaces.
Separation: Assign a distance to be maintained between particles within a given radius.
Cohesion: Particles will tend towards the average of their neighbours.
Alignment: Particles will tend towards travelling in the same direction as their neighbours.
Dynamic Keyframe: Give collections of dynamics time intervals to be activated.
- Added a “Settings” Component which allows you to tweak the integration component. Most of what we implemented are checks that stop the integral line (winding number still to come…), and the default values work in most cases
- Added an “Interpolation” factor in the “Settings” Component which computes an expected vector between the sample points. This allows you to get integral curves on even a very coarse sampling space – however, you lose accuracy. Use with caution!
- Dynamic Simulation Compute can now simulate multiple flows at once
- Under the hood, the whole project has been restructured (and rewritten!) to accomodate further development…
Download it here…, or join the discussion.
I had the great pleasure of working with some fantastic people at SG2011. Our team consisted of :
- Mark Cabrinha
- Michael Drobnik
- Alvin Huang
- Daniel Hambleton
And here’s what we built (Thanks Michael for the pics!):
Dragonfly is a first attempt at linking the theory of ecological perception to architecture. Given certain abstract programmatic events (e.g. view art, buy food, sit down, look up) and knowing roughly where they’re supposed to happen, Dragonfly simulates a user navigating the proposed layout. By observing the user’s behaviour, we can assess how effective the layout is.
Granted, in this example, the layout gets pretty chaotic, but it shows the principle…work in progress, folks.
- Daniel Hambleton, Studio for Progressive Modelling, Halcrow Yolles
- Michael Braund, Ph. D candidate, York University
- Martin Walker, Studio for Progressive Modelling, Halcrow Yolles
Here’s a quick video of the component in action. There’s still a lot of work to be done.
The Studio for Progressive Modelling (SPM) has started development of a couple custom GH components:
This one produces a principal curvature line emanating from a point on a surface – lines that are useful for constructing panelizations of freeform surfaces consisting entirely of planar quadrilaterals and prismatic structural members. It has been proven that surfaces with these characteristics are significantly more cost effective. However, the aesthetics of these panelization schemes are often quite pronouced, and so this component is a light weight solution that allows designers to see what kind of principal curvature mesh a given surface might suggest.
See Evolute and Daniel Piker’s work in this area for other aspects of panelization with planar elements. I find the latter approach very interesting, as it does not depend on a setting out the curvature lines as an initial guess – even though these are fundamental to the construction. Or are they?
We’re also working on some Rhino to Revit/SAP links, and hope to post some information on those soon.