algorithmic modeling for Rhino

Over the last year it has been great to see an increasing number of people start to script their own custom goals for Kangaroo2.

To help with this I have just open sourced most of the code for the actual goals that are included as components in the Kangaroo2 plugin.

Hopefully seeing how the existing ones work will be useful to some of you as a starting point for customizing or extending them. It may also be useful when trying to understand how certain goals behave to be able to look inside.

You can find the repository here:

Please do ask here any questions you may have about how these work.

The commenting is currently fairly minimal, but I'll try and improve that.

You may notice that some of these goals  inherit from a class called GoalObject, while some of the older ones directly implement an interface called IGoal.

GoalObject is a helper class which saves you from having to implement all the methods in the IGoal interface, and it is recommended to use GoalObject when creating your own.

Views: 2412

Replies to This Discussion

To add to this - a few general guidelines when setting out to create your own goals:

-Remember, a Goal is something that given the current positions of a set of points, calculates where it wants to move those points to.

-The PIndex array is an array of integers, one for each point this goal acts on, giving its index in the particle list.

-The move vectors on your set of points should usually sum to zero (for instance the two move vectors acting on each end of a spring are always equal and opposite). This is because otherwise you could introduce unbalanced forces causing the particles to fly off into space. An exception to this is if you are pulling points towards some fixed geometry, such as a target mesh. In this case it is as though the fixed geometry has infinite mass, and thus whatever the reaction force on it, it will not be moved, so we do not need to calculate this reaction.

Would it be possible to know how Sphere Collide Goal works? :)

Hi Marcus,

I've actually made a LineLine goal myself. Attached is an example using it.

Your goal looked to be heading along the right direction with finding the shortest distance, but the action it produced was only one-way, without a balancing reaction, and without the distribution of momentum between the ends of the lines that causes rotation.

I'm not sure I follow what the intention is in the second file, but perhaps this new LineLine goal helps.


Thanks, Daniel, this works really well.

Is there a reason why it is not part of the standard distribution?

Hi Daniel, 

I have just tried to look through some old components I made and I am getting this error:

1. Solution exception:Unable to cast object of type 'ModInflate' to type 'KangarooSolver.IGoal'.

Any solutions? or have you swapped from GoalObject to IGoal?

All the best 


Hi Jens,

Is it possible the assembly reference is pointing to a different copy of the dll? Or the COFF option needs to be switched off?

IGoal is actually the interface which Kangaroo uses internally, and in very early versions, to make custom goals you needed to implement IGoal directly, but then I added GoalObject, an abstract class which acts as a base implementation of IGoal, so users only need to override the methods they are actually using (for example, you don't need to include an output method).

Custom goals should now always be written to implement GoalObject, not IGoal directly.

Hi Daniel, 

Thank you for the reply.

I will try your suggestions, I forgot to mention that I am trying to do it in the new Rhino6 beta version, I dont know if you think that has any implications?


Just resaved my files for Rhino 5 and then there is no problem. 


I was trying to get inspired by the Plastic Length Goal to developp another goal, but I don't manage to use the Plastic Length script properly.

There are no error messages but the plastic deformation does not work when the endpoint is pulled. It seems that the loop

if (Stretch > Limit)
{ RestLength += Stretch - Limit; } ...

is not actualizing the RestLength.

Does anyone knows how this could be fixed ?



Hi Ludovic,
That is strange, as the actual goal code is identical.
Your script goal does sort of work when I run it - it deforms if stretched enough, but not the same behaviour as the compiled version.
I suspect this has something to do with the way the Plastic Length goal modifies its own variables during iteration, which is unlike most of the other goals.

One possibility could be to declare the instance of the goal outside the main RunScript and have a reset button.

Like this:


By the way I found a division by zero in ConstantTension component which explains why the solver collapse when CT length is null.

A way to fix it :







  • Add Photos
  • View All

© 2021   Created by Scott Davidson.   Powered by

Badges  |  Report an Issue  |  Terms of Service