I think it only happens when fed more than one curve I think. I can select it, but can’t see it. Same in both 3D view and plan views. Seems to be somewhat random. Not a view settings issue as the other beams pictured were made by the same script, at the same time.
Also, what is the best way to get a floor’s perimeter curves? I have tried various methods including surface.perimeter, converting to faces and edge curves, and using spring nodes’ Collect.ElementSketch, but I have not been able to get 100% reliable results, at least when fed into the beam by curve node.
Can’t see what the issue is without seeing the graph itself. Can you post an image of the dyn with previews expanded?
1 Like
Sure, here you go. (The remainder of the script just determines and sets the Z Offset Value.)
I have also used the other methods to get the floor edges described above, I have seen the same issue. But it happens intermittently, and it was not reproduced in this screenshot.
Thanks, this seems like a good reliable method, I will give it a try. Always best not to use those custom nodes if possible though.
1 Like
Still seems unreliable, at least when fed to the beam by curve node. Weird stuff, not sure what is going wrong here.
weird, you can send part of your file I’ll take a look at it tomorrow morning (edit: it’s 6:30PM at my place right now)
cordially
christian.stan
Thanks! But I think figured out this issue - beams ends are auto-joining despite being dozens of feet apart. I disabled then re-enabled autojoins (with a transaction stop/start) and it seems to have worked. I also have not seen an invisible beam in about 30 test runs I just did.
I did notice however that while setting the beam orientation of all the new elements to left/right (which ones depends on which method used to get the curves) works 95% of the time, occasionally the beams are oriented the other way. Is there a way to determine whether the inside of the floor is to the left or right of the perimeter lines?
1 Like
The left/right should be determined by the direction of the curve.
If I recall you can join them into a polyline and extract the curves and the direction should be consistent.
Every method I used to get the edge curves has had a consistent direction around the perimeter, I would guess because they are all being extracted from closed polylines. And it is generally, 95%+ of the time, consistent in clockwise vs counterclockwise based on method. But not 100%.
But I’m still not really clear how to get the left/right direction. The line’s direction (expressed as start vs end points in modeling a beam) determines which side of the curve left and right offsets the beam, however I don’t know how to determine whether the floor is right or left of the curve based on start and end points to determine whether I need to use right or left.
I’d imagine if you have a closed loop, there would be a way to determine inside vs outside. That seems like a requirement to get this data. Not sure what it is (a normal?), or how to translate this information to a left/right direction based on start and end points of the edge curves.
you have an offset solution (half width of your family) of the polycurve then family based on the center
(a potential lead)
The normal is the vector perpendicular to a surface (by convention but not always often taken out of the material)
cordially
christian.stan
I don’t want to offset a beam centerline, that is an easy solution but not the best way to model an edge member.
I think I found a solution, to offset the curves along whatever normal that the curve.offset node uses (which seems to work the same way, positive = left, negative = right), and then choose a right/left direction based on whether that curve was offset towards or away from the centerpoint.