Need help creating a hole in a solid
Interesting, a void object created by a difference works as expected. So it
seems to be a problem with intersection(). That is probably why I haven't
come across it before.
difference() {
difference() {
cube(1);
cube(2);
}
cube(10, center = true);
}
On Wed, 1 Jul 2020 at 08:50, nop head nop.head@gmail.com wrote:
The intersection produces a void so, yes, the difference should be void
and that is what I get with F6 that uses CGAL.
With F5 I get a big cube stretched by the scale. It appears that the void
object is simply ignored and the big cube becomes the first operand of
difference. If you add sphere(50) as a third operand it gets subtracted
from the big cube.
It still goes wrong with simple integers.
difference() {
intersection() {
cube(1);
translate([2,0,0]) cube(1);
}
cube(10, center = true);
}
I am using OpenSCAD 2020.04.26.ci4968, is this a regression? I think I
would have noticed such a simple bug.
On Tue, 30 Jun 2020 at 22:25, Ronaldo Persiano rcmpersiano@gmail.com
wrote:
nop head nop.head@gmail.com wrote:
CGAL will handle exact differences fine as long as they are exact, which
the height is. F6 gives this.
Yes, but when they aren't exact some surprises come from render:
scale([1e6,1,1])
translate([-1,0,0])
difference(){
intersection(){
cube(1);
translate([1+1e-6,0,0]) cube(1);
}
translate([1,1,1]/2) cube(100);
}
Would you expect a non void object from this?
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
When the two cubes overlap I get this as the CSG products
CSG before normalization:
((cube4 * cube6) - cube7)
CSG after normalization:
((cube4 * cube6) - cube7)
CSG rendering chain:
+cube4 *cube6 -cube7
When there is no overlap I get this:
CSG before normalization:
cube7
CSG after normalization:
cube7
CSG rendering chain:
+cube7
So it looks like something does a bounding box analysis and takes a
shortcut because geometry isn't evaluated during preview, so how would it
know that the intersection is empty?
On Sat, 4 Jul 2020 at 12:33, nop head nop.head@gmail.com wrote:
Interesting, a void object created by a difference works as expected. So
it seems to be a problem with intersection(). That is probably why I
haven't come across it before.
difference() {
difference() {
cube(1);
cube(2);
}
cube(10, center = true);
}
On Wed, 1 Jul 2020 at 08:50, nop head nop.head@gmail.com wrote:
The intersection produces a void so, yes, the difference should be void
and that is what I get with F6 that uses CGAL.
With F5 I get a big cube stretched by the scale. It appears that the void
object is simply ignored and the big cube becomes the first operand of
difference. If you add sphere(50) as a third operand it gets subtracted
from the big cube.
It still goes wrong with simple integers.
difference() {
intersection() {
cube(1);
translate([2,0,0]) cube(1);
}
cube(10, center = true);
}
I am using OpenSCAD 2020.04.26.ci4968, is this a regression? I think I
would have noticed such a simple bug.
On Tue, 30 Jun 2020 at 22:25, Ronaldo Persiano rcmpersiano@gmail.com
wrote:
nop head nop.head@gmail.com wrote:
CGAL will handle exact differences fine as long as they are exact,
which the height is. F6 gives this.
Yes, but when they aren't exact some surprises come from render:
scale([1e6,1,1])
translate([-1,0,0])
difference(){
intersection(){
cube(1);
translate([1+1e-6,0,0]) cube(1);
}
translate([1,1,1]/2) cube(100);
}
Would you expect a non void object from this?
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
On Sat, Jul 04, 2020 at 12:33:45PM +0100, nop head wrote:
Interesting, a void object created by a difference works as expected. So it
seems to be a problem with intersection(). That is probably why I haven't
come across it before.
difference() {
difference() {
cube(1);
cube(2);
}
cube(10, center = true);
}
IIRC, difference is odd, in that it uses the first non-null item to
subtract from.
intersection() {
cube(1);
translate([2,0,0]) cube(1);
}
is null, so the second argument becomes the object to subtract from.
But
difference() {
cube(1);
cube(2);
}
contains a few slivers that make this "an object" (albeit with zero volume)
that can be subtracted from.
Hmm... I just tested my theory: It is not the slivers that make
the difference work.
I tried this:
difference() {
difference() {
cube(1,center=true);
cube(2,center=true);
}
cube(10, center = true);
}
so now the difference should return properly "nothing", not even a few
slivers, but still things work as expected (to some. :-) ) So
difference returns "an object with nothing in it" and intersection
returns "nothing"....
By the way, shouldn't the # make that cube visible?
Roger.
On Wed, 1 Jul 2020 at 08:50, nop head nop.head@gmail.com wrote:
The intersection produces a void so, yes, the difference should be void
and that is what I get with F6 that uses CGAL.
With F5 I get a big cube stretched by the scale. It appears that the void
object is simply ignored and the big cube becomes the first operand of
difference. If you add sphere(50) as a third operand it gets subtracted
from the big cube.
It still goes wrong with simple integers.
difference() {
intersection() {
cube(1);
translate([2,0,0]) cube(1);
}
cube(10, center = true);
}
I am using OpenSCAD 2020.04.26.ci4968, is this a regression? I think I
would have noticed such a simple bug.
On Tue, 30 Jun 2020 at 22:25, Ronaldo Persiano rcmpersiano@gmail.com
wrote:
nop head nop.head@gmail.com wrote:
CGAL will handle exact differences fine as long as they are exact, which
the height is. F6 gives this.
Yes, but when they aren't exact some surprises come from render:
scale([1e6,1,1])
translate([-1,0,0])
difference(){
intersection(){
cube(1);
translate([1+1e-6,0,0]) cube(1);
}
translate([1,1,1]/2) cube(100);
}
Would you expect a non void object from this?
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
--
** R.E.Wolff@BitWizard.nl ** https://www.BitWizard.nl/ ** +31-15-2049110 **
** Delftechpark 11 2628 XJ Delft, The Netherlands. KVK: 27239233 **
The plan was simple, like my brother-in-law Phil. But unlike
Phil, this plan just might work.
With F6 and CGAL I would expect the difference to return nothing but with
F5 and OpenCSG it doesn't evaluate geometry, it just makes pictures of it.
On Sat, 4 Jul 2020 at 14:26, Rogier Wolff R.E.Wolff@bitwizard.nl wrote:
On Sat, Jul 04, 2020 at 12:33:45PM +0100, nop head wrote:
Interesting, a void object created by a difference works as expected. So
it
seems to be a problem with intersection(). That is probably why I haven't
come across it before.
difference() {
difference() {
cube(1);
cube(2);
}
cube(10, center = true);
}
IIRC, difference is odd, in that it uses the first non-null item to
subtract from.
intersection() {
cube(1);
translate([2,0,0]) cube(1);
}
is null, so the second argument becomes the object to subtract from.
But
difference() {
cube(1);
cube(2);
}
contains a few slivers that make this "an object" (albeit with zero volume)
that can be subtracted from.
Hmm... I just tested my theory: It is not the slivers that make
the difference work.
I tried this:
difference() {
difference() {
cube(1,center=true);
cube(2,center=true);
}
cube(10, center = true);
}
so now the difference should return properly "nothing", not even a few
slivers, but still things work as expected (to some. :-) ) So
difference returns "an object with nothing in it" and intersection
returns "nothing"....
By the way, shouldn't the # make that cube visible?
Roger.
On Wed, 1 Jul 2020 at 08:50, nop head nop.head@gmail.com wrote:
The intersection produces a void so, yes, the difference should be void
and that is what I get with F6 that uses CGAL.
With F5 I get a big cube stretched by the scale. It appears that the
void
object is simply ignored and the big cube becomes the first operand of
difference. If you add sphere(50) as a third operand it gets subtracted
from the big cube.
It still goes wrong with simple integers.
difference() {
intersection() {
cube(1);
translate([2,0,0]) cube(1);
}
cube(10, center = true);
}
I am using OpenSCAD 2020.04.26.ci4968, is this a regression? I think I
would have noticed such a simple bug.
On Tue, 30 Jun 2020 at 22:25, Ronaldo Persiano rcmpersiano@gmail.com
wrote:
nop head nop.head@gmail.com wrote:
CGAL will handle exact differences fine as long as they are exact,
which
the height is. F6 gives this.
Yes, but when they aren't exact some surprises come from render:
scale([1e6,1,1])
translate([-1,0,0])
difference(){
intersection(){
cube(1);
translate([1+1e-6,0,0]) cube(1);
}
translate([1,1,1]/2) cube(100);
}
Would you expect a non void object from this?
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
--
** R.E.Wolff@BitWizard.nl ** https://www.BitWizard.nl/ ** +31-15-2049110
**
** Delftechpark 11 2628 XJ Delft, The Netherlands. KVK: 27239233 **
The plan was simple, like my brother-in-law Phil. But unlike
Phil, this plan just might work.
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
I think this is where it goes wrong:
https://github.com/openscad/openscad/blob/2010915177d3415931e8df290c0e7101d810f463/src/csgnode.cc#L83
Seems to prune the node when the intersection of the bounding boxes is
null. My guess is it should return an empty CSGLeaf instead of an empty
CSGNode but I haven't looked deep enough to know if that is the case.
On Sat, 4 Jul 2020 at 14:49, nop head nop.head@gmail.com wrote:
With F6 and CGAL I would expect the difference to return nothing but with
F5 and OpenCSG it doesn't evaluate geometry, it just makes pictures of it.
On Sat, 4 Jul 2020 at 14:26, Rogier Wolff R.E.Wolff@bitwizard.nl wrote:
On Sat, Jul 04, 2020 at 12:33:45PM +0100, nop head wrote:
Interesting, a void object created by a difference works as expected.
So it
seems to be a problem with intersection(). That is probably why I
haven't
come across it before.
difference() {
difference() {
cube(1);
cube(2);
}
cube(10, center = true);
}
IIRC, difference is odd, in that it uses the first non-null item to
subtract from.
intersection() {
cube(1);
translate([2,0,0]) cube(1);
}
is null, so the second argument becomes the object to subtract from.
But
difference() {
cube(1);
cube(2);
}
contains a few slivers that make this "an object" (albeit with zero
volume)
that can be subtracted from.
Hmm... I just tested my theory: It is not the slivers that make
the difference work.
I tried this:
difference() {
difference() {
cube(1,center=true);
cube(2,center=true);
}
cube(10, center = true);
}
so now the difference should return properly "nothing", not even a few
slivers, but still things work as expected (to some. :-) ) So
difference returns "an object with nothing in it" and intersection
returns "nothing"....
By the way, shouldn't the # make that cube visible?
Roger.
On Wed, 1 Jul 2020 at 08:50, nop head nop.head@gmail.com wrote:
The intersection produces a void so, yes, the difference should be
void
and that is what I get with F6 that uses CGAL.
With F5 I get a big cube stretched by the scale. It appears that the
void
object is simply ignored and the big cube becomes the first operand of
difference. If you add sphere(50) as a third operand it gets
subtracted
from the big cube.
It still goes wrong with simple integers.
difference() {
intersection() {
cube(1);
translate([2,0,0]) cube(1);
}
cube(10, center = true);
}
I am using OpenSCAD 2020.04.26.ci4968, is this a regression? I think I
would have noticed such a simple bug.
On Tue, 30 Jun 2020 at 22:25, Ronaldo Persiano <rcmpersiano@gmail.com
wrote:
nop head nop.head@gmail.com wrote:
CGAL will handle exact differences fine as long as they are exact,
which
the height is. F6 gives this.
Yes, but when they aren't exact some surprises come from render:
scale([1e6,1,1])
translate([-1,0,0])
difference(){
intersection(){
cube(1);
translate([1+1e-6,0,0]) cube(1);
}
translate([1,1,1]/2) cube(100);
}
Would you expect a non void object from this?
OpenSCAD mailing list
Discuss@lists.openscad.org
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
--
** R.E.Wolff@BitWizard.nl ** https://www.BitWizard.nl/ ** +31-15-2049110
**
** Delftechpark 11 2628 XJ Delft, The Netherlands. KVK: 27239233
**
The plan was simple, like my brother-in-law Phil. But unlike
Phil, this plan just might work.
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org