Request for Plane Primitive

classic Classic list List threaded Threaded
21 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Request for Plane Primitive

Richy_T
Sometimes, especially if you're 3D printing, you just want to cut off everything beyond a certain value. You can sort-of do this with a large cube but it's easy to make errors and if your camera ends up inside the cube, you get weird things happening so it would be really useful just to have a plane() primitive that you can just do difference() against or whatever.

Presumably there would have to be some restrictions because I'm guessing you couldn't export an actual plane to an stl file and other such fun things but as a virtual object, it would be extremely useful.
Reply | Threaded
Open this post in threaded view
|

Re: Request for Plane Primitive

frankv
I agree. It perhaps could also make mirror() more general. 

On 26/12/2016 19:28, "Richy_T" <[hidden email]> wrote:
Sometimes, especially if you're 3D printing, you just want to cut off
everything beyond a certain value. You can sort-of do this with a large cube
but it's easy to make errors and if your camera ends up inside the cube, you
get weird things happening so it would be really useful just to have a
plane() primitive that you can just do difference() against or whatever.

Presumably there would have to be some restrictions because I'm guessing you
couldn't export an actual plane to an stl file and other such fun things but
as a virtual object, it would be extremely useful.



--
View this message in context: http://forum.openscad.org/Request-for-Plane-Primitive-tp19750.html
Sent from the OpenSCAD mailing list archive at Nabble.com.

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: Request for Plane Primitive

nophead
You can get rid of the camera problems by using render() or intersection() instead of difference().

On 26 December 2016 at 06:42, Frank van der Hulst <[hidden email]> wrote:
I agree. It perhaps could also make mirror() more general. 

On 26/12/2016 19:28, "Richy_T" <[hidden email]> wrote:
Sometimes, especially if you're 3D printing, you just want to cut off
everything beyond a certain value. You can sort-of do this with a large cube
but it's easy to make errors and if your camera ends up inside the cube, you
get weird things happening so it would be really useful just to have a
plane() primitive that you can just do difference() against or whatever.

Presumably there would have to be some restrictions because I'm guessing you
couldn't export an actual plane to an stl file and other such fun things but
as a virtual object, it would be extremely useful.



--
View this message in context: http://forum.openscad.org/Request-for-Plane-Primitive-tp19750.html
Sent from the OpenSCAD mailing list archive at Nabble.com.

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org



_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: Request for Plane Primitive

jon_bondy
In reply to this post by frankv

I've never had a problem using difference() and a cube.


On 12/26/2016 1:42 AM, Frank van der Hulst wrote:
I agree. It perhaps could also make mirror() more general. 

On 26/12/2016 19:28, "Richy_T" <[hidden email]> wrote:
Sometimes, especially if you're 3D printing, you just want to cut off
everything beyond a certain value. You can sort-of do this with a large cube
but it's easy to make errors and if your camera ends up inside the cube, you
get weird things happening so it would be really useful just to have a
plane() primitive that you can just do difference() against or whatever.

Presumably there would have to be some restrictions because I'm guessing you
couldn't export an actual plane to an stl file and other such fun things but
as a virtual object, it would be extremely useful.



_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: Request for Plane Primitive

nophead
The problem is that when viewed with F5 the camera has to be outside the big cube you use as a substitute for a plane. This is because OpenCSG does not draw the cube if any of it is beyond the clipping plane.

On 26 December 2016 at 12:31, jon <[hidden email]> wrote:

I've never had a problem using difference() and a cube.


On 12/26/2016 1:42 AM, Frank van der Hulst wrote:
I agree. It perhaps could also make mirror() more general. 

On 26/12/2016 19:28, "Richy_T" <[hidden email]> wrote:
Sometimes, especially if you're 3D printing, you just want to cut off
everything beyond a certain value. You can sort-of do this with a large cube
but it's easy to make errors and if your camera ends up inside the cube, you
get weird things happening so it would be really useful just to have a
plane() primitive that you can just do difference() against or whatever.

Presumably there would have to be some restrictions because I'm guessing you
couldn't export an actual plane to an stl file and other such fun things but
as a virtual object, it would be extremely useful.



_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org



_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: Request for Plane Primitive

Richy_T
In reply to this post by nophead
Hmm, intersection() might be a plan. I'm not familiar with render() but I'll give it a look.
Reply | Threaded
Open this post in threaded view
|

Re: Request for Plane Primitive

nophead
render() uses CGAL to actually compute the geometry and just leaves CGAL to render the resulting polyhedron.

On 26 December 2016 at 17:07, Richy_T <[hidden email]> wrote:
Hmm, intersection() might be a plan. I'm not familiar with render() but I'll
give it a look.



--
View this message in context: http://forum.openscad.org/Request-for-Plane-Primitive-tp19750p19764.html
Sent from the OpenSCAD mailing list archive at Nabble.com.

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: Request for Plane Primitive

frankv
In reply to this post by jon_bondy
One situation where it was a problem for me is dividing an imported STL (aircraft model) into halves... you need to know the size of the object so that you can draw a larger cube, but there's no way to find out what the size of the STL is.

On Tue, Dec 27, 2016 at 1:31 AM, jon <[hidden email]> wrote:

I've never had a problem using difference() and a cube.




_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: Request for Plane Primitive

Ronaldo
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 <[hidden email]>:
One situation where it was a problem for me is dividing an imported STL (aircraft model) into halves... you need to know the size of the object so that you can draw a larger cube, but there's no way to find out what the size of the STL is.



_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: Request for Plane Primitive

dbvanhorn
A clipping plane would be very handy. 

On Dec 26, 2016 1:09 PM, "Ronaldo Persiano" <[hidden email]> 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 <[hidden email]>:
One situation where it was a problem for me is dividing an imported STL (aircraft model) into halves... you need to know the size of the object so that you can draw a larger cube, but there's no way to find out what the size of the STL is.



_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org



_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: Request for Plane Primitive

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

On 27 Dec 2016, at 11:07 AM, david vanhorn <[hidden email]> wrote:

A clipping plane would be very handy. 

On Dec 26, 2016 1:09 PM, "Ronaldo Persiano" <[hidden email]> 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 <[hidden email]>:
One situation where it was a problem for me is dividing an imported STL (aircraft model) into halves... you need to know the size of the object so that you can draw a larger cube, but there's no way to find out what the size of the STL is.



_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: Request for Plane Primitive

dbvanhorn
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" <[hidden email]> wrote:
You can use an oversized cube, but it messes with zoom all if you are not careful about how oversized it is.

On 27 Dec 2016, at 11:07 AM, david vanhorn <[hidden email]> wrote:

A clipping plane would be very handy. 

On Dec 26, 2016 1:09 PM, "Ronaldo Persiano" <[hidden email]> 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 <[hidden email]>:
One situation where it was a problem for me is dividing an imported STL (aircraft model) into halves... you need to know the size of the object so that you can draw a larger cube, but there's no way to find out what the size of the STL is.



_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: Request for Plane Primitive

DanS
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 <[hidden email]> wrote:
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" <[hidden email]> wrote:
You can use an oversized cube, but it messes with zoom all if you are not careful about how oversized it is.

On 27 Dec 2016, at 11:07 AM, david vanhorn <[hidden email]> wrote:

A clipping plane would be very handy. 

On Dec 26, 2016 1:09 PM, "Ronaldo Persiano" <[hidden email]> 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 <[hidden email]>:
One situation where it was a problem for me is dividing an imported STL (aircraft model) into halves... you need to know the size of the object so that you can draw a larger cube, but there's no way to find out what the size of the STL is.



_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org



_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: Request for Plane Primitive

jon_bondy

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:
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...



_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: Request for Plane Primitive

nophead
In reply to this post by DanS
>I've never had these "camera issues" with a box

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 <[hidden email]> 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 <[hidden email]> wrote:
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" <[hidden email]> wrote:
You can use an oversized cube, but it messes with zoom all if you are not careful about how oversized it is.

On 27 Dec 2016, at 11:07 AM, david vanhorn <[hidden email]> wrote:

A clipping plane would be very handy. 

On Dec 26, 2016 1:09 PM, "Ronaldo Persiano" <[hidden email]> 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 <[hidden email]>:
One situation where it was a problem for me is dividing an imported STL (aircraft model) into halves... you need to know the size of the object so that you can draw a larger cube, but there's no way to find out what the size of the STL is.



_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org



_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org



_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: Request for Plane Primitive

adrian
Why not just specify the height explicitly like this?

cube ([1000,1000,1])

That way, you would be specifying a slice of defined height.
Reply | Threaded
Open this post in threaded view
|

Re: Request for Plane Primitive

nophead
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 <[hidden email]> 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/Request-for-Plane-Primitive-tp19750p19785.html
Sent from the OpenSCAD mailing list archive at Nabble.com.

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: Request for Plane Primitive

DanS
In reply to this post by nophead
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 <[hidden email]> wrote:
>I've never had these "camera issues" with a box

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 <[hidden email]> 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 <[hidden email]> wrote:
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" <[hidden email]> wrote:
You can use an oversized cube, but it messes with zoom all if you are not careful about how oversized it is.

On 27 Dec 2016, at 11:07 AM, david vanhorn <[hidden email]> wrote:

A clipping plane would be very handy. 

On Dec 26, 2016 1:09 PM, "Ronaldo Persiano" <[hidden email]> 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 <[hidden email]>:
One situation where it was a problem for me is dividing an imported STL (aircraft model) into halves... you need to know the size of the object so that you can draw a larger cube, but there's no way to find out what the size of the STL is.



_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org



_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org



_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org



_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: Request for Plane Primitive

doug.moen
In reply to this post by nophead
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 <[hidden email]> 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 <[hidden email]> 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/Request-for-Plane-Primitive-tp19750p19785.html
Sent from the OpenSCAD mailing list archive at Nabble.com.

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org



_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: Request for Plane Primitive

nophead
>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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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/Request-for-Plane-Primitive-tp19750p19785.html
Sent from the OpenSCAD mailing list archive at Nabble.com.

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org



_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org



_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
12