HoopSnake, apart from a legendary creature, is simple component for Grasshopper. What it does in principle is to create a copy of the data it receives at it's input upon user request and store it locally. This duplicate is made available through a standard Grasshopper parameter output.

What turns this operation from mundane to actually promising is the fact that the input of the component includes some custom programming to escape Grasshopper's recursive loop avoidance check.

What this means in practice is that it is possible through the use of HoopSnake to send the output of a set of components back to it's input in a looping fashion. With the help of a little bit of Data Tree / Data List manipulation, this should open up some new possibilities for iterative process modeling.

Now, iterating in that sort of way is fundamentally opposite to Grasshopper's operating principles. In order to bridge the gap between the two different paradigms and treat Grasshopper nicely, HoopSnake bases it's function on a controlled-loop behavior. What this means is that the loop is not triggered automatically, but on user request. Once started, it can either perform a single step (triggering a new solution at the output and recording the new input) or a continuous loop, each time generating a new solution based on current output data fed back to the input of the component set.

Furthermore, this loop can be stopped at any point either by the user or automatically by setting a termination condition (the third input of the component) to false. This way, an operation mode quite similar to a "while" loop can be modeled in Grasshopper, without any coding. This is beneficial primarily to the clarity of a definition, since it enables the exposure of an iterative solution's logic outside a scripting component.

Of course, the component doesn't come without drawbacks: The fundamental one is that the process is slow. Visually it may not seem so, but in terms of computational efficiency* it's an overkill. But if you plan your loops carefully so as to avoid huge amounts of iterations, it should be no problem.

Second one is that the data stored within HoopSnake is not serialized (saved) and therefore not persistent. Once you've closed your document, you'll have perform the iterative process again.

Operation

Hoopsnake has 4 inputs:

• S : Starting value
• D* : Feedback value. This can be connected anywhere (including forward components)
• B* : Control value. Can be also connected anywhere and will look for boolean values.
• T* : Trigger input. This forces it's owner component to take over any ongoing looping whenever it encounters a change in it's input data. It makes possible for multiple components to be linked together in a recursive or serial fashion (Please keep in mind that this is an advanced and experimental feature).

The component unassumingly gets the data from the D* input (or the S input if D* is empty), stores it locally and outputs it through a standard Grasshopper output parameter. This process can be looped, with the boolean input at B* acting as a control switch (when it becomes false the loop stops). In this sense, a controllable loop can be produced, which is based on persistent data and does not need to run every time a calculation is re-computed.

With the download file examples of various Hoopsnake configurations are included.

Some experiments by Garcia del Castillo.

And here are some recent experiments at SketchyGrid.

The latest version of Hoopsnake has been found to work with Grasshopper v0.8.0051.

Hoopsnake couldn't have been made possible without the fruitful discussions with Pirouz Nourian and Michael Bittermann.

Hoopsnake is licensed under a Creative Commons Attribution-NonCommercial-NoDerivs 3.0 Unported License.

HoopSnake is and will remain free for educational and personal use. However, it's development requires a significant amount of time and effort. If you find it useful in any way, please consider supporting by donating.