C# Mover Trails + Kangaroo2

Replies to This Discussion

Permalink Reply by Daniel Piker on February 4, 2016 at 11:21am

Hi Petras - Interesting definition!

I think it would probably be faster to actually call the Kangaroo library from within the same C# script you are using to add the elements. Have a look at the scripting examples in the Kangaroo download folder.

Just adding the goals through code instead of components will probably speed things up significantly, but to further improve it you could also manage the particle indexing directly.

Normally Kangaroo handles all this automatically - searching for pairs of coincident points to combine into single particles so that elements are properly connected. However, this searching does have a time cost, and if you are creating the elements through code, you can avoid this because you know the appropriate indexing already.

Permalink Reply by Anders Holden Deleuran on February 5, 2016 at 3:01am

This reminds me of an idea I had to speed things up (apologies for hijacking):

Problem:
In my experience with generating goals, the primary bottleneck has been to output/input long lists of goals, not their actual creation inside the component (especially when using scripting components).

Solution:
In the Joey/ShapeOp stuff I've been doing prior to K2, my method to solve this has been to wrap goals list in some data structure which is output/input as an item. In Python I would either wrap the goals list in another Python list or a dictionary. These both output to an ironpython object that can be sent downstream as an item, which drastically decreases the time cost of outputting/inputting goals. See attached example.

Suggestion:
Perhaps there could be a simple K2 utility class for wrapping goals in a "GoalsPackage" or a suitcase or something :)

Best,

Anders

Attachments:

• 160204_GoalsPackageIdea.gh, 20 KB

Permalink Reply by Anders Holden Deleuran on February 5, 2016 at 7:31am

Small update:
Just did a side-by-side with the standard component to verify my "problem":

Permalink Reply by Petras Vestartas on February 7, 2016 at 1:50pm

Thank you for a reply. I have  written the same definition in one c# component.

I have question regarding adding Particles to Particle System and then making Springs from them.

 Is it possible to:
    1 Add particles to Particle System
    2 Incrementally draw springs between them?
    I saw that there is possibility to create springs like this:
    Spring(Int32 s, Int32e, Double l, Double k)
    Instead of Spring(Point3d s, Point3d e, Double l, Double k);
    Does is it mean that I can add particles to ParticleSystem and then create Spring between Particle(Int32) and Particle(Int32)

    If yes, I got an error when I try to make a Spring  : Object reference not set to an instance of an object. (line: 0)
    Could you help me with this issue? I attached the .gh file with c# component (There is one working component that shows working script and one that I stuck with)

Thank you,

Petras

Attachments:

• Kangaroo_Particles.gh, 12 KB

Permalink Reply by Daniel Piker on February 7, 2016 at 3:23pm

Hi Petras,

"Does is it mean that I can add particles to ParticleSystem and then create Spring between Particle(Int32) and Particle(Int32)" 

Yes - that's the idea. Kangaroo maintains a list of particles, and each Goal object has an array of integer indices saying which of these particles it acts on (its PIndex[]).

There are two different ways of managing this indexing - the first is by giving a Point3d for each point each goal acts on - eg each end of a spring, and then calling the AssignPIndex function to automatically build the list of particles (combining any coincident points) and find the integer indices for each goal.

The second way is to add the particles explicitly, and set the indices yourself when creating the goal. It will give an error if the index is higher than the number of particles currently in the system.

Permalink Reply by Petras Vestartas on February 7, 2016 at 2:28pm

Hmm, this worked when I commented out //PS.AssignPIndex(tempSpringH, 0.0001);

      //Horizontal Spring
      Spring tempSpringH = new Spring(n - 1, n, 0.1, 0.1); ///////////////////Error here
      //PS.AssignPIndex(tempSpringH, 0.0001);
      GoalList.Add(tempSpringH);

      //Vertical Spring
      Spring tempSpringV = new Spring(n - 1, n - dif, 0.1, 0.1); ///////////////////Error here
      //PS.AssignPIndex(tempSpringV, 0.0001);
      GoalList.Add(tempSpringV);

      //Lock particle
      if(n - dif > 0 && n - dif < 2 * dif){
        Anchor pLock = new Anchor(b.loc, 0.1);
        PS.AssignPIndex(pLock, 0.0001);
        GoalList.Add(pLock);
      }//end if

Could you please explain PS.AssignPIndex function ?

Attachments:

• Kangaroo_Particles_lock.gh, 8 KB

Permalink Reply by Daniel Piker on February 7, 2016 at 3:26pm

This is the AssignPIndex funtion:

/// <summary>
/// Compare the PPositions of the Goal to the positions of the particles in the system,
/// add new particles to the system if there is nothing there already,
/// and assign the appropriate PIndexes to the Goal.
/// </summary>
public void AssignPIndex(IGoal Goal, double Tolerance)
{
   Goal.PIndex = new int[Goal.PPos.Length];
   for (int i = 0; i < Goal.PPos.Length; i++)
   {
      int Index = this.FindParticleIndex(Goal.PPos[i], Tolerance, true);
      if (Index == -1) // if no particle exists yet at this location, add one:
      {
         this.AddParticle(Goal.PPos[i], 1.0);
         Goal.PIndex[i] = this.ParticleCount() - 1;
      }
      else
      {
         Goal.PIndex[i] = Index;
      }
   }
}

Permalink Reply by Petras Vestartas on February 7, 2016 at 4:53pm

Thank you :)

Now it seems quite fast ( The end of the video: when I lock last loop of particles, the Particle System behaves quite nicely )

If you have some time, would you please answer a few questions?

Why some of the springs are null?

Is it possible to know how to add Unary force?

I tried to implement this Goal, but it is changes the spring behaviour greatly with different values.

Attachments:

• Kangaroo_Particles_lock.gh, 13 KB

Permalink Reply by Long Nguyen on February 11, 2016 at 5:47pm

Hi Petras.

"Why some of the springs are null?"

I guess you mean that some elements in the GoalListOut are null (see screenshot)? Well, these null values are caused by the Anchor goals, which simply do not output any display geometry. This is just how Daniel defined the Anchor class. The spring goals, on the other hand, do output lines as display geometries.

Despite not outputting any display geometry, the anchor goals are still working fine and influencing the particles accordingly. So everything is fine. You can safely ignore these null values.

Attachments:

• 1.png, 61 KB

Permalink Reply by Long Nguyen on February 11, 2016 at 7:02pm

Also you can further speed up the execution by supplying the particle index when constructing the Anchor object. If you do this you do not have to later call the PS.AssignPIndex function, which is quite costly as it has to traverse through all the particles that are already in the system (so over time as you accumulate more and more particles in the system this function will run slower and slower!!!).

if (n - dif > 0 && n - dif < 2 * dif)
{
    Anchor pLock = new Anchor(n, b.loc, 1000000);
    GoalList.Add(pLock);
}