Hoopsnake Iterations - Data carries across ?

Hay,

I'v got a nested HS function that moves the first item (a curve) +1 until its X from the end, then moves onto the next list item and so on.

Just to clarify I'm trying to get it to move cleanly - always start at 0 move every new list item.

The issue is that when moving from the list item HS to the move +1 HS the distance from X is then transferred onto the next list item for the first "cycle".

So;

Select curve List item 1 (& Direction & Line for evaluation of X)

+ 1 move

until distance is X from end (call this distance y)

Select curve list item 2 (& etc)

Curve starts at y

Then goes to origin

+ 1 move

until distance is X from end and so on maintaining (variable) Y every time

.... Reading this I can't make sense of it, the only thing I can suggest is to look at the definition, especially at the ends of the shape where you can Really see it happen(zoomed and waiting for it to come around). But you can only see it for a split second.

This is driving me insane, so any help will be met with grovelling thanks

James

Attachments:

Hoopsnake_issue.gh, 24 KB

Replies to This Discussion

Permalink Reply by James on March 28, 2015 at 3:01am

Little Help?

It almost seams like theres 2 true values for this to happen? do I need another hoopsnake function

Permalink Reply by peter fotiadis on March 28, 2015 at 3:36am

You need the other color, he he (Sorry for the Skype thing but this week was terrible > good news > the worst still to come).

Permalink Reply by James on March 28, 2015 at 4:15am

Its too late for that ...

...unfortunately there was no black pills.

No worries about the skype thing (when it rains it pours right?).

Here's the innards of the file for anyone else to shed some light on it:

Thanks

Permalink Reply by James on March 30, 2015 at 5:29pm

Boop pa dee bump!

Permalink Reply by peter fotiadis on March 31, 2015 at 12:12am

Skype today ~9.00 p.m.

Permalink Reply by James on March 31, 2015 at 11:52am

Permalink Reply by James on March 31, 2015 at 1:03pm

Growth

Attachments:

GROWTH2.webm, 925 KB

Permalink Reply by James on March 31, 2015 at 1:09pm

Shapes

Attachments:

Dimondo.3dm, 73 KB

Permalink Reply by peter fotiadis on April 1, 2015 at 2:38am

Case resolved (via the black pill).

In the mean time get the gist of the connectivity DataTree (as we discussed already yesterday) as regards node indices VS node-to-node/faces DataTrees (if you can't do that you'll be NOT able to understand what I'm doing).

Imagine a List with nodes : vList. Imagine a DataTree with node-to-node connectivity info: vvT. Where vvT BrancheCount == vList.Count.

for a given vList[i] node the vvT.Branch(i) contains indices of all the neighbor nodes (we need to sort them (easy busy), compute the bisector(ditto), and get the clash safe "x" length per strut "adapter" (Math.Tan(bisectorAngle/2.0) = Rstrut/x).

PS: Accessing neighbors:

for(int i =0; i<vList.Count; i++){ // all node pts

for(int j = 0; j < vvT.Branch(i).Count; j++){ // all neighbor pts per node

Point3d neighborPoint = vList[vvT.Branch(i)[j]]

blah...blah

}

The rest are peace of cake.

I'll mail you in privet the solution (another Skype session is required: Today, 9.00 p.m as usual).

Permalink Reply by peter fotiadis on April 1, 2015 at 6:00am

Hmm ... theoretically this:

could take us out of the rabbit hole (sort properly neighbors in order to extract bisectors in order to manage strut to strut clash situations):

but theory and reality differ (sort along curve doesn't work when, say, the points are in some "banana" topology arrangement).

Plan B is required (Peter's sort: slower but 100% spot on regardless the topology).

more soon

Permalink Reply by peter fotiadis on April 1, 2015 at 11:46am

Good news: works in any imaginable situation (closed/open mesh, weird mesh, odd mesh, wild mesh, faulty mesh, no mesh (best option, he he), you name it). It's real-time (tested in meshes up to 10K nodes) as well since the clash detection is performed via trigonometry and NOT via some stupid bool union/difference/whatever test.

Better news: well if the topology is "normal" adapters are a charm (shown the test/inspection mode: no solids, no adapter protrusion for the flex-strut, no union etc etc) - if you change values it's surreal to see the clash working on-line:

Bad news: I was wrong by saying that we don't need GH for that (Plan B: doing the C# directly for SolidWorks and by-passing GH completely): I mean ... OK the clash works but we've got ridiculous adapter lengths > it's a bit overkill > we need control over the mesh thing for avoiding laughable situations like this (steep angles + clash detection > BIG adapters).

Permalink Reply by James on April 1, 2015 at 12:56pm

I came across this in the preliminary design stage, where by the nodes arm length was either determined by the minimum set length or by the angle (as stated by above).

So where's the compromise?

+ Edit the node type??

+ Edit the mesh??

+ Stick to squares?? (my favourite option)

It took 8 of us round a table to come up with ..."just go with it"... no where near as catchy as just do it.

The other option is to turn the node into a male joint, where by the node arm mimics the extrusion shape until the point of connection...

however the female node secures the truss via an interference fit (as we discussed) and claps secure the extrusion on the paper.

SO just go with it seems to also be my opinion now, I'll manipulate the mesh to avoid such monstrosities, but at (rare) points they may be desired (pingus beak). I almost feel that I deserve it (ugliness) if I design it that way.

As discussed the mesh "purity" is fixable at the beginning or even after viewing the results (go back to start, do not pass the pharmacy, do not collect migraine tables.)

Unless you can think of a way to subvert the laws of physics then I think this is the way it has to be done.

I'll be busy manipulating time until then.