Geometry for simple reciprocal frames

Hi all,

So I am trying to apply some simple transformations to the members in a reciprocal frame. The units of the RF are based on the mesh edges of some surface.

So I am trying to move a straight line connection B and C (say upwards in z for simplicity) by some amount proportional to the length L, say n*L.

image|636x480

I can locate lines BA and BC by checking for duplicated start points for all the lines in the structure. It seems necessary to flattened all the lines in the model into one list to do this, since I want to see if any points are duplicated anywhere, its not enough to shift the path or something and check locally between the members of adjacent meshes (or at least it seems complicated to do this simply). Only now it is difficult to match the length L to the correct line BC for all mesh discritizations.

Any ideas how I can organise this better?

Thanks

simple_reciprocal_unit.gh (31.8 KB)

I’m having trouble understanding your sketch and description. It’s not really clear what the lengths refer to, and you talk about B and C, but these aren’t labelled.
The grasshopper file doesn’t make it any clearer either - what’s the idea of this offset?


Is the idea to make tangent cylinders? or will these be rectangular sections?
Is this a single unit that needs to repeat?

If it is just about finding the ends, you can get the intersections like this:


simple_reciprocal.gh (12.6 KB)

1 Like

Hi Daniel,

So for each mesh rectangle I use a centre-to-centre scaling to generate the reciprocal members.

image

So for a width (U) of 2 and rac divisions (V) of 3, it looks like this:

Then where there are two members which share a start point (green lines), I want to change these into straight lines (which I do currently by flattening all the start points and seeing if any points appear more than once), use that index to get the two members and create a new straight line between their end points.

And then I want to move them updards proportioanlly, which involves this length here, which was easy to find before but since I have flattened the lines it’s seems hard to use an index to match up this length with the appropriate straight member I want to move upwards (well towards the kink actually) because the lines are no longer in seperate branches containing the lines based on each mesh rectangle, if that makes sense.

Basically 6.1 here: https://www.researchgate.net/publication/336642227_The_Timber_Reciprocal_Frame_Designer_Free_Form_Design_to_Production

Thanks

Okay, so you are looking at this challenge of finding the line orientations in 3d to give consistent offset distances. This does generally require numerical optimisation. See some of the examples I posted in this long thread which solve this using Kangaroo:

Yep. I was mainly trying this transformation to get the basic geometry, underlapping/overlapping mebers etc. before an optimsiation step. Anyway, thanks for your reply :slight_smile:

Finding which ones should overlap/underlap is actually easier when you don’t have any coplanar adjacent faces.
When there is an angle between each face, just rotating each edge about an axis through its midpt and in the average direction of the neighbouring face normals gives a natural under/over arrangement very easily (an idea I got from this paper by Tomohiro Tachi on freeform tensegrity):

When the faces are coplanar though, this doesn’t give any over/under:


So you probably need to use a different strategy

Daniel is right, it depends on curvature.
If you have a barrel vault then U beams will be shifted more than U directions.
Diamond grid is a bit better though (a bit).
If you think about Zollinger system instead of Recirpocal all beams are at the same eccentricity for a barrel vault.

Webp.net-gifmaker (1)

Webp.net-gifmaker
9_ZollingerAndNexoradeStudies.gh (1.2 MB)

This post might help:

Nice! yep the idea was that with some simple geometric transformations pre-optimisation you could get correct RF member orientation even from a co-planaer surface. And I think I’m pretty close but not quite there, the key being keeping a good branch structure.

@Petras_Vestartas very cool with the NGon stuff, I will definately look into it the Zollinger structures thanks!