>This is a bug in preview. Ideally it should be reported as a bug and fixed. It has been discussed before. I think it is a limitation of OpenCSG. Presumably crop could be a user module in OpenSCAD that just intersects with a cube defined by the bounds. module crop( xmin, ymin, zmin, xmax, ymax, zmax) intersection() { children(); translate([xmin, ymin, zmin]) cube([xmax - xmin, ymax - ymin, zmax - zmin]); } On 28 December 2016 at 19:19, doug moen <doug@moens.org> wrote: > nophead: "I was trying to illustrate the problem you get using a big cube > to emulate a plane. It needs to be bigger than the part of the object you > want to slice off. You then can't zoom in any closer than that or the > preview goes wrong." > > This is a bug in preview. Ideally it should be reported as a bug and fixed. > > "A plane would be mathematically neater but does OpenCSG support planes? > And once you introduce a new class of object you have to decide how it > interacts in all operations. Hull of a plane would be what? union of two > planes? Minkowski... Very easy to make infinitely sized objects. A big can > of worms and lots of code changes for something that already has a couple > of simple workarounds." > > My OpenSCAD variant has a `crop` operation: > crop( xmin=, ymin=, zmin=, xmax=, ymax=, zmax= ) shape > All of the arguments are optional; each specifies a different axis aligned > clipping plane. I think this interface could be implemented in OpenSCAD > preview and render without running into implementation problems. > > Infinite objects *are* actually useful, and a number of OpenSCAD's > competitors support them, including the system I'm working on. But I > agree with Nop Head that it is unlikely that OpenSCAD itself would be > extended to support them: it would be a big change. > > Internally, my `crop` operator intersects the shape with a series of > half-spaces (in 3D) or half-planes (in 2D). These objects are directly > supported by CGAL (a half-space is a Nef polyhedron). So these are the > infinite objects I imagine we'd add (rather than planes) to support writing > `crop` as an OpenSCAD library module. > > > > On 28 December 2016 at 05:57, nop head <nop.head@gmail.com> wrote: > >> Because I was trying to illustrate the problem you get using a big cube >> to emulate a plane. It needs to be bigger than the part of the object you >> want to slice off. You then can't zoom in any closer than that or the >> preview goes wrong. >> >> If you wrap it in render() then preview works but is slower the first >> time. I wrap all my objects in render(), otherwise they interfere with each >> other in an assembly. >> >> A better solution to cutting part of an object off is to intersect it >> with a cube, instead of differencing it. The cube is then the size of the >> bit you want to keep, so zooming in is no problem. >> >> A plane would be mathematically neater but does OpenCSG support planes? >> And once you introduce a new class of object you have to decide how it >> interacts in all operations. Hull of a plane would be what? union of two >> planes? Minkowski... Very easy to make infinitely sized objects. A big can >> of worms and lots of code changes for something that already has a couple >> of simple workarounds. >> >> On 27 December 2016 at 19:06, adrian <adrianh.bsc@gmail.com> wrote: >> >>> Why not just specify the height explicitly like this? >>> >>> cube ([1000,1000,1]) >>> >>> That way, you would be specifying a slice of defined height. >>> >>> >>> >>> -- >>> View this message in context: http://forum.openscad.org/Requ >>> est-for-Plane-Primitive-tp19750p19785.html >>> Sent from the OpenSCAD mailing list archive at Nabble.com. >>> >>> _______________________________________________ >>> OpenSCAD mailing list >>> Discuss@lists.openscad.org >>> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org >>> >> >> >> _______________________________________________ >> OpenSCAD mailing list >> Discuss@lists.openscad.org >> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org >> >> > > _______________________________________________ > OpenSCAD mailing list > Discuss@lists.openscad.org > http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org > >

What makes crop tricky is that all of the arguments are optional. If you just specify one argument, then you are only specifying a single clipping plane. For example, crop(zmin=0) shape removes everything in the negative z axis, without the requirement to know in advance how large 'shape' is. Here is a "good enough" implementation of `crop` in OpenSCAD. module box(xmin,ymin,zmin,xmax,ymax,zmax) polyhedron( [[xmin,ymin,zmin], // 0 [xmin,ymin,zmax], // 1 [xmin,ymax,zmin], // 2 [xmin,ymax,zmax], // 3 [xmax,ymin,zmin], // 4 [xmax,ymin,zmax], // 5 [xmax,ymax,zmin], // 6 [xmax,ymax,zmax]], // 7 [[7,5,1,3], // top [2,0,4,6], // bottom [5,4,0,1], // front [3,2,6,7], // back [5,7,6,4], // right [0,2,3,1]] // left ); inf = 1e10; module crop(xmin=-inf, ymin=-inf, zmin=-inf, xmax=inf, ymax=inf, zmax=inf) render() intersection() { children(); box(xmin,ymin,zmin,xmax,ymax,zmax); } crop(zmin=0) sphere(5); This relies on Nop Head's render trick to make preview work. The variable 'inf' is supposed to represent floating point infinity, but OpenSCAD doesn't like infinite objects, so I picked a number large enough for most models, but small enough that CGAL still works. On 28 December 2016 at 14:41, nop head <nop.head@gmail.com> wrote: > >This is a bug in preview. Ideally it should be reported as a bug and > fixed. > > It has been discussed before. I think it is a limitation of OpenCSG. > > Presumably crop could be a user module in OpenSCAD that just intersects > with a cube defined by the bounds. > > module crop( xmin, ymin, zmin, xmax, ymax, zmax) > intersection() { > children(); > translate([xmin, ymin, zmin]) > cube([xmax - xmin, ymax - ymin, zmax - zmin]); > } > > > > On 28 December 2016 at 19:19, doug moen <doug@moens.org> wrote: > >> nophead: "I was trying to illustrate the problem you get using a big >> cube to emulate a plane. It needs to be bigger than the part of the object >> you want to slice off. You then can't zoom in any closer than that or the >> preview goes wrong." >> >> This is a bug in preview. Ideally it should be reported as a bug and >> fixed. >> >> "A plane would be mathematically neater but does OpenCSG support planes? >> And once you introduce a new class of object you have to decide how it >> interacts in all operations. Hull of a plane would be what? union of two >> planes? Minkowski... Very easy to make infinitely sized objects. A big can >> of worms and lots of code changes for something that already has a couple >> of simple workarounds." >> >> My OpenSCAD variant has a `crop` operation: >> crop( xmin=, ymin=, zmin=, xmax=, ymax=, zmax= ) shape >> All of the arguments are optional; each specifies a different axis >> aligned clipping plane. I think this interface could be implemented in >> OpenSCAD preview and render without running into implementation problems. >> >> Infinite objects *are* actually useful, and a number of OpenSCAD's >> competitors support them, including the system I'm working on. But I >> agree with Nop Head that it is unlikely that OpenSCAD itself would be >> extended to support them: it would be a big change. >> >> Internally, my `crop` operator intersects the shape with a series of >> half-spaces (in 3D) or half-planes (in 2D). These objects are directly >> supported by CGAL (a half-space is a Nef polyhedron). So these are the >> infinite objects I imagine we'd add (rather than planes) to support writing >> `crop` as an OpenSCAD library module. >> >> >> >> On 28 December 2016 at 05:57, nop head <nop.head@gmail.com> wrote: >> >>> Because I was trying to illustrate the problem you get using a big cube >>> to emulate a plane. It needs to be bigger than the part of the object you >>> want to slice off. You then can't zoom in any closer than that or the >>> preview goes wrong. >>> >>> If you wrap it in render() then preview works but is slower the first >>> time. I wrap all my objects in render(), otherwise they interfere with each >>> other in an assembly. >>> >>> A better solution to cutting part of an object off is to intersect it >>> with a cube, instead of differencing it. The cube is then the size of the >>> bit you want to keep, so zooming in is no problem. >>> >>> A plane would be mathematically neater but does OpenCSG support planes? >>> And once you introduce a new class of object you have to decide how it >>> interacts in all operations. Hull of a plane would be what? union of two >>> planes? Minkowski... Very easy to make infinitely sized objects. A big can >>> of worms and lots of code changes for something that already has a couple >>> of simple workarounds. >>> >>> On 27 December 2016 at 19:06, adrian <adrianh.bsc@gmail.com> wrote: >>> >>>> Why not just specify the height explicitly like this? >>>> >>>> cube ([1000,1000,1]) >>>> >>>> That way, you would be specifying a slice of defined height. >>>> >>>> >>>> >>>> -- >>>> View this message in context: http://forum.openscad.org/Requ >>>> est-for-Plane-Primitive-tp19750p19785.html >>>> Sent from the OpenSCAD mailing list archive at Nabble.com. >>>> >>>> _______________________________________________ >>>> OpenSCAD mailing list >>>> Discuss@lists.openscad.org >>>> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org >>>> >>> >>> >>> _______________________________________________ >>> OpenSCAD mailing list >>> Discuss@lists.openscad.org >>> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org >>> >>> >> >> _______________________________________________ >> OpenSCAD mailing list >> Discuss@lists.openscad.org >> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org >> >> > > _______________________________________________ > OpenSCAD mailing list > Discuss@lists.openscad.org > http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org > >