Yes I understand. In my youth we had a family company woodshop, where we made stairs, windows doors and “anything” really. But I never made these handrails. Looks impressive!
But this (the direction of the box) was one reason I added the mesh conversion, and from its vertices a PlaneFit could be drawn as a starting plane. Sometimes this is useful, sometimes not. Just connect the wire, or disconnect it if it gets too ugly.
I also noticed that the Volume actually changes if you use the mesh or the Brep in the last definition. For better or worse, try different combinations and keep what suits you the best.
Thank you, the Mitch’s script method already gave better results for thickness than the traditionnal drafting method. It looks your script have very similar results. Thank you again for your help.
Hey All, Thanks for this lovely work, I was happily surprised to find exactly what I was looking for here! I used as a base @RIL code and adjusted a bit. Mainly 1) added support for a List of Geometries, 2) Wrote it as a precompiled library and finally 3) added the option to only rotate particular axis (right click to change).
Hey @Max3 yes it requires a bit more work to use it. My intention wasn’t to make it difficult but to give the opportunity for people that want to use just this component on their library. An easy way for you to use it would be to download the latest release here: https://github.com/psarras/GH-Misc-Toolbox/releases/tag/v0.0.4
On the second attempt, I set degrees to 5 before connecting geometry (a simple tapered pipe), and it worked perfectly, with a 500ms processing time. When I switched degrees to 2, it crashed again.
Running a Zbook G3 portable workstation (two years old) with 48gb RAM, fwiw.
I love the simplicity of this component. It should be a standard component.
Hey @Max3. I realised I should have mentioned this was build using Rhino5. I created a new build that I checked works with Rhino6. It should be way faster than 500ms, in my tests it surpassed the original version (not because I changed something significant, just because it is compiled, I guess).
Maybe it helps someone, maybe it doesn’t. The diff between the codes was that I was using
When the Rhino 5 version runs on a Rhino 6 system, it crashes it, however it compiles correctly when using the RhinoCommon / Grasshopper binaries for Rhino6.
Downloaded, unblocked, moved to components folder, got an error. It’s not showing up in my components bar. Looks like it won’t load in Rhino 6, but it works in the Rhino 7 WIP. In the WIP, my test geometry takes 2.5 seconds to process at 1 degree. I can’t crash it.
hmm… this is odd as it works on my version of Rhino6. I using this version: Which seems newer to yours. Maybe try to force update?
I think the slow down you are getting is due to the nature of the function GetBoundingBox, which is out of our direct control. I think in particular this specific Brep is difficult to compute. However, a quick fix is to cast your Brep to a Mesh before passing it here dropping it down to 11ms or lower
I also found that the difference in max thickness that I got between setting it at one degree and setting it at ten degrees was under 0.01 units, which is more than adequate for my use, which is optimizing stock use for CNC routing. It’s pretty consistently that good, even when I warp the solid I’m testing.
The variation I’m getting when I A/B using fit plane and using the XY plane is up to 0.3 units, which is significant enough to matter. I’m going to play with that in more contexts, though because there are so many variables in how the fit works out.
Thanks again. This is super useful to me. Immediate real world application! Yay!
Thanks @Helvetosaur and @dharman for this gh component - it means I don’t need galapagos to get an efficient, oriented bounding box. Finding a close bounding box is the first stage in analysing my model solution space - and now I don’t have to run galapagos for each and every iteration, I have some hope of automating that analysis. Life savers!
Hey @architect.civil5 ! I don’t think I’ve made any changes on the newer version I was just experimenting with some Actions on Github, I would use the previous link I shared. Cheers!
Hi Mitch! I have been following this issue and downloaded your phyton definition and its amazing! it works perfectly… Do you have a reduce version to calculate only planar objects and a minimun oriented bounding rectangle?
I tried this component, which works well, except it does not preserve the data structure of the input in its output, which makes it unusable for me.
Does anyone have thoughts about how to implement a more simple minimum oriented bounding box problem in GhPython? Here’s the scenario:
Every input geometry I will be working with is a skewed or modified rectangular prism. They are wood beams, rafters, posts, some with angled cuts on the ends, some with notches (bird’s mouths). So overall the form is rectilinear, except on the ends, or some notches on the long faces.
I am working towards drawing the centerline of each of these members, which I have achieved in a python script, by creating a bounding box, and drawing a line between the centroids of the two smallest faces of the bounding box.
I am using the minimum bounding box component linked above, but for a number of reasons I would like to make my own in python. However, I have not yet been successful. I tried to orient the bounding box to the largest face (or one of them as there will always be at least two with identical area) of the original geometry, which would by definition identify also the primary axis or long axis of the member. However, I can’t seem to solve that.
I can share my code, but I am mainly interested in how you all would approach it.
Which seems newer to yours. Maybe try to force update?
