Tuesday 28, July 2015
There is a fun component when working with computational tools in architecture: they are extremely flexible. They simplify a whole algorithmic world, letting us choose what to do with them.
Freedom and flexibility are great, but they can be a double-edged sword; too much flexibility might lead to solve a problem in multiple ways without a real improvement. Standardizing our ways of doing can speed up our work. Setting up workflows and constrains can save time and create space for creativity.
Two Types of References
When working with Grasshopper, the geometry used can be native from Grasshopper or referenced from Rhino. Either way, the operations we can perform with both types of geometry references inside Grasshopper are the same—the only difference resides in the origin of that geometry and the method used to reference it.
I like to differentiate among two ways of referencing Rhino geometry inside Grasshopper: hard references and soft references.
Hard references are manual references of Rhino objects from a Grasshopper component (created by right-clicking the Grasshopper component and manually selecting objects in Rhino). This references reference the objects directly by their guid (the identification number that Rhino uses to identify objects).
Soft references are references of Rhino objects through a geometry pipeline, where a Grasshopper component defines a set of object types and a layer filter to find objects in the Rhino document. This references use filters to search for objects inside a document.
I strongly recommend you to always work with soft references. When Grasshopper definitions start getting big, hard references can be your enemy; they are difficult maintain and can break a whole definition easily. On the other hand, soft references will make it easier for you to organize your Grasshopper references in a Rhino document. Here is how I do it.
By-Layer Reference Naming Convention
Every time I work with Rhino references in Grasshopper, I create layers using a naming convention to reference them from the geometry pipeline with ease.
I group all layers with soft references inside a layer folder named REF, and every layer under it is named with the prefix REF_ and a short description (using text and underscores to describe what kind of references are to be stored on them).
In Grasshopper, I create a geometry pipeline component for each of those layers, filtering by name, and, if known, by object type (point, curve, surface, mesh, or a combination of those).
After everything has been set up, we have Grasshopper geometry pipelines that “soft reference” the contents inside the reference layers. Changing the contents of those layers will update the reference and re-generate the Grasshopper definition using the new inputs. For instance, if you were to draw a set of curves where you need trees to be created each five meters, you would:
- Create a layer, named REF_Tree_Curves;
- Draw your tree curves inside them;
- Create a Grasshopper pipeline, setting the type to curves and the name to REF_Tree_Curves;
- Use that Grasshopper component (that contains all your curves) as the input of your tree-generating definition;
- Add, delete, or update your curves inside the REF_Tree_Curves layer;
- See the model update with your updated soft references.
Hopefully, this method will simplify your way of working with Grasshopper references, and allow you to create bullet-proof definitions which don’t get broken by hard-references. Thanks for reading.
Tuesday 16, June 2015
As happens with programming languages, Grasshopper is a really flexible tool. A given problem could be solved in many different ways, and each of those ways would be equally right, as Grasshopper is basically programming through a visual interface (of course, some solutions to that problem will be more efficient and optimized than others).
Through the daily use of Grasshopper, I found myself repeating tasks over and over—common tasks that were part of most of my Grasshopper definitions.
For those common tasks, I started developing generic Grasshopper definitions that contain just that—the workflows—and can be copy-pasted into bigger Grasshopper definitions when needed.
Workflows are ways to structure definitions for those frequently-performed tasks, or simply paths in which problems can be solved, in order to save time and optimize the way we do things.
Recently, I incorporated two of my workflows to the GettingArchitectureDoneKit, an open-source kit with utilities and workflows for common tasks in Grasshopper for Rhino. You can check the repository of the project on Github. Utilities are simplified or improved operations, and workflows are ways to structure your definitions to achieve certain things.
The first workflow I implemented allows to bake elements in different layers. A small group is created per objects' layer with a specific name, and all of them are later included under a group called Output.
I like maintaining the color used in workflow groups, so every time I copy-paste it to my definitions its color can be easily associated to a workflow.
The main functionality of the GADWorkflowBake is the Bake Component, part of the Elefront plugin for Grasshopper (a dependency of this workflow).
The purpose of the second workflow is to work with different parameter-sets inside a Grasshopper definition.
For instance, the file provided inside the kit has a file with various options for the width, height, length, and x variables of the definition. This way, you can work with different options in parallel, and switch among them just by changing a single connector.
I will be adding more workflows to the GADKit in Github as I create them. It is good to become familiar with this dynamic of abstracting the workflows you often use, to save time and optimize different processes.
Monday 20, October 2014
Earlier this year I found a new AutoCAD command I had never used before, the wblock command. With it, you can export Selected Elements of an AutoCAD drawing to a single file, keeping the Selected Elements on the file or removing them at the moment of exporting--depending on the option you select.
Three Simple Steps
- Select elements you want into a separate DWG file.
- Run the wblock command.
- Set the options on the menu as desired--exported file path, what to do with the selected elements after they have been exported.
The command has been really useful for me when exporting portions of a CAD drawing from AutoCAD to Rhino. Hope you find it useful.
Getting Architecture Done
This article is part of the Getting Architecture Done series. A series of posts about architectural methods, workflows and tools, titled . If you want to be notified when other articles are posted, go ahead an subscribe here.
Sunday 24, November 2013
Working time is commonly conceived as a time frame with no distractions. When you work, you are supposed to be as efficient as you can, and not let anything get in your way until you finish. It is widely known that some enterprises even block access to common distractions so workers don’t waste their time, but this is not a real solution.
Contrary to this model, deliberate breaks can improve your productivity while allocating a time for those distractions, which are needed by our brain in some way.
Why Deliberate Breaks?
Breaks are great. But I feel guilty taking too many of them. — John P. Trougakos
Deliberate breaks provide you with time to do things that are not strictly work-related and let your brain rest. Removing, at the same time, the guilt of distractions. Here, tasks and activities not related to work have their own span of time to happen.
Task Driven Blocks
My working hours are structured in fifty-minute working blocks and five-minute breaks, with the remaining five minutes as a buffer –which allows to slightly extend work or break blocks if needed.
Before starting to work, you should write down the tasks needed to get done and estimate how many hours you need for them. During working blocks, commit to switch off all your potential distractions, leave aside the non-work related stuff and capture them into a list to get done in the next break.
A Flexible System
The system I use is an adaptation of Francisco Cirillo's Pomodoro Technique®. After using it for a while I found that, for myself, one-hour blocks with five to ten-minute breaks in between work pretty well. You should find how the system better works for you. Let others know how you are working so they don't interrupt you in your working blocks –groups can even synchronize their work and break intervals so that interruptions are minimized and breaks are shared in between team members.
Breaks are breaks.
It’s not just a matter of being well rested. None of us can work flat-out, without breaks. — Ellen Galinsky
Breaks are periods of time in which you stop working on the main task and let your brain rest. Anything that is not the main task will be understood by your brain as a break –this is why a break can be from doing exercise, to read Twitter or to procrastiwork in a side project.
Usually, the best thing you can do for having an actual break is doing something different. If you work involves using the computer, don't use it during the break. If you work involves physical activity, don't exercise during the break. You get it.
Give It A Try
To be able to see if this method works for you: just try it. If you do so, and it is useful for your workflow, I would be glad to hear about it. Also, last month I developed Everfocus for iOS, an app that allows you to control your work and break blocks, currently on the App Store.
Thank you for reading this, to the HelpMeWrite community and supporters for pushing the idea behind this post forward, and to the #sundaypost initiative.