A clipping plane would be very handy.

On Dec 26, 2016 1:09 PM, "Ronaldo Persiano" rcmpersiano@gmail.com wrote:

That would be trivial with a bounding box information. I don't understand
how OpenSCAD do resize() without computing a bounding box. And if it is
computed, why it is not available by a language function.

2016-12-26 16:21 GMT-02:00 Frank van der Hulst drifter.frank@gmail.com:

OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org

You can use an oversized cube, but it messes with zoom all if you are not careful about how oversized it is.

Exactly.. I could use lots of things with appropriate careful math.. A
clipping plane is easy and simple.  Povray has very similar csg constructs
and it would not be a bad example to follow.

On Dec 26, 2016 5:54 PM, "Greg Frost" gregorybartonfrost@gmail.com wrote:

I've never had these "camera issues" with a box, but that's probably
because I've never figured out how to do anything with the camera other
than zoom in or out from the origin (I've never panned with the camera, for
instance).

A plane construct would help me because sometimes it takes me a while to
figure out how big the box needs to be...

On Tue, Dec 27, 2016 at 9:17 AM, david vanhorn kc6ete@gmail.com wrote:

Dan:

Panning uses the right mouse button, and zooming uses the mouse scroll
wheel.  Very intuitive once you get used to it.

I usually figure out the box size through trial and error.  I can
usually do this in under a minute.

Jon

On 12/27/2016 7:53 AM, Dan Shriver wrote:

Try this:
//render()
difference() {
sphere(20);
cube(1000);
}

It wont render correctly until you zoom out far enough for the 1000  cube
to be in front of the view port front clipping plane. Not sure why, but it
shows the intersection instead of the difference when too close.

Then uncomment the render() and see that it renders properly, even when
close.

On 27 December 2016 at 12:53, Dan Shriver tabbydan@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:

I wasn't saying the camera issues didn't exist, just that I've never had
them (and that it was probably because I only zoom in and out and am
typically not "too close").

Boxes to get rid of part of the object tend to take me a lot more than a
minute to come up with, I can't quickly compute the size I need it my head.

On Tue, Dec 27, 2016 at 11:28 PM, nop head nop.head@gmail.com 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: