Grasshopper

algorithmic modeling for Rhino

Hi,


I would like to ask about Kangaroo2 and adding elements incrementally.

I made a small C# class for moving a point, that adds segments iterativelly with timer.

It works well, but the simulation gets slow as long the numbers of elements increases.
In the end, there are not so many elements, but the procedure for adding elements each 20 ms makes trouble.

Is it possible to make this process faster?

I attached .gh file and .gif bellow.

http://payload432.cargocollective.com/1/20/653920/10942564/Untitled...


Thank you,
Petras

Views: 1145

Attachments:

Replies to This Discussion

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.

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:

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

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:

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.

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:

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;
      }
   }
}

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:

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:

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);
}

RSS

About

Translate

Search

Photos

  • Add Photos
  • View All

Videos

  • Add Videos
  • View All

© 2024   Created by Scott Davidson.   Powered by

Badges  |  Report an Issue  |  Terms of Service