Skip to main content

Getting along with Grasshopper on a mac


I have slowly began to learn Grasshopper (and Rhino with it). But as a Mac user, it is a bit cumbersome to launch Parallels and wait several minutes before the whole systems is operational and responsive. Once it it fully launched, it is workable.


But I have a conceptual issue with Grasshopper. I am experienced with programming in code (C++, php, Java, VBA and a tiny bit of Ruby and Python). There are so many things that I can easily write in a one or two lines of code that take a lot of nodes in Grasshopper to do so. And the whole thing becomes a mess... But replacing this with a scripted node will make the whole thing hardly legible.
  • I guess I need more practice: e.g. learn how to use the remote control, to put independent groups of nodes apart, so they don't overlap.
  • I also try to use groups, but did not find how to ungroup or how to add new nodes into an existing group.
  • And I still don't get how to combine several nodes into a smaller unit, to make it more reusable.
Now I sometimes want to repeat a series of nodes, to make the solution more legible, as not to have nodes inside another part of the solution linked in between all the others.

My main gripe: for small constructions, the visual node-connection framework is nice, but when complexity arises, it is really hard to "read" the network. Adding descriptive names is one part of the solution, but then nodes become very tall and the layout suffers.

All in all, I would like to see additional attention be put into osx-compatibility and in the legibility of the visual network. I know that Puredata/MAX have always been designed with the idea that the visual code would also show all you need to know. Now many settings and parameters are buried inside the nodes.

But to end with a positive node, you can get nice results too. The image here is rendered with Cinema4D from an OBJ file exported from the baked Rhino geometry.

One quality this example had: the two main steering parameters led to widely differing results, even with small adjustments. So the range of forms this one script could generate is endless.

But I had to turn of some nodes, as the generated geometry became quite heavy.

Comments

Popular posts from this blog

Improve usage of BIM during early design phases

When I was collecting ideas for a book chapter on BIM (that seemed to never have emerged after that), I collected 10 ideas, which I believe still reflect good recommendations to improve the usage of BIM during the early design phases. These ideas are related to BIM software, but you can apply them in any flavor, as long as you can model with Building Elements, Spaces and have control over representation. Introduction This article gives an overview of several recommendations and tips, to better apply BIM applications and BIM methodologies, in the context of the early design phases. Many of these tips are applicable in any BIM application and they are based on experience gathered from teaching, researching and using BIM software. Sometimes they could help software developers to improve the workflow of their particular BIM implementation. Tip 1 : Gradually increase the amount of information In the early design phases, the architect makes assumptions and lays out the main design in...

Getting BIM data into Unity (Part 9 - using IfcConvert)

This is part 9 of a series of posts about getting BIM data into Unity. In this post, we’ll discuss the IfcConvert utility from the IfcOpenShell Open Source IFC Library to preprocess an IFC model for integration with Unity. This is (finally?) again a coding post, with some scripts which are shared to build upon. Conversion of IFC into Unity-friendly formats The strategy with this approach is that you preprocess the IFC-file into more manageable formats for Unity integration. Most Web-platforms do some sort of pre-processing anyway, so what you see in your browsers is almost never an IFC-file, but an optimised Mesh-based geometric representation. However, it wouldn’t be BIM-related if we’d limit ourselves to the geometry, so we will parse the model information as well, albeit using another, pre-processed file. IFC to Wavefront OBJ I used a test IFC-model and used the IfcConvert-utility converted it into OBJ en XML formats. The default way to use it is very simple: ...

PythonOCC : Open Source interactive CAD shell (and how to run it on OSX)

What is PythonOCC? PythonOCC is an Open Source (LGPL) Python-wrapper for OpenCASCADE. So what is OpenCASCADE (OCC)? This is an advanced Open Source (custom license) modeling kernel, comparable to commercial engines, such as ACIS or Parasolid, which are used in quite some commercial CAD programs. When you want to develop CAD software, you could use OCC and write programs in C++. And why using Python? With this wrapper, you can create CAD and geometry scripts in Python, which is an interpreted Object-oriented scripting language. You can write almost "on-the-fly" and seriously reduce the implementation effort, by skipping the compiling-phase. You can even interact with a running program in the Python interpreter. Want to read more about this? The OpenCASCADE official website  (currently Linux and Windows are officially supported) The PythonOCC website/blog  (beware that the core of the actions happen in the development repositories). So far so good. Now the nasty, techn...