Iteration in two directions

Hi all,

I have a surface then I generated two curves on it that are perpendicular to each other. I divided them from their intersection point to equal distances and I need to generate a grid of points by intersection of each two spheres with the surface which the center of the first sphere is the first point on one curve and the center of the other sphere is the first point on the perpendicular curve to the first curve. Other points can be obtained by a similar drawing.

As the image below.

I can only use the hoopsnake component to repeat this function in a row and for generating the next row, I have to use another hoopsnake component and it is a long way.

How can I repeat this function in the easiest way for two dimensions?

Tanks in advance.

Replies to This Discussion

Permalink Reply by peter fotiadis on November 10, 2015 at 1:27pm

Hmm ... I can't claim that I've got it right ... but anyway:

1. you have a geodetic (yellow) and as much "perpendicular" curves (the white ones) you like.

2. then you want to divide the white ones by length (in fact the properly aligned pairs of splitted curves at the yellow curve division points) ... giving a grid with equal distance points, right?

If so ... what have to do with all these ... er ... the balls?

PS: the thing captured above is C# (not Hoopsnake) ... but anyway ... just out of curiosity.

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

But of course, get it

Attachments:

chebyshevloop_V1.gh, 149 KB

Permalink Reply by peter fotiadis on November 11, 2015 at 7:52am

Well ... there's a variety of ways to divide a curve (by count, by length [ meaning the segment's length and NOT the end-start points distance] and others). If the division method is NOT what you think that you want > garbage in > garbage out, he he.

For instance these mysterious "lines" do a division by count (and make the planes "along" the geodetic curve). Remember: equal "segments" NOT ptToPt distances.

Get this attached as well that is "close" to what I call internal C# scripts (hence the dark grey color: Lord of Darkness etc etc) ... and I'll promise to add some lines of code more in order to allow you having ALL the division options on hand (and ways to report any result imaginable - like the ones already provided with regard end-to-end pts distances).

PS: provide some TEST surfaces of yours

more soon, best, Lord of Darkness

Attachments:

Geodesic_grid_V1.gh, 146 KB

Permalink Reply by peter fotiadis on November 11, 2015 at 9:56am

What did I said one step above?: provide some TEST surfaces of yours (i.e. some surface [or more] that appears "not" working). PS: pack some in a Rhino file (def is NOT required).

PS: in general 1 line of "actual" code requires about 9 that "address" the "what happens if" scenario(s) - therefor some tests are always required to manage potential shortcomings ... or bugs ... or cases not taken into account ... or ... Usually changes are few (just one or more "if" added).

Permalink Reply by peter fotiadis on November 11, 2015 at 11:50am

This is (was) a good case ... where the internal version works in a totally controlled environment (lists of "ideal" Breps + hole detection + other stuff) and when portions of it surface as "public" ... well ... Karma what else? he, he

So here's V1B that assigns priority to CCX points AND not curves ... since there's always the probability for some CCX failures (due to tolerance or who knows what else).

Spot the variety of messages related with that:

all that in case:

Whilst when things are "as expected" (but what this actually means? he he):

NOTE: I do hope that you know that a surface and a trimmed thingy (Brep) that ..."looks" like a surface ... er ... they are NOT the same thing (the "underlying" surface with respect the Brep ... hmm ... is a surface). A bit confusing eh?

he, he

Attachments:

Geodesic_grid_V1B.gh, 151 KB

Permalink Reply by peter fotiadis on November 11, 2015 at 8:36am

Of course is rather impolite to use C# in a hoopsnake Forum (I promise: never again, ha he) ... but get this V1A that reports pt to pt distances.

These ARE NOT the same with the 20.11 (DivideByLength method used) value entered because this is the length of the segment and NOT the pt to pt distance.

I do hope that this sheds some light on that matter.

Attachments: