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.
Thank you so muchGebouw 2.2_hh_13.gh (52.5 KB)
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.
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).
hi @Joseph_Oster its really wonderful solution !
in the script before surface offset set curve the data 512 and after its offset it becomes 559
i tried to fix this but failed could u show how to fix it too…
regards
RP
still i see open curves after the offset curve ! from 559 it increase to 614
Sorry, you’ll have to ask McNeel why our results are different, I have no clue.
Yeah i tried it this way myselft before. But it doesn’t work because of it being not perpudicular to the tubes that hold the frames. :C
I will try to clean it up for you, so you can take a better look at it also i will change my settings to be the same as yours.
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.
