Kangaroo2 - scripting custom iteration - examples

I'm going to post here some examples of writing simple C# scripts which use the Kangaroo library for custom iterative behaviour. While I have posted a number of examples of custom goals before, so far I've not shown much about such custom looping.

This can be useful because it allows you to make changes in topology (such as which goals act on which particles, or the number of particles in the simulation), which would be difficult or impossible using only the standard components.

Please let me know if you have any questions about these files, or requests for other types of examples.

For all of these scripting examples, the first time you open them you will need to set the location of the KangarooSolver.dll on your system.

I think the easiest way to do this is to use File>Special Folders>Components Folder to navigate to your libraries folder, and copy the path. Then right click the script component on the canvas, and Manage Assemblies. Select and delete the KangarooSolver reference which is there, then choose Add, paste the path you copied earlier, and select your local copy of KangarooSolver.dll

After you have done this once, it should be easier with future files, as the dll will then show up in the recent assemblies tab, and you can simply drag it over.

Example 1: AddingPoints.gh

Starting with something simple - this takes a collection of points, pulls them to a mesh, with collisions between them, and adds a new point at each iteration. Note that here the PhysicalSystem object is actually being created anew at each iteration, with the point locations the only thing preserved between iterations.

Example 2: GrowingLine.gh

This is an updated version of a file I previously posted here. I've cleaned it up a bit to hopefully make it easier to follow. Unlike the first example, this actually maintains the physical simulation from one iteration to the next. It includes a custom goal for the collisions, as the one in the current compiled component did not have a constructor allowing you to assign the Indexing directly.

Comment

You need to be a member of Kangaroo to add comments!

Comment by David Bachman on March 1, 2017 at 3:08pm: Just a quick note that I was able to modify the "Growing Line" Kangaroo/Anemone script further to make a "Growing Sphere" script. Details are here and also on my blog here.

Comment by Pieter Segeren on February 27, 2017 at 3:32pm: Thank you for your kind reply Daniel. I think I sort of 'feel' (excusez le mot) what you are saying ... but really - I don't comprehend:
I would have thought that the transformations would only be calulated at a different rate, but the same outcome would occur every time I (re)run the simulation. Is that a misunderstanding then? (appearantly...)
Is it the case that the same outcome does in fact occur, but it might not be the last iteration just before the magic 15 ms feedback/interaction limit elapses? How does time change the underlying math to be done?

Comment by Daniel Piker on February 27, 2017 at 4:29am: @Pieter - interesting observation. I think what is happening here is due to the way the timer on the input is interacting with the solver's internal timer.

The default K2 solver actually runs multiple iterations for every output frame (because outputting and drawing the geometry typically takes much longer than just calculating an internal iteration). The exact number of iterations performed depends on your system - it keeps iterating until reaching 15ms then outputs the result. So for a very simple simulation it may be making hundreds of internal iterations for each one you see on screen, allowing it to converge quickly, whereas for a large complex simulation it might make only 1 or 2 iterations in that time, but it still tries to maintain a reasonable framerate for the sake of feedback/interaction.

The exact processing resources available on your system fluctuate due to other background windows processes, which also causes this number of iterations to vary over time. Since in this example, the rate of growth of the line is controlled by a separate timer, the number of steps it has to relax before growing again therefore varies, explaining the different results.

I'll actually post soon another example of how to make goals which vary over the course of the simulation in a way that is tied to the number of iterations performed.

Comment by Pieter Segeren on February 24, 2017 at 3:42pm: Very nice David! And of coarse: very nice Daniel!
About the 'GrowingLine': I wonder what causes the different results, without changing any parameters... is it just different floating point errors?

Comment by David Bachman on February 23, 2017 at 9:45am: For those who would prefer to avoid writing code, I was able to recreate Piker's GrowingLine script by putting Kangaroo inside an Anemone loop. Details are in the post here.

Comment by Daniel Piker on October 28, 2016 at 5:25am: Hi Cylin,

It looks like it is not successfully loading the KangarooSolver.dll. Presumably the standard K2 components are loading and working without errors? Are you setting the assembly reference location to the same copy of the file which Grasshopper is loading? ie the one in the Grasshopper libraries folder. If you select a different one (such as a copy in your downloads folder), it could cause problems.

Comment by cylin on October 28, 2016 at 2:18am: Hi

I have set the location of the dll file, but I still got some errors.

It seems that something is still missing.

Is there any setting or libraries which I should take care?

Thanks.