A couple of months ago, and a couple of weeks ago I have presented a quick primer of Python scripting on the Revit Platform at the Manchester and London Revit User Groups. Both have been fantastic experiences, summarized the evening I was having a beer (or #BIMbeer) and heard someone say "I've been told that the other day there was an interesting presentation on Python at the Manchester Revit User Group", to what I replied "That was me, thanks!".
My main objective is to trigger curiosity and push at least some people to discover that the programming edge is not that hard to climb, and things appear much nicer from those heights. I have to clarify that among non-programmers I can pretend to be one, but in all ernesty I am a wannabe noob of a programmer, despite a few lines of code I cannot understand does not stop me from trying to understand it!!
Following a recent request on Twitter to share the presentation and thinking that they are probably available somewhere, here comes a brief summary of that presentation with the most important part of it: a list of resources to start learning Python and implement it on the Revit platform (that means that whenever I say "Revit" in the following lines I mean any flavour of Revit including Architecture, Structure, MEP and even Vasari)
First of all, Computational Design could be a logical evolution of using computer power to draw (CAD), then to Model (BIM), and finally to simulate/manipulate design in more complex scenarios. Not necessarily a knowledge you need (yet) but something that could come particularly handy.
To be able to have computers "actively help" in the design process a few aspects need to be covered:
As a designer/programmer, you are still in control of the direction of your computer program, regardless of the complex or far-fetched result you may achieve or the number of steps in between. Don't trust the magic "create project" button or the black-box process spitting out magical results. Behind them someone has made the concious decision of following very specific steps, and the output is driven by them.
Some ideas that come to my mind in terms of how to use scripts are:
Obviously this is where language comes in, because we are giving the computer directions. And it needs to understand them. I see three levels of communication here: first, a way of giving a bunch of directions directly to your software (think AutoLISP or RhinoSCRIPT or even MACROS in Office). Second, a program running inside your application. A great advantage of this communication is that it enables a different interface, like a graphic environment (think Dynamo or Grasshopper). The third one is enabled through a communication channel talking directly to the software (via the Application Programming Interface, the infamous API!) that enables an external program. So you can create a "shortcut" on Revit that will trigger your script to run.
Revit API is based on .NET Framework. What that means I don't understand completely... because to some extent I am not a programmer. The biggest turn-down I found in the .NET languages is that you have to 'compile' them before running, and the compiler will check it for integrity before accepting it. But as Python does not need the compilation step (it's basically a text file that the computer reads step by step) it will run until it does not know what to do, and I found a great satisfaction in the fact that SOMETHING happened when I run my scripts. I found Python fairly easy to learn and being able to see changes is probably why I got a bit further than all I could do on VB or C++. So the implementation of RevitPythonShell, that enables Revit to follow Python scripts was the entry point to test it on a model, yet I feel I am only scratching the surface!
http://learnpythonthehardway.org/
It mentions there are several variations of Python (you can have more than one installation). Revit will work if IronPython is installed:
ironpython.net/
You need to download the RevitPythonShell:
http://code.google.com/p/revitpythonshell/
And set it up to work with Revit. The following guide from Zach's BuildZ is specific to Vasari 2.1 but it sets the principles:
http://buildz.blogspot.co.uk/2011/09/python-scripting-in-vasari-21.html
Once that is in place you are ready to go!
Take a look at the datasets I used for the MRUG and the LRUG meetings below:
2012-06-20-MRUG-Dataset
2012-11-21-LRUG-Dataset
If you have not been to the User Group meetings, I recommend to look at the London one, as it happened a few months later I prepared a "module" for a more advanced implementation. Otherwise compare the two. Also notice that some file addresses are absolute (that is, Python will look for them at a specific path, I encourage you to change the code as needed)
To learn more, and have a lot more fun, here's more learning resources:
http://www.diveintopython.net/
http://www.codecademy.com/tracks/python
I'd like to acknowledge their contribution to my understanding of this topic and publicly thank Daren Thomas, Zed. A. Shaw, Zach Kron, Mark Pilgrim, Jeremy Tammick, Nathan Miller and Matt Jezyk. Their generosity in sharing knowledge is a great step towards making better design!
Next up, I'll be sharing some more Python stuff, including an IFC interpreter I'd like to make work on the RaspberryPi!
My main objective is to trigger curiosity and push at least some people to discover that the programming edge is not that hard to climb, and things appear much nicer from those heights. I have to clarify that among non-programmers I can pretend to be one, but in all ernesty I am a wannabe noob of a programmer, despite a few lines of code I cannot understand does not stop me from trying to understand it!!
Following a recent request on Twitter to share the presentation and thinking that they are probably available somewhere, here comes a brief summary of that presentation with the most important part of it: a list of resources to start learning Python and implement it on the Revit platform (that means that whenever I say "Revit" in the following lines I mean any flavour of Revit including Architecture, Structure, MEP and even Vasari)
First of all, Computational Design could be a logical evolution of using computer power to draw (CAD), then to Model (BIM), and finally to simulate/manipulate design in more complex scenarios. Not necessarily a knowledge you need (yet) but something that could come particularly handy.
To be able to have computers "actively help" in the design process a few aspects need to be covered:
1. Know what to ask
Computers are good at following orders ("Computers do what we asked them to do, which is not always what we want them to do"). If we break the "path from A to Z" into a series of steps, we have suddenly become programmers and the sequence becomes our Script or Algorithm. This is not an over-simplification of Scripting (nobody said those steps would be easy or that the sequence could be extremely contorted), but a demystification aiming at tempting you, the reader, to dare become a programmer. (mind you, since I started programming I am growing a beard and I am talking about Linux... so it might be a one way road!)
As a designer/programmer, you are still in control of the direction of your computer program, regardless of the complex or far-fetched result you may achieve or the number of steps in between. Don't trust the magic "create project" button or the black-box process spitting out magical results. Behind them someone has made the concious decision of following very specific steps, and the output is driven by them.
Some ideas that come to my mind in terms of how to use scripts are:
- Minimize Repetitive Task Injuries
- Reuse common task definitions
- Deliver faster
- Open up to hundreds of options
- Explore new approaches to design
2. Talk to the machine
Obviously this is where language comes in, because we are giving the computer directions. And it needs to understand them. I see three levels of communication here: first, a way of giving a bunch of directions directly to your software (think AutoLISP or RhinoSCRIPT or even MACROS in Office). Second, a program running inside your application. A great advantage of this communication is that it enables a different interface, like a graphic environment (think Dynamo or Grasshopper). The third one is enabled through a communication channel talking directly to the software (via the Application Programming Interface, the infamous API!) that enables an external program. So you can create a "shortcut" on Revit that will trigger your script to run.
3. Speak the language
Revit API is based on .NET Framework. What that means I don't understand completely... because to some extent I am not a programmer. The biggest turn-down I found in the .NET languages is that you have to 'compile' them before running, and the compiler will check it for integrity before accepting it. But as Python does not need the compilation step (it's basically a text file that the computer reads step by step) it will run until it does not know what to do, and I found a great satisfaction in the fact that SOMETHING happened when I run my scripts. I found Python fairly easy to learn and being able to see changes is probably why I got a bit further than all I could do on VB or C++. So the implementation of RevitPythonShell, that enables Revit to follow Python scripts was the entry point to test it on a model, yet I feel I am only scratching the surface!
4. Enough talk. Now get started!
You need to set up your computer to be able to run Python, and know a bit of the language. I found the following book a great source of knowledge and a great step-by-step starter:http://learnpythonthehardway.org/
It mentions there are several variations of Python (you can have more than one installation). Revit will work if IronPython is installed:
ironpython.net/
You need to download the RevitPythonShell:
http://code.google.com/p/revitpythonshell/
And set it up to work with Revit. The following guide from Zach's BuildZ is specific to Vasari 2.1 but it sets the principles:
http://buildz.blogspot.co.uk/2011/09/python-scripting-in-vasari-21.html
Once that is in place you are ready to go!
Take a look at the datasets I used for the MRUG and the LRUG meetings below:
2012-06-20-MRUG-Dataset
2012-11-21-LRUG-Dataset
If you have not been to the User Group meetings, I recommend to look at the London one, as it happened a few months later I prepared a "module" for a more advanced implementation. Otherwise compare the two. Also notice that some file addresses are absolute (that is, Python will look for them at a specific path, I encourage you to change the code as needed)
To learn more, and have a lot more fun, here's more learning resources:
http://www.diveintopython.net/
http://www.codecademy.com/tracks/python
I'd like to acknowledge their contribution to my understanding of this topic and publicly thank Daren Thomas, Zed. A. Shaw, Zach Kron, Mark Pilgrim, Jeremy Tammick, Nathan Miller and Matt Jezyk. Their generosity in sharing knowledge is a great step towards making better design!
Next up, I'll be sharing some more Python stuff, including an IFC interpreter I'd like to make work on the RaspberryPi!
Comments
Post a Comment