K2 231 Locator syntax

[PeterFotiadis (Pfotiad0)]

Hi Daniel,

In order to sample some geometry (lines) into Locator Goals, what is the correct syntax? (PS: Some mini SDK anyone? [ or maxi]).

Lines are the pulling cables in some Tree [red: shown at start pos] in some tensile membrane (from mesh Lists) meaning that one point is anchor and the other is some mesh vertex.

This doesn’t work:

for(int i = 0; i < varCables.Count;i++) { // pulling cables
Line cable = varCables[i];
Spring sc = new Spring(cable.From, cable.To, 0, varCablesStifness);
PS.AssignPIndex(sc, indexTol, byCurr);
Goals.Add(sc);

  // GH_ObjectWrapper ow = new  GH_ObjectWrapper(cable);
  // Locator locator = new Locator(ow);
  // PS.AssignPIndex(locator, indexTol, byCurr);
  // Goals.Add(locator);
}

BTW: The whole single List approach in PS.GetOutput(Goals); needs a certain rethininkg

best,Peter

[PeterFotiadis (Pfotiad0)]

Forgot to mention that using as input the Show K2 for making the Locators (showTree in this demo) works: kinda flying from DC to NY via LA:

[wim (Wim Dekeyser)]

@PeterFotiadis

Hi Daniel,

You might want to hail him like this: @DanielPiker

[PeterFotiadis (Pfotiad0)]

BTW: Given the opportunity there’s some odd results from the K2 231 engine. Let’s see some classic steps.

1. A flat guide mesh (Plane.WorldXY) is defined (plus the pulling variable cables [red: start pos], fixed cables and masts):

2. The guide mesh is further subdivided (sorting topology vertices AND Dot stuff for the new faces against the face to be divided [better safe than sorry]):

3. Then the 231 does the job and the tensile membrane is on hand [minus - for the momernt - the Locator related cables]:

4. But … appears that some mesh faces occasionally are flipped (see stuff with different blue hue) and scrambled so to speak :

.

5. The freaky thing is that this anomaly happens rather randomly. For instance this 231 mesh (some random result) is OK:

231 bug or what?

[DanielPiker]

Hi Peter,

The locator goal can take the following types as input:
Mesh, Line, Polyline, Point, Arc

It’s really just a way of keeping track of the indices of a number of particles, and reconstructing some point based geometry using the updated positions of the particles at these indices after the solver has moved them around (for the ‘show’ component).

I didn’t really imagine people scripting with the library would have much use for it, since then you have direct access to the indices of all goals and particles you create, which I think should be simpler than using Locator.

After you’ve called AssignPIndex on a goal (which finds the indices of the particles in that goal if they already exist in the system, and adds new particles if they don’t), you can use its PIndex to see which particles from the particle list it is acting on, get their new positions and make updated geometry using these positions.

Regarding the list structure of GetOutput - I’ll have a think about whether anything can be done to make it easier for scripters to organise their goals in more convenient ways. I can say now though - I don’t think that will ever involve putting Grasshopper datatrees inside the KangarooSolver.dll (which as much as possible is kept separate from Grasshopper, since in the long run the intent is to do other Rhino stuff with it, with Kangaroo.gha handling all the interface with GH).

In your mesh example, I don’t understand what you mean in your step 2.
If you have a mesh with consistent normals, then Kangaroo moves the points around, if you keep the vertices in the same order, and the same face information as before, then the normals will remain consistent.

[PeterFotiadis (Pfotiad0)]

Hi Daniel.

Well let’s start from the “odd” result mesh. The input mesh has consistent normals (or at least they point to the right direction: step 2 refers simply to that [since the subdivision on the input mesh is made also via C# … well … s@#$#@ happens] ). The resulting mesh occasionally has incosistent normals (as shown). The sequel of images just indicates that: from a good mesh to a problematic mesh.

Anyway … I’ll make a simplified def that outlines the issue.

With regard accesing the post solution modified geometry (red lines in the images):

These at one end have a particle (mesh vertex) and on the other an anchor Goal. They are assosiated with a spring Goal (+ a PIndex) as well. So in fact we are looking for all the lines (i.e. springs) that have these Goal indices. So you suggest storing these indices and then retrieving them from the GetOuput List? But out of curiocity … why the inactive lines (//) in the first screen shot (Locator) yield an exception?

But speaking in general the main big issue here is the known one: a SDK , what else?

[PeterFotiadis (Pfotiad0)]

BTW: Demo postponed a bit: given the opportunity I’ll add some real-life requirements from similar solutions … for instance checking the plate topology (flat plates yield more or less bad results if the angle is bigger than a certain limit). Plate topology means keeping track on specific particle combos (say vertices connected to the vertex from where rhe pulling cable is attached).

For instance these fixed planar plates are no no (for random solutions as above - if you can’t provide a Jack for all trades … you’ll need a zillion different plates [on a per node basis]):

Other than that clash real-liffe issues are the other big thing. Thus this fixed mast end approach is also a no no (you need a lot of “hinges” in order to adapt in any situation).

[PeterFotiadis (Pfotiad0)]

In the mean time:

Plan B (PIndices) obviously works (but still I have no idea about the Locator correct syntax … meaning that life sucks). Yellow are the start pulling cables positions, red the final positions. A custom Goal is required for the dihedral plate angle calculations (and the all overal plate design policy) … but that’s rather trivial.

[PeterFotiadis (Pfotiad0)]

And this is an isolated (static) demo on the inconsistent K2 mesh normals. Strange indeed (unless the C# that does the subdivisions yields bananas).

278_UAE_WIP3_V1_forDaniel.3dm (310.0 KB)
278_UAE_WIP3_V1_forDaniel.gh (137.2 KB)

Load R file first (nothing internalised) and play with the subdivision values (a few faces are not as expected):

[PeterFotiadis (Pfotiad0)]

Tested about 100 solutions: small, medium, big, bigger, enormous meshes (there’s an auto option: do N random solutions and store them in various trees). The inconsistent Normals issue appears from time to time but not always and for a few mesh faces near by the naked edges.

Maybe is a matter of Karma.