Data-tree structure for simultaneous multiple sweep1

Good morning,

I am struggling with, I assume an easy, yet too complex for me data strucutre issue :

I am trying to sweep 2D profiles (laying flat on x;y plane near file origin) along closed polylines that represent the outline of my windows.

I figured that my sweep needed to be cut in two piecces to work properly-

So my inputs are : 1 tree with two curves/polylines on each branches.
1 tree with one ore more element per sub-branch (window material profile).

I get good orientation in space for my profiles (thanks to the orient component) but then I just cant wrap my head around how to do the operation in one go. (the red higlighted componenent would be the one that does the last step)
I assume it is a data-tree structure issue - but after spending some time on my own trying to figure it out I am seeking for an advice from the wises in the forum, regarding how to manipulate the data strucutre so it works .

You may find attached an internalised version of the script. (units = meters)

For the record I could make it work for one frame- but partially loosing th “material data structure” so not very happy about it - see the blue geometry (as the pofiles turns into 0,1,2 and 3 branch in the data structure instead of 0;0 , 0;1, 1;0 and 2;0)

Thanks in advance for your time - :slight_smile:
Thomas

20231121_Facade generation sweep and data structure.gh (30.0 KB)


20231121_Facade generation sweep and data structure_Edited-01.gh (35.5 KB)

Thanks for your help Rajeev.

Unfortunatelly, this is not what I am looking for :

Indeed by merging the profiles instead of “Entwinering” them you loose the data structure.
Furthermore with your method, one manually has to add 4 sweeps componenents because you counted that I inputed 4 profiles- but this is just place-holder, that may vary. So, in my mind it would need to be tacle in a “non-manual” way (that is why I was wondering wether it could be done with data-tree strucutre)

but maybe sweep does not handle well data strucutre ?

I apologise if it was not clear in the first place.

Well,

For those interested : A workaround was to work with lofts :

As I know how many windows I have (based on grid lines) and how many sides has a window (this might not change… I hope) I could make a serie of bissector planes and then project my profiles along, and finally get my data structure back with a match tree component.

I did not try it, but the numbers in the series could probably be all parametric (based on windows number and number of edges, as mentionned above)

Yet if anyone find a solution for this initial problem I would be curious to read about it, because I still believe it is a better and more elegant/faster way to do it rather than my speghettis solutions (which hopefully is future-proof) :smiley:

20231121_Facade generation sweep and data structure.gh (23.3 KB)

Hi Thomas,

The first thing I noticed is that while I could extrude and do simple operations on the curves you had, some of the segments were coming out at 0.0001 and once I tried to do anything more complex to them it would fail, so I had to bump up the tolerance of my Rhino file to 0.00001 (probably one more zero wouldn’t hurt) - I only half understand the subject, but I have a feeling that if you need to model to the millionth of a meter, you’re better off using millimetres rather than meters. Alternatively because such a high tolerance reduces performance, using DataInput and DataOutput - you could pass the window curves out of this definition into another one with tolerances and units more suited for what you’re modelling and put them together in a WorkSession file or something like that. (Maybe I’m teaching you how to suck eggs, but I have a few experiences where our team was incapacitated with tolerance rather than logic :sweat_smile:)

I’ve left you some annotations in the file of what I changed - I believe the main issue was that gh thought that you have 1 rail and 4 sections that belong to one object, I don’t think it was being interpreted as: “Sweep each of these 4 sections along the rail” but instead: “Sweep through all four sections using this rail” - so the main thing to do was to Duplicate Data so that there were 4 rails and 4 sections and then matching that. Anyway, see what you think

20231121_Facade generation sweep and data structure.gh (49.7 KB)

-Sash

On a side note: @DavidRutten - am I doing something wrong in setting up the Tree Selection Rules? For some reason {*;(0,1);*} is still giving other branches?


20231121_Facade generation sweep and data structure.gh (49.7 KB)

(the same tree is coming in at Location 1 and 2)

EDIT: I was troubleshooting the tree selection and accidentally left “?” instead of “*” in the file, updated with the right file and screenshot

3 Likes

This mask {*;(0,1);*} will match any path containing 0 or 1.

See this post:

-Kevin

1 Like

Hello Sash,

Your solution is exactly what I was looking for !
I was also thinking about something with duplicating datas but could not achieve it : My brain just melted yesterday becasue I could not find how to adress all the data properly :face_with_raised_eyebrow:
It was just about carefully curating the data structure !

Regardings units : it does work in my rhino files with meters as units, and tolerance at the 10th of a mm so global tolerance 0,0001 (which sounds reasonable enough for me, as even for facade I usually do not go lower than the mm)
But smart Idea to split the script between a mm and meters files with I/O-links.

Thank you very much !

1 Like

I might have spoken too quick :

@Artstep , Yes, the data structure is clean and usefull and it looks overall nice, but the geometry has some issues:

  • First : I wanted closed breps to run volume calculations (for LCA purpose). And for an unknown reasons I get some open Breps when joining the geometry
  • Second : even with the joined geometries I have a little visible edge where the two parts join, that I will need to manualy clean when doing my 2D drawing after a make 2D of this script : A bit of a bummer (I wish I could sweep without splitting my rail in two parts, but no idea how to do that with my example.)

Anyway thanks for your time - At least the data structure part make some sense now !

Hi Thomas,

I tried to troubleshoot it a bit further and moved the relevant geometry out of the file; a really good workaround turned out to be in using Mesh Sweep instead of NURBS Sweep - I left notes of what I tried in the file, but I wasn’t expecting it to work quite so easily in the end. Mesh Sweep came from Mesh Tools. You can also get away with one single Rail now (You’ll see I tried to adjust the Curve Seam to match where the sweep was starting, but it seems to be irrelevant with MeshSweep and you can leave the seam unedited I think)

I tried to insert the logic back into the original file, but even with really accurate tolerance it was making garbled meshes - maybe it will work on your machine though.

20231121_Facade generation sweep and data structure.gh (65.1 KB)

CrvSeamTest.gh (38.5 KB)

-Sash

2 Likes

Dear Sash,

Thank you so much for your help, elegant scripting solution : now we have clean geometry and clean data strucutre, much more faster now that we are working with mesh.

The fact that you mentionned auto-Orientation, made me think : if I have control over the orientation that would solve everything … How about I try with SWEEP-2, and guess what : that made the trick !

Here is the final script that works with nurbs (so a tad slower than meshes, but still pretty quick) we get :

  • No need to cut the rail
  • Clean geometry (so nice for elevation drawing (make2D…) and also for volume assessment)
  • Clean data structure for processing LCA evaluation (by material subdivision)

Thank you again :slight_smile: and see you around !

20231124_Facade generation sweep and data structure.gh (25.3 KB)

1 Like