Kangaroo Version 2.3.0

Version 2.3.0 is now available on Food4Rhino

Changes:

Various minor bug fixes
Anchor component now has separate inputs for initial and target locations. This simplifies the setup when you want to have an anchor which moves parametrically during simulation, avoiding the need to always move it back to its initial location on resetting.
Goal tab grouping - with the ever growing number of goal components, I felt they needed a bit more organisation. Hopefully the categories make things easier to find.
Wind goal component. Apply a wind vector to a mesh.
Assembly mate components: Concentric and AlignFaces. These both operate on the rigid bodies that were introduced in the previous release. For those with experience in other mechanical software these should be familiar. AlignFaces is like what SolidWorks calls a 'coincident' constraint, but I felt this name helps distinguish it from the coincident points goal.
Bomb goal. For when you are feeling destructive! Note that since this goal has a state which changes with the number of iterations of the solver, it also has a reset input, where you should connect the same button you reset the solver with.

More example files to follow. Any questions or bugs please let me know below.

Replies to This Discussion

Permalink Reply by Daniel Piker on April 11, 2017 at 12:45pm

Permalink Reply by Anders Holden Deleuran on April 11, 2017 at 1:39pm

Kablammo!!! Could use that Jose Gonzalez cover version of Heartbeats as the soundtrack :D

Permalink Reply by 未知 on April 11, 2017 at 6:30pm

Look forward to more cases

Permalink Reply by Daniel Fink on April 11, 2017 at 10:39pm

Hi Daniel.

I'm getting "Unable to cast object of type 'KangarooSolver.Goals.Locator' to type 'KangarooSolver.IGoal'"-type errors on scripts that were previously able to run in version 2.2.1, maybe something went missing during compile? Pls advise...

Also, thanks for the new release!

Permalink Reply by Daniel Piker on April 12, 2017 at 3:25am

Hi Daniel,

Thanks for reporting this. Can you please post a definition where you are getting this error?

Permalink Reply by Daniel Fink on April 12, 2017 at 5:50am

I just tried to use a scripted component to solve the Origami example you posted. Still no luck...

Attachments:

K2_Origami_scripted.gh, 28 KB

Permalink Reply by Daniel Piker on April 12, 2017 at 5:54am

Try switching off the COFF loading option in GrasshopperDeveloperSettings.

When this is on it seems to interfere with communication between compiled and scripted Kangaroo components.

Permalink Reply by Daniel Fink on April 12, 2017 at 12:21pm

Thanks Daniel.

I managed to somehow fix the problem; I'm not sure why this was happening but there might be an issue with GH/RhinoWIP saving components to 'C:\Program Files\Rhino WIP\Plug-ins\Grasshopper\Components', and these were interfering with loading from the 'C:\Users\...\AppData\Roaming\Grasshopper\Libraries' folder... ! the COFF loading option didn't have an effect... Confusing...

I also tested the new components out in both WIP and v5, and there seems to be something wonky; I get different answers running the same script (and referencing same DLL) between both builds. Also eg, in the Origami example, in v5 hinge points component calculates fine, but in v6 it returns empty...?? Not sure if you are testing this in WIP, but maybe @DavidRutten can explain this behaviour?

v5 above

Permalink Reply by Daniel Piker on April 12, 2017 at 1:26pm

Mm, thanks for the details. With Kangaroo being included with GH in the WIP now, it looks like things are getting mixed up with the different dlls. That hingepoints bug is odd too. I'll have to talk with some of the McNeel folks to figure out what's going on.

When you say you get different answers with the same script between WIP/v5, was there some other case where this is happening apart from the hingepoints bug?

Permalink Reply by Daniel Piker on April 12, 2017 at 3:34am

Here's an update of the origami example for this version

Attachments:

K2_Origami.gh, 29 KB

Permalink Reply by paul hackett on April 12, 2017 at 10:11am

Great! Daniel, what about Orient Goals based on planes? I use magnetic goals, but this implies at least 3 points... Is the new anchor component the solution, or it doesn´t deal with plane origin - plane target? Is there any easier workaround that we are missing? Thanks!

Permalink Reply by Daniel Piker on April 12, 2017 at 10:20am

Hi Paul,

I'm not sure I follow the question. Can you give an example of what you are after?

The Transform goal lets you maintain a fixed transformation between a pair of points, and this can be an Orient type transformation.

Or are you talking about for rigid bodies?