This article describes some methods for the optimization of the Grasshopper definitions aimed at reaching a relationship between control parameters and geometry movements that is as quick and as smooth as possible.
This kind of optimization in GH could not be considered crucial if the purpose is to define a fixed shape that derives from a certain configuration of parameters. In this common scenario, a delay of a few milliseconds in the computation between one variation and another during the form-finding process should not cause a big headache to the designer. What we intend to do here, though, is real-time streaming of potentially always-changing computed geometries within the VR scene. Why are we doing this?
Because to maintain the dynamic aspect of the definitions we generate, and to provide the possibility for the user to load their definitions in the VR space (a future feature of our app), we have chosen to rely on a software tool called Rhino Compute. Rhino Compute is an API (Application Programming Interface) that allows you to create Rhino geometry via a Rhino Compute Server. In other words, by “talking” with the server you can create Rhino geometry within your application, letting all the hard work be done by the server and not by the device itself. Compute is built on top of Rhino 7 for Windows and can run anywhere Rhino 7 for Windows can run. It’s available as a cloud service and it can even be installed on a local user’s computer. This is a very interesting project from McNeel Group because it does not require you to have Rhino installed on the device you are using, allowing even mobile devices, or in our case the Oculus Quest, to have access to a large part of Rhino’s functionality. Rhino Compute is based on Rhino Inside, an open source technology that allows for the possibility to run Rhinoceros and Grasshopper inside 64-bit applications.
Everything in GH can be done in different ways… well, not really
These features require the consideration of several aspects related to the correct and efficient functioning of the Grasshopper script, to be dictated by the objectives of the project. Considering that our goal is to reach a fluid and comfortable experience, we must avoid the eventual lags of the computational process each time a Grasshopper slider is subject to a change. Starting from this consideration, it is necessary to operate on the scripting method of the Grasshopper algorithms in order to reduce substantially the computational time involved in the process.
The first step of the optimization consists of the usage of specific tools to manage the computational time requested by each Grasshopper component. Grasshopper provides a widget called Profiler which measures and shows the time spent to solve the components and to transfer data between them. Another useful tool is the plugin Metahopper, which provides advanced analytic features such as the Bottleneck Navigator.
Once it’s possible to measure the size of the algorithm in computational terms, the scripting method can advance towards the choice of the right components and towards a generative approach. This has the aim of not only the final visualization but of the high computational speed of the geometries. The strategies applied to our test geometries come from a deep analysis of the performances of Grasshopper and from a pure mathematical approach, starting from an interesting and useful article written by the ShapeDiver team that is available from this link. The issues can be laid out as follows:
- N.U.R.B.S. surfaces require great expenditure of memory, because of the breadth of their needed calculations and their strong impacts on the visualization. It is desirable to work directly with meshes which are by definition lighter and simpler entities. Moreover, software such as Unity does not support N.U.R.B.S. surfaces but supports meshes. Modeling with N.U.R.B.S. requires an additional step for the conversion of the geometries into meshes, which is the heaviest computational operation and often leads to cluttered output.
- The ShapeDiver Team makes available to users some C# scripts which perform generative operations not included directly in Grasshopper, such as the Loft Mesh, which allows generation of a mesh as a loft through curves. It is also possible to use external Grasshopper plugins aimed at generating and managing meshes as Pufferfish, Weaverbird, WombatGH, Mesh Edit, Mesh+ and so on. Additional scripts are made by us.
- The intersection between geometries is another very expensive category of operations in terms of computing time, depending on the number of elements to be intersected. An efficient alternative comes from mathematics, preferring an approach based on geometrical relations and vectors.
- When performing intersections, it can be useful to disable the Grasshopper Parallel Computing which seems to be mainly effective for great amounts of data. This advice should be seen as something strictly related to the purpose of the specific project and to the features of the computer or the server that performs the computation. Indeed, sometimes Parallel Computing is the best choice, so use it with moderation and care.
- Almost always, the sentence “Everything can be done in different ways” is misleading because some paths are better than others. For instance, when performing transformations, it is a good practice to merge them together with the native Grasshopper component called Transform. This is accompanied by the Compound component, aimed at the matching of different transformations, instead of using independent transformations in sequence. Another example with the same logic is the calculation of a centroid, allowed by the generic Area component which is always more expensive than other components such as Polygon Center.
- It is crucial to clean and adjust the output meshes as much as possible, in order to relieve the interpretation work carried out by the game engine. It is strongly recommended to use the Combine&Clean component of the plugin Kangaroo Physics, which removes unused and duplicate vertices of the meshes.
- The last operation is a general reduction of the unnecessary components. This step, of course, is not a big deal but a good practice of refining.
Smooth is more
The optimization strategies applied to the Grasshopper definitions allow the exchange between Rhino Compute and the VR scene in an extremely smooth manner, reaching a nearly instantaneous overall computational time. Notice that the procedure applied to our test geometries is made using these strategies.
Below you can better understand the comparison between the conventionally scripted algorithm, which reaches the final geometry regardless of its smoothed dynamic properties, and the optimized algorithm – both referring to the Folding Wall test geometry. The latter not only looks more pleasing to the eye but should even help to avoid simulation/sensory sickness within the VR experience. Following the strategies shown above, you can reach a high geometrical complexity fully governable in VR, without renouncing an overall smooth and pleasant experience.
Pio Lorenzo Cocco, November 24, 2020
Cover image
Walter De Maria – Apollo’s Ecstasy
20 solid bronze rods (1990)
The encyclopedic Palace, Arsenale, Venice Collection Stedelijk Museum Amsterdam. View of the installation, 2013
Photo by John Volpato.