Does Kangaroo handle data trees?

Hello Daniel,

I was testing something out to see if it could work in Kangaroo. Its just a simple spring + unary force definition. In the main kangaroo component, I plug in the force objects and the anchors. For one mesh, this works well. I have just two things going into the Kangaroo component: forces and anchor pts.

What I wanted to try is feeding the Kangaroo component two branches of forces and anchor points, properly structures as {0} and {1}. So I have the forces for one mesh in branch {0} and for the other mesh in branch {1}. I have the anchors for one mesh in branch {0} and for the other mesh in branch {1}. Unfortunately, it seems that Kangaroo makes it all work together. Was kangaroo never designed to work like this? Could it work like this? Am I missing a key step?

I just found myself replicating certain things at certain times. In this case, I could just join the mesh into one and send out the anchor points. But I was wondering for other situations...

Replies to This Discussion

Permalink Reply by Daniel Piker on February 16, 2012 at 2:49pm

Hi Luis,

I'm not quite following what is the result you are after.

Do you want to have 2 different parallel non-interacting simulations happening through the same Kangaroo component ? What would this be useful for ?

The only Kangaroo input that currently uses Tree access is the Geometry input. All the others have only Item access.

As you know, normally with item access inputs on a component or script, if you provide that input with a list or a tree, it behaves roughly as though you have multiple separate copies of the same component with each of those branches or list items as an input.

However, because I store information (such as particle positions) between iterations, it looks as though trying to use multiple branches for things like the Kangaroo Force input doesn't work, because the data from separate branches ends up mixing.

One time this is useful is that you can provide 'Reset' with a list of 'True,False,False,False...' and get multiple frames or instants in time as an output (and I guess this shows that it is not really keeping things separate like with other components, because each item in the list is using the result from the previous item).

If you want to simulate several things in parallel (e.g. relaxing 10 different meshes at once), you can always just input them all into the same simulation, but don't include any interactions between them. If you need to keep the results in separate branches for downstream operations, then you can do so using the Geometry input.

So I can't see much advantage in being able to have different simulations running in different branches - except maybe if you wanted to do something like run each of the relaxations with a different timestep - and this currently doesn't seem worth the headache it would be trying to get all the paths to operate separately. Though if you have a compelling reason why it would be useful then I'd reconsider.

I hope that makes things clearer

Permalink Reply by Luis Fraguada on February 16, 2012 at 3:04pm

The only clear compelling reason is just so that things sort of match the default component behavior. But really, this is only a reason because the situation I was working on could definitely be done on one component, just needs to be organized appropriately.

The example I posted about above was just illustrative, and could easily be done in one go. What I was really working with were different clusters of objects which all had some sort of relationship, but not to every other object. So I was treating each cluster in a different kangaroo component. Actually, thinking further, it was probably just lazyness on my part, as all of the objects interact in some way eventually.

Let me work further with it and see if there actually is another compelling reason besides to match general gh component behavior.

thanks for the reply! hope all is well...

RSS