Hi, I want to split 1 box with same length line to 8 small boxes(like rhino capture file). I tried to use panel components and make a some srf for trimming, but it is failed. (maybe it is because of my skill of grasshopper)
If you know the solution, please let me know about that, sorry for bad english.
Instead of splitting, you can scale the box by its center point by 0.5, then move the scaled box in the 8 vector directions from the center to each of the original vertices, scaling the vectors by 0.5.
To make sure the sub boxes are made ‘from the center out’ but always kept within the bounds of the parent box. For this the method is dividing the domain of the box dimensions (width, depth, height) into sub-domains.
Yes. I figured that out after some thinking. Does it still work if the box is rotated because of the world unit vectors?
… it does not. This is the first time I have seen the Edges From Direction component used. Being a novice, I am always greatful to see a component I don’t know being used in simple context. What does the Reflex Angle input of the component do, assuming I understand what a reflex angle is?
This one is a ‘true/false’ indication affecting how the Edges from directions component determines edge selection relative to specified direction you’re matching. This can help with other more complex breps - in this new case the box is ‘axis-aligned’ so switching the ‘R’ between true and false might not have any visible effects.
*Ultimately, we don’t strictly require the use of Edges from directions, to find width, depth, and height dimensions of a box, but it was a quickie here. An alternative would be to evaluate the box in U, V, and W (all of these 0 to 1) to get these dimensions as well.
For a more generalized subdivision, another technique (similar to other posts) is to scale by the inverse of the divisions in that direction and then use Box Array with the scaled geometry. The only caveat, since Box ArrayEDIT:the Bounding Box after Scale NU(I made the wrong assumption, see later posts) uses World XYZ as a plane, is to orient the geometry to XY plane and then back. Here’s the core, before and after are a base plane generation and visualization.
Yes. This is pretty much the solution I came up with in my last post, though I still struggle to understand why your generalized solution requires a reorientation of the geometry, while my doesn’t.
@ale2x72
After looking at it for a while, I think it is the difference between my solution providing the Cell input of the Box Array with a box, while your solution provides it with a brep. This would mean that the Box Array does not actually always assume the World XYZ plane!
See here where I plug in my scaled Box into your definition: Box subdivision 2.gh (11.2 KB)
Thank you very much for taking the time to explain in images and steps this intricacy. It pretty much cleared everything up for me. Much appreciated.
So, since the bounding box of a non-uniformly scaled geometry is oriented to the world plane and not the plane of the geometry’s construction, the Box Array will array according to world XYZ directions. In my case, since the geometry is a box created at scale, its bounding box will always match the geometry. My point still stands though. Box Array does not always array according to the XYZ plane, but rather on the basis on the plane of the bounding box passed to it through the the Cell input.