Native OpenSCAD includes the ability to place a cube based on a center point,
rather than based on one corner. E.g. *cube([10,10,10]);* <http://forum.openscad.org/file/t2397/Capture1.png> vs *cube([10,10,10], center=true);* <http://forum.openscad.org/file/t2397/Capture2.png> I find, however, that I often need to center the cube in just one dimension, for example y axis only. Thus I sometimes write the following code to extend cube centering functionality: * module cube2(size, center=[0,0,0]) { translate([-(size.x/2)*center.x, -(size.y/2)*center.y, -(size.z/2)*center.z]) cube(size); } * Examples of use: *TestSize = [10,10,10]; color("red") cube2(TestSize, center=[0,1,0]); color("blue") cube2(TestSize, center=[1,0,1]);* <http://forum.openscad.org/file/t2397/Capture3.png> Feature request: I would like to see this implemented into native OpenSCAD. Thus the center parameter would be overloaded as follows: -- If a boolean (true / false) is passed, then it would work as previously. -- if an expression that evaluates to 0, then interpreted as false, if any other number, then as true. (currently passing in "1" is interpreted as false.) -- if a vector ([1,1,1]) is passed, then each element is interpreted as boolean for each dimension. E.g. center.x would be parameter for centering in x axis, and so on for .y and .z I suspect this would be a relatively easy bit of code to implement. Yes, I can just make my own custom library and include this for my own use. But does anyone else think this would be a helpful addition to the native language? Thanks Kevin T -- Sent from: http://forum.openscad.org/ _______________________________________________ OpenSCAD mailing list [hidden email] http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org |
Much more useful extensions have been rejected as unnecessary complication,
so I doubt you'll see this in native OpenSCAD. Especially since it is easy to do what you want with user-written modules...or many would argue by just sticking a translate() in front of your cube. The BOSL2 library supports this via a syntax like: cuboid([10,10,10], anchor=LEFT) which places the center of the left side of the cube on the origin, or equivalently anchor=[-1,0,0]. (So that's centered in y and z.) You could use anchor=[-1,0,-1] or equivalently anchor=LEFT+BOTTOM to center on Y only. kdtop wrote > Native OpenSCAD includes the ability to place a cube based on a center > point, > rather than based on one corner. E.g. > > *cube([10,10,10]);* > > <http://forum.openscad.org/file/t2397/Capture1.png> > > vs > > *cube([10,10,10], center=true);* > > <http://forum.openscad.org/file/t2397/Capture2.png> > > I find, however, that I often need to center the cube in just one > dimension, > for example y axis only. -- Sent from: http://forum.openscad.org/ _______________________________________________ OpenSCAD mailing list [hidden email] http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org |
In reply to this post by kdtop
It seems useful, but also pretty trivial to implement in userspace. The cube I use in most of my code specifies x, y, and z offsets for the faces. There are any number of ways to specify a cube, and it is difficult to justify any particular ones as being necessary On Sun, 29 Nov 2020, 11:36 kdtop, <[hidden email]> wrote: Native OpenSCAD includes the ability to place a cube based on a center point, _______________________________________________ OpenSCAD mailing list [hidden email] http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org |
In reply to this post by kdtop
Kevin,
What you're asking is the perfect example of feature creep. A feature that does not add any value to the existing code. If you really want it, create a module that will do what you want, and don't bloat a good feature with useless stuff. Just my two cents, Jean-Paul N1JPL
_______________________________________________ OpenSCAD mailing list [hidden email] http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org |
I often want the XY centred and not Z, or perhaps vice versa. That can be done by linear_extude() square() because you get two separate center parameters. On Sun, 29 Nov 2020 at 16:59, Jean-Paul Louis via Discuss <[hidden email]> wrote: Kevin, _______________________________________________ OpenSCAD mailing list [hidden email] http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org |
In reply to this post by OpenSCAD mailing list-2
It is also the perfect example of why the "OpenSCAD language - replace it with Python3" discussion thread is worth reading.
Cheers, RobW On 30 November 2020 3:59:04 am AEDT, Jean-Paul Louis via Discuss <[hidden email]> wrote: Kevin, _______________________________________________ OpenSCAD mailing list [hidden email] http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Rob W
Lake Tyers Beach, Victoria, Australia |
Thanks for the replies. I guess I will just keep it in a library for myself. Kevin T On Sun, Nov 29, 2020 at 12:20 PM Rob Ward <[hidden email]> wrote:
_______________________________________________ OpenSCAD mailing list [hidden email] http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org |
In reply to this post by kdtop
I just made my own cube module, which has three extra arguments, xalign,
yalign and zalign. If they are 0, it's centered, if -1, the bottom (or, more precisely, the negative side) aligns with the axis, if 1, the top (the positive side) aligns with the axis. Literally a 5 minute job to make. I don't see a need for this in the core language. -- Sent from: http://forum.openscad.org/ _______________________________________________ OpenSCAD mailing list [hidden email] http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org |
In reply to this post by kdtop
Before I added the anchor= functionality to BOSL2, I used to have upcube(), leftcube(), etc modules that centered the cube above, to the left, etc of the origin. -Revar On Nov 29, 2020, at 10:07 AM, Kevin Toppenberg <[hidden email]> wrote:
_______________________________________________ OpenSCAD mailing list [hidden email] http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org |
In reply to this post by kdtop
I have a module jcube (for justified cube) that takes dims and a
[jz,jy,jz] justify vector where -1 means the cube goes negative from
the origin, 0 means centered, and +1 means positive from the origin.
It's based on a more general justify module that similarly justifies its children. It takes a bounding box (either [dx,dy,dz] dimensions with an implied origin at [0,0,0], or [[ox,oy,oz], [dx,dy,dz]]) and a justify vector as above. Both also take a simple boolean center equivalent to j=[0,0,0], but I don't know if I've ever used it since it's longer. With respect to whether such a feature should be in the base... undecided. It could certainly be in MCAD and so available in every installation. Argument for putting it in the base: so you don't have to have a module that is almost, but not quite, the same as "cube". Also helps to establish a convention for how to represent this sort of justification, so that it's obvious how justifying a cylinder, or sphere, or whatever would work. Argument against: it doesn't need to be. (But note: "center" doesn't need to be either, so we aren't strictly minimal.) use <default.scad> // @brief Given an [x,y] or an [x,y,z], return an [x,y,z]. // @param a A two- or three- element array // @returns A three-element array function make3(a) = assert(len(a) == 2 || len(a) == 3) len(a) == 3 ? a : concat(a, 0); // @brief Justify children as specified by argument. // @param center Equivalent to justify=[0,0,0]. // @param j [jx,jy,jz]: // +1 toward-positive // 0 center // -1 toward-negative // @param bb Bounding box: // [dimx,dimy,dimz] // [ [ox,oy,oz], [dimx,dimy,dimz] ] // @children Object(s) to be justified. // @note Works for two- or three- dimensional objects. // @note If more than one object is supplied as a child, they // are all justified en mass with respect to the specified // bounding box. module justify(center, j, bb) { origin = make3( assert(is_list(bb)) is_list(bb[0]) ? assert(len(bb) == 2) bb[0] : [0,0,0] ); dims = make3( is_list(bb[0]) ? bb[1] : bb ); j = make3(default(j, center ? [0,0,0] : [1,1,1])); function o(flag, dim) = flag > 0 ? 0 : flag < 0 ? -dim : -dim/2; translate([o(j[0], dims[0]), o(j[1], dims[1]), o(j[2], dims[2])]) translate(-origin) // Move BB minima to [0,0,0] children(); } // @brief A justified cube // @param dims Dimensions of the cube // @param center Equivalent to j=[0,0,0] // @param j As for justify() above module jcube(dims, center, j) { justify(center=center, j=j, bb=dims) cube(dims); } // Test/demos for (xj=[-1:1], yj=[-1:1], zj=[-1:1]) { justify(j=[xj,yj,zj], bb=[[-10,-10,-10],[20,20,20]]) color([(xj+1)/2, (yj+1)/2, (zj+1)/2]) sphere(r=10); } translate([30,0]) for (xj=[-1:1], yj=[-1:1]) { justify(j=[xj,yj], bb=[[-10,-10],[10,10]]) color([(xj+1)/2, (yj+1)/2, 0]) circle(r=10); }
It depends on a trivial function "default": function default(val, def) = is_undef(val) ? def : val;
_______________________________________________ OpenSCAD mailing list [hidden email] http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org |
In reply to this post by OpenSCAD mailing list-2
On 29 Nov 2020 at 16:59, Jean-Paul Louis via Discuss wrote:
> What you're asking is the perfect example of feature creep. A feature that does not add any value > to the existing code. And your response is a perfect example of the reason I use the BOSL2 library for almost everything now. I say almost, because I have a friend that I collaborate with on some designs, who apparently can't use BOSL2 on his Linux box. > If you really want it, create a module that will do what you want, and don't bloat a good feature with > useless stuff. What you find useless is certainly not useless to everyone, and in particular, folks just starting with OpenSCAD, having to noodle their way through things that you find simple, are often so intimidated that they end up never using it again. > Just my two cents, Exactly. _______________________________________________ OpenSCAD mailing list [hidden email] http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org |
lar3ry wrote
> On 29 Nov 2020 at 16:59, Jean-Paul Louis via Discuss wrote: >> What you're asking is the perfect example of feature creep. A feature >> that does not add any value >> to the existing code. > > And your response is a perfect example of the reason I use the BOSL2 > library for almost everything now. I say almost, because I have a friend > that I > collaborate with on some designs, who apparently can't use BOSL2 on his > Linux box. Seems odd. BOSL2 works fine on my Linux box...and there is nothing machine dependent about it. It's developed for the stable version of OpenSCAD and doesn't work properly with some of the recent snapshots. Could it be a path setting issue? > If you really want it, create a module that will do what you want, and > don't bloat a good feature with > useless stuff. What you find useless is certainly not useless to everyone, and in particular, folks just starting with OpenSCAD, having to noodle their way through things that you find simple, are often so intimidated that they end up never using it again. As you know, I'm a big proponent of libraries. And yet that doesn't mean that I think features like this necessarily belong in the base language. It would be nice if it was possible to more cleanly extend the functionality of base modules by redefining existing modules and then calling the base language module. But it definitely seems reasonable to keep the base language simple. I'd rather see developments in the base language that implement fundamentally different things that are really hard to do in userspace rather than trying to build out more complex interfaces that are trivial userspace extensions. The point is that you have the option of using a library, be it BOSL2 or some other library you choose, to provide these extensions. So what is the argument for including them in the base language? I would suggest that libraries should play a bigger role. Nobody uses C or Python without using the libraries. If you think users are being scared away the answer is to introduce them to OpenSCAD with some suitable library. -- Sent from: http://forum.openscad.org/ _______________________________________________ OpenSCAD mailing list [hidden email] http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org |
In reply to this post by OpenSCAD mailing list-2
OpenSCAD mailing list-2 wrote
> Kevin,What you're asking is the perfect example of feature creep. A > feature that does not add any value to the existing code. If you really > want it, create a module that will do what you want, and don't bloat a > good feature with useless stuff. Well, don't judge this hard. There are a lot of feature requests like this around in this forum and they all have their right. You can certainly find workarounds by writing some specific modules or lets say rewriting OpenSCAD's primitives. It was one of the first steps to write my own shortcuts library when I started programming with OpenSCAD. However, 1. while we can overload a native module, the price is that we loose access to the native module. Therefore, we can't implement our own cube by referring to the native cube module and have to use either different names or different techniques (like linear_extrude for implementing a cube) 2. we can't quest modules about their objects in lack of a boundingbox() function and so on. Therefore, we can't align or center any stuff, without knowledge of the critical design parameters, which is a nightmare especially with imported objects. 3. in the early days of OpenSCAD native modules were defined in a kind of stubborn fashion with respect to their defaults and parameter names. E.g. a cube/square is not centered at all, a cylinder/circle is partly centered, cylinder() and linear_extrude() don't allow for a negative height and also use different parameter names for defining the height. Operators like translate, scale and rotate have their own weired parameter logic instead of allowing calls like translate(x=10). This means there is a lot stuff one can criticize and might want to have corrected in the native appearance of OpenSCAD. Of course one can find and put workarounds into an own library. But this has the effect that every second programmer ends up writing and maintainig his own lib, while others don't get tired to extol specific libraries like BOSL2. In this sense I think the feature being requested by the TS has all rights to be treated as a serious request. However the proposed solution might be to specific, since all OpenSCAD objects more or less suffer from this alinging problem, which triggers the request for an align-operator module align([x,y,z]=[0,0,0]) children; and/or even better: module align(x=0, y=0, z=0) children() where a negative, zero, or positive value for x, y, z enforces an alignment to the negative side, center or positive side of the respected axis. While such an operator could be used in a very general way it might bring up the question whether it would have to use CGAL if applied to a Boolean expression. Without having thought about this issue extensively my idea would be that a boundingbox logic could do. -- Sent from: http://forum.openscad.org/ _______________________________________________ OpenSCAD mailing list [hidden email] http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org |
Free forum by Nabble | Edit this page |