I am trying to design my building in GH. I have made the structural beams and defined al of the indidvidual windows. You can see it in the bottom right. What i made when i try it for just 1 window. However when i try to scale it up. It looks like the Offset cr on srf command breaks. I dont know exactly what the reason for this is. So i hoop that someone here knows what the problem is and tell me. It would help a lot.
I have no idea what youâre doing because Grasshopper froze up very badly when I tried to open your model. So badly that I feel obligated to add this WARNING!!! to anyone who else who tries.
Disable the solver before opening this file.
Then disable the SUnion at the end of the model and
disable all the Loft components feeding the SUnion and
disable the two Geometry params labeled âRamenâ prior to the red âHere it goes wrongâ group.
Because something in this model goes very wrong indeed!
I donât know what the objective is in this model. There are way too many visible âpreviewsâ that obscure whatever is important. That is, preview should be disabled on many components, which I did to some extent in this copy. I also disabled whole sections that freeze the code due to grafting errors.
The only little bit of sense I made of this is the highlighted Loft in the image below, which might be window frames? It still takes a long time when you open the model, but it doesnât freeze up.
It appears to me that some of the âwindowsâ in your image failed, as I see some gaps where rectangles are missing. This might explain the red color of the Loft component, though I would have to read the error message and examine the resulting geometry to be sure. I donât know the reason it is different for you but suspect Rhino settings such as âView | Display Options | Units | Absolute toleranceâ? But when I make changes to that value (mine is 0.001) it has no effect.
Did you make any changes to what I posted? If so, please post it again.
The model is difficult to follow because preview is enabled on so many components, and there are dead ends in the code that donât connect to anything.
I took a different approach in this version, using SrfSplit instead of Loft to get the window frame surfaces. Then I extruded them, exaggerating their thickness to make it more visible. Extrude isnât quite the same as offset surface but I was impatientâŚ
I used sFace(Shrink Faces) to circumvent issues with using EvalSrf on subsurfaces (split from a larger surface). I used List Item after SrfSplit to separate the frame surface from the window surface, assuming their index positions which is not always safeâŚ
And I disabled preview for many surfaces that cluttered the model.
As you can see, the largest time (41 secs.) is taken by OffsetS(Offset on Srf).
Please donât assume I will keep looking at this. I spent some time making sense of the model and your goals, despite major obstacles. I realize the extrude isnât as accurate as an offset surface (though the differences are very small in this case).
But I didnât like the idea of adding a second major delay to the code caused by OffsetS(Offset on Srf). Maybe you can extrude the window surfaces to make breps that cut both surfaces of the frames? In any case, I would add a Data Dam before that extremely slow OffsetS so that upstream changes donât always incur such a heavy performance penalty. Unfortunately, data dams have no effect when a file is first opened.