bottom_half: cp arg is confusing about bosl HOT 11 CLOSED

That would be a bug, not a feature.

from bosl.

Actually, scalar cp in negative directional halves is arguably correct. It actually matches what the documentation states. But yes, the multiple translates are silly. I can remove two translates in each half function.

from bosl.

I know it matches the documentation. But it does not make intuitive sense to me. It took me a while to realize that the documentation described this unexpected behavior. So why do it like that?

from bosl.

It’s moving the cut plane in the vector direction of the halving.

from bosl.

All the *_half() modules share the same code with only a difference of the vector direction for the cut mask. Thus the scalar cp is defined in terms of that vector. If your getting the bottom_half(), the scalar cp is moving the cut plane away from the origin towards the bottom. It seemed fully consistent to me.

from bosl.

Another way to think of it is that a positive scalar cp always masks away more of the part being halved.

from bosl.

I could see an argument for inverting that, to make positive scalar cp make the part larger.

To be honest, having the scalar cp as just a shortcut for the coordinate cp didn’t even occur to me, as the scalar implied distance instead of position, and therefore the direction would be implied by the orientation of the cut.

from bosl.

I completely understand what you have done. I just find it unnatural, and unexpected (as indicated by the length of time I took me to figure it out...even after consulting the documentation, which is not unclear). I guess I just don't feel like there is an implied direction. I don't imagine this as a translation operation but as cutting at a designated position. To me it seems like

union() { top_half(cp=A) thing(); bottom_half(cp=A) thing() }

should be the whole thing(). I don't really understand the utility of the cp=[dummy1,dummy2,z] notation. I guess if you wanted to make a cube corner or something it would be handy, but mostly it seems like extra clutter. I think I probably would have done it as top_half(z=cut_location), right_half(x=location), left_half(x=location), etc.

from bosl.

I guess it's because, in my head, it's all generalized from the half_of() module, where cp is an arbitrary point on the not-necessarily axis oriented cut plane. I can see merit in the x, y, or z notation, though.

from bosl.

Added x, y, and z args to *_half() modules in BOSLv1 master branch commit 8c0f979

from bosl.

Implemented in BOSL2 master branch commit a6a2ed520bbd834a02005f7a803f74e3eda636a8

from bosl.