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.
Here’s another equally naïve approach for a given box, inspired by @Volker_Rakow’s example :
*oops, screenshots don’t match each other lol, my bad - script works, though.
Yes. Mine breaks if the same base plane and origin are not assumed for the two boxes.
I am trying to understand your script. Is there a reason that you are creating domains centered around 0?
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?
Great question and great catch - let me fix that.
Here’s an adjustment:
sub-box.gh (21.9 KB)
Summary:
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.
This only works for a single subdivision of the box, where as the OP asks for 8. 
I see. So could solve the problem using your UV coordinates and my Box Array thusly:
(Planes are merged first into the List Item component)
sub-box 3.gh (17.9 KB)
OP’s question:
I understood he wanted 8 smaller boxes as a result, not split 8 times
You are correct, and I was mistaken. Sorry about that.
Hey, no problem at all!
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 Array EDIT: 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)
Here’s what happens with different subdivision values in X, Y and Z without orienting to XY plane:
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.
Correct, I assumed the wrong explanation earlier, it follows the Cell orientation plane indeed.
