Grasshopper

algorithmic modeling for Rhino

Hello everyone, I am trying to split curves based on a program inserted between them, the piece splited is based on the distance of this program.

I was able to split the curves but no luck trying to isolate those specific pieces. So I thought curve sub domain could help me reconstruct these specific pieces, after all I have got the points with their t.

Now its more a data problem, I have these t grouped in two, and the number of branches is the number of curves. Some curves need to be evaluated more than once, (there are branches with 6 items), this means 3 domains.

How could I create these domains, making the tree structure: nr of branches = number of curves. (done) number of items in each branch = number of domains.

Thanks for any help,

Shynn

Views: 1013

Attachments:

Replies to This Discussion

I am trying to split curves based on a program inserted between them, the piece splited is based on the distance of this program.

I have no idea what that means - and a strong gut feeling that you're "barking up the wrong tree", so to speak.

As I probe your 'Brep' and 'Crv' params with my 'Tree/List Viewer', I can see that the seven rectangles are in branches corresponding to their placement between curves (2, 2, 1, 2), and that instead of the apparent six curves, there are twelve in a flat list with between one and four(?) segments per visible curve, none of them touching each other.

So I guess my question is this: What is your goal here?  Forget about sub-domains or other speculation about how to get there; in simple terms, what is the objective or outcome you wish to see?

Hi Joseph, thanks for your reply.
The simple goal is to extract those segments (marked in yellow in first picture). Then I will create stands for people to sit using these segments.

I was not able to have, in a list, only these segments. The shatter component worked ok, but the list containts unwated segments (the ones not inmediatly infront of the program).

OK, now I understand - and I see two problems:

  1. The two rectangles on the left below, {4;0} and {4;1} in the tree, have their closest points on two different curves, resulting in three instead of two results after removing duplicates.
  2. interpreting the results of 'Shatter'...  nuff said for now.

Check out the attached with the trace 'Tree/List Viewer' and choice of results to display (blue group): 

  • Points
  • Curves (raw)
  • Curves (de-duped)

Gotta go, ciao for now.

P.S.  Sorry, too hasty...  "Curves (de-duped)" is really the 'Shatter' results.

Attachments:

I meant to say, the two rectangles on the right, {0;0;0;0;4;0} and {0;0;0;0;4;1}:

Attachments:

Indeed, but we could replace those points with the end points right? Equal to replacing with 1 or 0 in the sub curve domain.

For now I think this problem could also be sorted by considering 6 curves as you previously mentioned. Not 13.

I also meant to say:

instead of the apparent six curves, there are thirteen in a flat list with between one and four(?) segments per visible curve, none of them touching each other.

That these curves don't touch is why there are three curves instead of the expected two after "de-dup" lines/curves.  This would be easier if there were six continuous curves, and you can get that like this:

Is there really any reason not to flatten the list of rectangles?  The branching in that list looks arbitrary, though it's not a fatal flaw like these discontinuous curves.

Its organized on how many rectangle are in each "tweened axis". These would be the mid curves between the six curves. So from left to right there are 2 in the first axis, 2 in the second, 1 in the third, 2 in the last.

But for this operation there is no need to keep that tree structure, I grafted it once it got to the "curve closest point"

Attachments:

Thank you Joseph!

Here is the stripped down version, with trace features removed (except for the yellow 'Pipe' highlights); deceptively simple, isn't it?  Not that it was easy, by any means...

We didn't answer your original question ("Create Domains based on Items on each branch?"), except to show once again that by keeping close track of data tree branching along the way, awkward problems like that can be avoided.

Attachments:

RSS

About

Translate

Search

Photos

  • Add Photos
  • View All

© 2024   Created by Scott Davidson.   Powered by

Badges  |  Report an Issue  |  Terms of Service