If you follow either myself or Matthias on twitter you may have seen that we were ‘living it up’ in the great city of Philadelphia last week. Home to the Liberty Bell and all sorts of reminders as to where my native land went wrong and some of its big mistakes….
Having said that the city seems a wonderful place and it helped our experience staying in the historic core of Philadelphia where all the good restaurants and bars are. The food was wonderful and the people were friendly.
Enough of the travel guide! We were there to help and support the work of students on their design charrette on Philadelphia University’s GeoDesign Masters Program. The M.S. in GeoDesign was the first of its kind in the USA, and come to think of it probably the world. You can read more about Geodesign elsewhere but for all practical purposes it’s about collaborative workflows and coordinated iterative processes across disciplines. It’s heavily influenced by new technologies like Esri CityEngine and has a strong supporter from Esri as well as a string of notable academics.
Garsdale Design (Matthias and I) were there to provide additional support, troubleshooting and advice on CityEngine and Geodesign workflows. We had already provided remote assistance to elements of the course around technical aspects of CityEngine, so we were familiar with the students and the program.
As with all projects academic or ‘real-world’ collaboration in a team is critical. In such a small amount of time the students had to focus on a design goal on chosen study areas, and come up with workflows and analytical processes to measure metrics to help them design. They were designing using software like ArcGIS, SiteOps, AutoCAD and CityEngine and merging it into one cohesive process. Towards the end of the week the students had focused in on achievable goals and worked out workflows that were easily repeatable and produced metrics that would help inform there design choices. I won’t go in to detail what these all were as it is there project and is best heard directly from them when the are ready.
One clear thing came out of this charrette for me was that most software (especially CityEngine) works best with focused tasks and simplified processes. For example when you first work with CityEngine the tendency is to think it can do many things, which it can. But trying to combine all those tasks into one is often a mistake, keep the workflows as simple as possible is much better for everyone.
Believe it or not, but this whole scenery was created procedurally. In e-on software’s VUE.
This image is the result of an 8 week online (yes, late evenings and weekends!) 3D Workshop I just recently completed (my second already) on CGSociety.
Everything is procedural: The terrain model, the vegetation (each plant plus the distribution), the volumetric clouds and haze. Even the main attraction: The almost too well hidden villa. The villa is a procedurally generated model coming from CityEngine, which was manually placed.
Rendering this single image took about 26 hours on my quite fast hex-core machine. Minimal post work was done in PhotoShop.
Imagination is required to use CityEngine, I’ve said this before and I say it a lot in our 3DPathFinder CityEngine training sessions (shameless plug). The power of the rule file is in it’s ability to be used in other contexts and is often only limited by your imagination. Some of what I think Geodesign is also about this, connecting up other peoples workflows, joining disciplines together to form a coherent team.
Take the humble rule that places a parapet around a roof top and places a satellite dish inside, this is the same rule that I use to make my infamous “procedural sheep”. Get your head around that and the world is yours (in a metaphorical sense).
This leads me to a little rule file I adapted yesterday, my colleague and friend Matthias had created a couple of rule files for a client (Philadelphia University’s Geodesign course). One rule file coloured a surface depending on the steepness of a slope, which clearly when drawing a path or a road can be useful. The other rule file was one that placed arrows facing down a slope in a grid pattern, think about water run-off and this is cool, useful stuff.
A topical visualisation today after I wondered whether I could do this whole flood map thing in 3D. What I’d really like to do next is have the rule file change the building colour as the water level rises… It can be done just not very nicely. It also demonstrates the real potential of CityEngine to become a responsive Geodesign tool.
Yes you can do this all in other packages but in CityEngine I can change the flood height variable and the model changes pretty much instantly (video to come). I’ve obviously done some pre processing work in ArcGIS to allow for it to work in CityEngine.
This is a fun quick tip, instead of assigning a specific colour to each floor and building when not use the built in colorRamp function. Search for it in the help file for detailed usage here’s how I’ve used it:
I’ve taken a centre point and coloured the rooftop of each building using the colorRamp function. Basically it checks to see how far it is from a chosen point (fixed in the rule file) and normalises it so the value is between 0 and 1 and then uses that value to pick a colour in the depending on your chosen colorRamp.
I’ll be holding an introduction to CityEngine workshop at GISWORX ’13 this year entitled “Using CityEngine for Urban Planning (the Instant City in practice).
I’ll introduce attendees to the basics of CityEngine and how I use it in a city master planning context. I will outline a couple of rule files that create quickly an urban block model with details such as building facades and lamp posts.
The second part of the workshop will take you through our process for creating and visualising a city neighbourhood in realtime from taking real GIS data through to rendered visualisations.
Hopefully I will also have the time to show attendees how they can share their models on line and off line.