Visualize an Object Classification Network with Crow for Grasshopper

Monday 19, February 2018

Crow exposes artificial neural networks in Grasshopper, offering supervisde learning through backpropagation networks and unsupervised learning through self-organizing maps. As mentioned by Pennjamin (developer of FlexHopper and Crow), "The new feature let's you visualise network training in real time. [In hopes of] better intuition on how to setup a good network topology." The video shows the classification of fruit-like shapes, but more complex tasks could be achieved with this tool.

It's exciting to start seeing the introduction of machine intelligence algorithms in tools like Grasshopper and Dynamo.

RhinoGrasshopperArtificial Intelligence

The Hard and the Soft Way to Work with Grasshopper References

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.

ParametricGrasshopperWorkflows

Grasshopper Workflows

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.

GettingArchitectureDoneKit

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.

GADWorkflowBake

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).

GADWorkflowDictionary

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.

ParametricGrasshopperWorkflows