Series transformation/translation

Replies to This Discussion

Permalink Reply by peter fotiadis on March 22, 2016 at 10:06am

Well ... this spaghetti is too chaotic for me ... thus I'm not at all sure that I've got correctly what you want (rather the opposite I suspect)

Anyway see this attached.

PS: what are you trying to achieve? some "inclined" grid? (if so is rather very simple).

Attachments:

• Grillage_seriesbased_30_Rev_A_V1.gh, 37 KB

Permalink Reply by Kenyon Graham on March 22, 2016 at 11:04am

Hi Peter,

I am trying to generate an orthogonal grillage through the points contained within the extent of the rhombic shape defined by the points that I have grouped.

However I would like to control the points contained within it, using one data tree for ease of manipulation of the points.

My workflow was as follows:

•Define the points that define the skewed edge EBPt1 and Pt6
•Define the extent of the points ( grouping the 6 pts gave me a mental picture of the control points, ie. changes in direction)
•Divide the line determining the skew edge, these points determine the number of points
•Use the intervals between the points to get the x and y steps
•Use the indices to gain a starting point on the next point cloud ie. Triangular/rectangular/triangular point clouds, it may seem odd there was logic to it
•Once I have the extent of the points connect the points into longitudinal and transverse lines/curves using a data tree relative items approach.


The points contained within the rhombus are constrained by the condition that they require to be orthogonal, this is proving actually quite tricky as the lines intersect with the rhombus.

That's my stage 1

Not forgetting that I would like to move the grillage anywhere on the canvas linked to a key point, in this case EBPt1 (0,0.225,16.0) from memory, crudely achieved with the vector translation.

Aside from the geometry I am trying to organise my point data tree in a manner that captures the points in consecutive longitudinal or transverse branches. Avoiding unnecessary points

A while back I tried a different approach with three data trees, one of my addition constraints in this attempt is to avoid using a data panel to control the data tree parameters, allowing the grillage to be completely generative.


I'm sure you are glad that you asked.

Thanks and may the geometry be with you.

Kenyon

Permalink Reply by peter fotiadis on March 22, 2016 at 1:24pm

Er ... hmm ... let's spend 5 minutes on something: could we start from this ?

I mean what else (other than it does) you want/wish more? (I suspect some stuff, maybe patterns? maybe dogs? maybe cats?).

PS: by more I don't mean the way that the grid distances are defined (that's peanuts to modify).

Attachments:

• Grids_V1.gh, 11 KB

Permalink Reply by Kenyon Graham on March 22, 2016 at 11:22pm

Thanks Peter always eye opening.

The arrangement will be the structural geomtery model for a bridge deck.

Generally the type of analysis for skews greater than 25deg requires an orthogonal grillage.

Hence the three sections. I've attached a sketch.

For me it is a data tree example, which appears simple, I suspect that its quite difficult (awkward).

The idea from working only from the points is to minimise the duplicates. When I import to my analysis package I generally have two issues tolerance and too many duplicate points.

It is also important for me to use grasshopper components possibly a teeny weeny bit of Python. We are also using Dynamo (nighmare!).

I wasn't sure about your ptree parameter and failed to get the C#to run.

I got 30 %, the refernvce origin, failed to suss the T input of the data tree component and humiliatingly the A point on the line component.

It is important that there are points at the intersections, connected to the grillage where the skewed edges meet the parallel edge lines.

Again thanks for your interest, oh!! no cats we have one of those and she reckions that I should merge the 3No. series.

Attachments:

• Skew_grillage_30.jpg, 193 KB

Permalink Reply by peter fotiadis on March 23, 2016 at 12:28pm

Hmm ... Appears (based on your sketch and a dose of good Karma) that you want this thingy attached.

PS: Dynamo is not nightmare in the sense that Generative Components is not a nightmare (the very same [Robert Aish ex Bentley Systems top-dog] did both).

Attachments:

• Grids_V2.gh, 118 KB

Permalink Reply by peter fotiadis on March 23, 2016 at 1:16pm

And this maybe can clarify things better

Attachments:

• Grids_V2A.gh, 121 KB

Permalink Reply by Kenyon Graham on March 23, 2016 at 9:59pm

That's definitely the result i am aspiring to.

Particularly the data tree structure.

My plan was/is to combine data trees, flatten, sort x then y, graft, the Y

You need to admire ambition

Attachments:

• Grillage_series based_datatree_Rev_A.gh, 11 KB

Permalink Reply by peter fotiadis on March 24, 2016 at 12:55am

Well ... this 3 branch approach of yours it doesn't make any sense to me (and violates 3.56 laws of chemistry and 5.34 laws of physics)  ... but I've added it as a s@$%t option (in the name of Science, as usual).

Permalink Reply by peter fotiadis on March 24, 2016 at 12:57am

And the thing

Attachments:

• Grids_V2B.gh, 124 KB

Permalink Reply by Kenyon Graham on March 26, 2016 at 7:04pm

The script that you provided works very well. I converted it to Python, which i an equally rubbish at.

My aim has always been to keep it in GH minimising the need for input text panels, avoiding losing generative aspect.

The three section approach was to give direct control over the number of points in the central section only. Its relatively easy to generate the rows of points

Oh! I was looking at it as a datatree exercise with path mapper.

I was trying to get:

1.{0;0;0} to {0;0;5} consistent N of 17 and

2. reversed {0;0;0} to {0;0;17} varying N

I havent quite solved that yet, thanks all the same.

Attachments:

• Grids_V2B_5x17.gh, 16 KB
• Grillage_series based_datatree_Rev_Cgh.gh, 13 KB