Touching surfaces.

classic Classic list List threaded Threaded
13 messages Options
rew
Reply | Threaded
Open this post in threaded view
|

Touching surfaces.

rew

Hi,

Yesterday we wasted some acrylic again...

I had made a design in openscad, allowing for an assembled version and
a "flat" version for lasering. We had made one prototype, but decided
to increase one dimension by 1.6mm for the second prototype.

The assembled version looked good, change parameter to create the flat
version, compile, export, import, print, laser!

Turns out that the 3D version looked good, while the flat version had
some protuding pieces missing. This was caused by those pieces aligning
exactly with the plane of the main piece.

//---------------------------------------
module test ()
{
  cube ([60,40, 3]);
  translate ([10,40,0]) cube ([10,3,3]);
  translate ([40,40,0]) cube ([10,3,3]);
}

// comment out the next line for the 3D model.
projection (cut=true) translate ([0,0,-1.5])
test();
//---------------------------------------


Currently on my computer this now renders/projects/compiles just fine.
And that's what happened when we made the first prototype last week,
and changing something unrelated (that would be the height of 40 in
this example) suddenly the protrusions disappeared in the projected
version....

Would it be possible to have openscad help prevent this kind of error?
e.g. by warning me that there are two object that are touching?

        Roger.

--
** [hidden email] ** http://www.BitWizard.nl/ ** +31-15-2600998 **
**    Delftechpark 26 2628 XH  Delft, The Netherlands. KVK: 27239233    **
*-- BitWizard writes Linux device drivers for any device you may have! --*
The plan was simple, like my brother-in-law Phil. But unlike
Phil, this plan just might work.

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

Re: Touching surfaces.

nophead
Hard to grasp what your original problem was as the example works fine as you stated.

If two parts exactly touch then they will union correctly, so it isn't an error. If they don't quite touch due to floating point inaccuracy then there will be a gap. Again that isn't an error as they are not touching, so it would be hard to give a warning.

In either case they don't disappear. They are either attached or separate. What might make them disappear is doing the projection through a plane that coincides exactly with the top or the bottom.

On 17 March 2016 at 13:13, Rogier Wolff <[hidden email]> wrote:

Hi,

Yesterday we wasted some acrylic again...

I had made a design in openscad, allowing for an assembled version and
a "flat" version for lasering. We had made one prototype, but decided
to increase one dimension by 1.6mm for the second prototype.

The assembled version looked good, change parameter to create the flat
version, compile, export, import, print, laser!

Turns out that the 3D version looked good, while the flat version had
some protuding pieces missing. This was caused by those pieces aligning
exactly with the plane of the main piece.

//---------------------------------------
module test ()
{
  cube ([60,40, 3]);
  translate ([10,40,0]) cube ([10,3,3]);
  translate ([40,40,0]) cube ([10,3,3]);
}

// comment out the next line for the 3D model.
projection (cut=true) translate ([0,0,-1.5])
test();
//---------------------------------------


Currently on my computer this now renders/projects/compiles just fine.
And that's what happened when we made the first prototype last week,
and changing something unrelated (that would be the height of 40 in
this example) suddenly the protrusions disappeared in the projected
version....

Would it be possible to have openscad help prevent this kind of error?
e.g. by warning me that there are two object that are touching?

        Roger.

--
** [hidden email] ** http://www.BitWizard.nl/ ** <a href="tel:%2B31-15-2600998" value="+31152600998">+31-15-2600998 **
**    Delftechpark 26 2628 XH  Delft, The Netherlands. KVK: 27239233    **
*-- BitWizard writes Linux device drivers for any device you may have! --*
The plan was simple, like my brother-in-law Phil. But unlike
Phil, this plan just might work.

_______________________________________________
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: Touching surfaces.

ednisley
In reply to this post by rew
On 03/17/2016 09:13 AM, Rogier Wolff wrote:
> possible to have openscad help prevent this kind of error?

Because OpenSCAD doesn't know your /intent/, it really can't tell
whether you meant to do something or made a mistake.

I generally define constants for all the key physical measurements, then
compute the cube() and translate() parameters from those constants, with
explicit provision for the required overlaps:

-----------
Protrusion = 0.1; // overlap to ensure no coincident faces

Body = [60,40,3];
Tab = [10,3,3];
TabOC = 30; // distance between tab centers

module test() {
  cube(Body,center=true);
  for (i=[-1,1])
   translate([i*TabOC/2,(Body[1] + Tab[1] - Protrusion)/2,0])
    cube(Tab + [0,Protrusion,0],center=true);
}

projection (cut=true)
test();
-----------

nophead uses fancier techniques to accomplish that sort of thing, but
the straightforward method suffices for my needs.

Defining all those relations forces me to work out the actual model
geometry, rather than bashing numbers until the shape looks right. The
payoff comes when I change one measurement and have /all/ the other
parts rearrange themselves accordingly; that happens a lot for the
build-to-fit repair parts I make.

For simple 2(-1/2)D shapes, however, I usually linear_extrude a polygon
and skip all the 3D stuff.

--
Ed
softsolder.com

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

Re: Touching surfaces.

clothbot
Riffing on what nophead and Ed have replied, here's my approach.  I create a 'volume_slice()' module that intersect-masks a "thin enough" volume with the object and does a projection(cut=false) to get the 2D shadow-outline of the slice:

--snip--
//--------------------------------------- 
module test () 
{ 
  cube ([60,40, 3]); 
  translate ([10,40,0]) cube ([10,3,3]); 
  translate ([40,40,0]) cube ([10,3,3]); 
} 

module volume_slice(delta=0.1,lowerLeft=[-1,-1],upperRight=[100,100],z=0.0) {
    projection(cut=false) intersection() {
        #translate([lowerLeft[0],lowerLeft[1],z-delta/2])
            cube([upperRight[0]-lowerLeft[0],upperRight[1]-lowerLeft[1],delta],center=false);
        union() children();
    }
}

// comment out the next line for the 3D model. 
volume_slice(z=1.5)
test(); 
//--------------------------------------- 
--end-snip--

Andrew.
Reply | Threaded
Open this post in threaded view
|

Re: Touching surfaces.

clothbot
Well that's rather annoying.  I'm not seeing my code on the mailing list
side; tried to get smart with the formatting markup.

--snip--

//---------------------------------------
module test ()
{
  cube ([60,40, 3]);
  translate ([10,40,0]) cube ([10,3,3]);
  translate ([40,40,0]) cube ([10,3,3]);
}

module volume_slice(delta=0.1,lowerLeft=[-1,-1],upperRight=[100,100],z=0.0) {
    projection(cut=false) intersection() {
        #translate([lowerLeft[0],lowerLeft[1],z-delta/2])
            cube([upperRight[0]-lowerLeft[0],upperRight[1]-lowerLeft[1],delta],center=false);
        union() children();
    }
}

// comment out the next line for the 3D model.
volume_slice(z=1.5)
test();
//---------------------------------------

--end-snip--

Hopefully that shows up...

Andrew.

> Riffing on what nophead and Ed have replied, here's my approach.  I create
> a
> 'volume_slice()' module that intersect-masks a "thin enough" volume with
> the
> object and does a projection(cut=false) to get the 2D shadow-outline of
> the
> slice:
>
> --snip--
>
> --end-snip--
>
> Andrew.
>
>
>
> --
> View this message in context:
> http://forum.openscad.org/Touching-surfaces-tp16508p16512.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: Touching surfaces.

nophead
Yes the forum incompatibility with the mailing list is a nightmare. Your message from the forum is from clothbot but the mailing list one is Andrew Plumb, both with the same email address. One ends up having to remember two names for everybody.

Why do you intersect with a plane and then do projection(cut=false) instead of just projection(cut = true). Are you saying it is more robust using a finite slice?

On 17 March 2016 at 15:00, Andrew Plumb <[hidden email]> wrote:
Well that's rather annoying.  I'm not seeing my code on the mailing list
side; tried to get smart with the formatting markup.

--snip--

//---------------------------------------
module test ()
{
  cube ([60,40, 3]);
  translate ([10,40,0]) cube ([10,3,3]);
  translate ([40,40,0]) cube ([10,3,3]);
}

module volume_slice(delta=0.1,lowerLeft=[-1,-1],upperRight=[100,100],z=0.0) {
    projection(cut=false) intersection() {
        #translate([lowerLeft[0],lowerLeft[1],z-delta/2])
            cube([upperRight[0]-lowerLeft[0],upperRight[1]-lowerLeft[1],delta],center=false);
        union() children();
    }
}

// comment out the next line for the 3D model.
volume_slice(z=1.5)
test();
//---------------------------------------

--end-snip--

Hopefully that shows up...

Andrew.

> Riffing on what nophead and Ed have replied, here's my approach.  I create
> a
> 'volume_slice()' module that intersect-masks a "thin enough" volume with
> the
> object and does a projection(cut=false) to get the 2D shadow-outline of
> the
> slice:
>
> --snip--
>
> --end-snip--
>
> Andrew.
>
>
>
> --
> View this message in context:
> http://forum.openscad.org/Touching-surfaces-tp16508p16512.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: Touching surfaces.

clothbot
nophead wrote
Yes the forum incompatibility with the mailing list is a nightmare. Your
message from the forum is from clothbot but the mailing list one is Andrew
Plumb, both with the same email address. One ends up having to remember two
names for everybody.
Yeah, I just let e-mail clients figure out the mapping. ;-) When I'm at work I usually use the forum interface so it uses my 'clothbot' username; when I'm at home I'm using my regular 'Mail.app' which has my proper signature with all the 'clothbot' references.

nophead wrote
Why do you intersect with a plane and then do projection(cut=false) instead
of just projection(cut = true). Are you saying it is more robust using a
finite slice?
I use it as a sort of 'volumetric quantization' or grid-snap operation.  The size of 'delta' gives you a z-axis range in which geometry should be considered valid and takes care of floating-point imprecision.

Andrew (aka clothbot :-)
rew
Reply | Threaded
Open this post in threaded view
|

Re: Touching surfaces.

rew
In reply to this post by nophead
On Thu, Mar 17, 2016 at 01:31:47PM +0000, nop head wrote:

> Hard to grasp what your original problem was as the example works fine as
> you stated.
>
> If two parts exactly touch then they will union correctly, so it isn't an
> error. If they don't quite touch due to floating point inaccuracy then
> there will be a gap. Again that isn't an error as they are not touching, so
> it would be hard to give a warning.
>
> In either case they don't disappear. They are either attached or separate.
> What might make them disappear is doing the projection through a plane that
> coincides exactly with the top or the bottom.

I KNOW I can "fix" it by overlapping the objects.

The problem is: occasionally you forget to preventively fix it, and
you place an object exactly where it is supposed to go.

The render looks fine, you laser or 3D print it, and... wasted time
and material. I understand that according to openscad if rounding
errors cause two surfaces to not-touch, then there are simply two
objects. That is actually the easiest case as mathematically there is
no problem.

In my case however there WAS an error, I think caused by the planes
being EXACTLY in the same spot. In the 3D view the protrusions
actually showed. "correctly unioned" as you say. Then the "projection
(cut=true)" caused the whole protrusion to disappear. If there was a
gap, it would have ruined my laser-job too: the protrusion would have
been cut loose from the main object. But there was no gap, the
protrusion disappeared.

Anyway, I understand that if there is a minimal gap, that would make
an entirely valid object and there is nothing that openscad can do to
FIX it automatically. However, it can warn me about a construct that I
didn't intend.

I would want to set an epsilon, that two planes in exactly the same
spot or only less than epsilon apart would get flagged as a warning.

I can imagine that this operation to find these places is "expensive"
so maybe I would have to hit a "check double faces" button. Then I'd
get to hit myself when I mess up again because I forgot to do that
before exporting.

I agree that from openscad's viewpoint "there is no error" is a valid
point-of-view. On the other hand, a tool should help me make what I
actually want.

Suppose I have an oven where I need to set the temperature with a knob
but the digits are reversed. So to set it to 190 degrees you need to
turn the knob to 091. So when I find my cake burnt to a crisp, I
notice the knob is now set to 092, or 290 degrees. Technically I
specified "burn my cake at 290 degrees" and the oven was correct to
comply. But it is not what I wanted.

        Roger.



>
> On 17 March 2016 at 13:13, Rogier Wolff <[hidden email]> wrote:
>
> >
> > Hi,
> >
> > Yesterday we wasted some acrylic again...
> >
> > I had made a design in openscad, allowing for an assembled version and
> > a "flat" version for lasering. We had made one prototype, but decided
> > to increase one dimension by 1.6mm for the second prototype.
> >
> > The assembled version looked good, change parameter to create the flat
> > version, compile, export, import, print, laser!
> >
> > Turns out that the 3D version looked good, while the flat version had
> > some protuding pieces missing. This was caused by those pieces aligning
> > exactly with the plane of the main piece.
> >
> > //---------------------------------------
> > module test ()
> > {
> >   cube ([60,40, 3]);
> >   translate ([10,40,0]) cube ([10,3,3]);
> >   translate ([40,40,0]) cube ([10,3,3]);
> > }
> >
> > // comment out the next line for the 3D model.
> > projection (cut=true) translate ([0,0,-1.5])
> > test();
> > //---------------------------------------
> >
> >
> > Currently on my computer this now renders/projects/compiles just fine.
> > And that's what happened when we made the first prototype last week,
> > and changing something unrelated (that would be the height of 40 in
> > this example) suddenly the protrusions disappeared in the projected
> > version....
> >
> > Would it be possible to have openscad help prevent this kind of error?
> > e.g. by warning me that there are two object that are touching?
> >
> >         Roger.
> >
> > --
> > ** [hidden email] ** http://www.BitWizard.nl/ ** +31-15-2600998 **
> > **    Delftechpark 26 2628 XH  Delft, The Netherlands. KVK: 27239233    **
> > *-- BitWizard writes Linux device drivers for any device you may have! --*
> > The plan was simple, like my brother-in-law Phil. But unlike
> > Phil, this plan just might work.
> >
> > _______________________________________________
> > 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


--
** [hidden email] ** http://www.BitWizard.nl/ ** +31-15-2600998 **
**    Delftechpark 26 2628 XH  Delft, The Netherlands. KVK: 27239233    **
*-- BitWizard writes Linux device drivers for any device you may have! --*
The plan was simple, like my brother-in-law Phil. But unlike
Phil, this plan just might work.

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

Re: Touching surfaces.

nophead
Unless you produce an example that fails it is hard to say why. As I said before exactly touching is not an error and unions correctly. Why would we want OpenScad to produce a warning? Having a small gap produces two objects and that is also not an error as somebody might want that. Both are clear when you do F6 because of the red perimeter. It is also clear in the F6 3D view if you turn on show edges.

If the tabs disappeared completely something else happened, like the cut plane was not though the tabs or there is a bug in OpenScad.

On 18 March 2016 at 08:31, Rogier Wolff <[hidden email]> wrote:
On Thu, Mar 17, 2016 at 01:31:47PM +0000, nop head wrote:
> Hard to grasp what your original problem was as the example works fine as
> you stated.
>
> If two parts exactly touch then they will union correctly, so it isn't an
> error. If they don't quite touch due to floating point inaccuracy then
> there will be a gap. Again that isn't an error as they are not touching, so
> it would be hard to give a warning.
>
> In either case they don't disappear. They are either attached or separate.
> What might make them disappear is doing the projection through a plane that
> coincides exactly with the top or the bottom.

I KNOW I can "fix" it by overlapping the objects.

The problem is: occasionally you forget to preventively fix it, and
you place an object exactly where it is supposed to go.

The render looks fine, you laser or 3D print it, and... wasted time
and material. I understand that according to openscad if rounding
errors cause two surfaces to not-touch, then there are simply two
objects. That is actually the easiest case as mathematically there is
no problem.

In my case however there WAS an error, I think caused by the planes
being EXACTLY in the same spot. In the 3D view the protrusions
actually showed. "correctly unioned" as you say. Then the "projection
(cut=true)" caused the whole protrusion to disappear. If there was a
gap, it would have ruined my laser-job too: the protrusion would have
been cut loose from the main object. But there was no gap, the
protrusion disappeared.

Anyway, I understand that if there is a minimal gap, that would make
an entirely valid object and there is nothing that openscad can do to
FIX it automatically. However, it can warn me about a construct that I
didn't intend.

I would want to set an epsilon, that two planes in exactly the same
spot or only less than epsilon apart would get flagged as a warning.

I can imagine that this operation to find these places is "expensive"
so maybe I would have to hit a "check double faces" button. Then I'd
get to hit myself when I mess up again because I forgot to do that
before exporting.

I agree that from openscad's viewpoint "there is no error" is a valid
point-of-view. On the other hand, a tool should help me make what I
actually want.

Suppose I have an oven where I need to set the temperature with a knob
but the digits are reversed. So to set it to 190 degrees you need to
turn the knob to 091. So when I find my cake burnt to a crisp, I
notice the knob is now set to 092, or 290 degrees. Technically I
specified "burn my cake at 290 degrees" and the oven was correct to
comply. But it is not what I wanted.

        Roger.



>
> On 17 March 2016 at 13:13, Rogier Wolff <[hidden email]> wrote:
>
> >
> > Hi,
> >
> > Yesterday we wasted some acrylic again...
> >
> > I had made a design in openscad, allowing for an assembled version and
> > a "flat" version for lasering. We had made one prototype, but decided
> > to increase one dimension by 1.6mm for the second prototype.
> >
> > The assembled version looked good, change parameter to create the flat
> > version, compile, export, import, print, laser!
> >
> > Turns out that the 3D version looked good, while the flat version had
> > some protuding pieces missing. This was caused by those pieces aligning
> > exactly with the plane of the main piece.
> >
> > //---------------------------------------
> > module test ()
> > {
> >   cube ([60,40, 3]);
> >   translate ([10,40,0]) cube ([10,3,3]);
> >   translate ([40,40,0]) cube ([10,3,3]);
> > }
> >
> > // comment out the next line for the 3D model.
> > projection (cut=true) translate ([0,0,-1.5])
> > test();
> > //---------------------------------------
> >
> >
> > Currently on my computer this now renders/projects/compiles just fine.
> > And that's what happened when we made the first prototype last week,
> > and changing something unrelated (that would be the height of 40 in
> > this example) suddenly the protrusions disappeared in the projected
> > version....
> >
> > Would it be possible to have openscad help prevent this kind of error?
> > e.g. by warning me that there are two object that are touching?
> >
> >         Roger.
> >
> > --
> > ** [hidden email] ** http://www.BitWizard.nl/ ** <a href="tel:%2B31-15-2600998" value="+31152600998">+31-15-2600998 **
> > **    Delftechpark 26 2628 XH  Delft, The Netherlands. KVK: 27239233    **
> > *-- BitWizard writes Linux device drivers for any device you may have! --*
> > The plan was simple, like my brother-in-law Phil. But unlike
> > Phil, this plan just might work.
> >
> > _______________________________________________
> > 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


--
** [hidden email] ** http://www.BitWizard.nl/ ** <a href="tel:%2B31-15-2600998" value="+31152600998">+31-15-2600998 **
**    Delftechpark 26 2628 XH  Delft, The Netherlands. KVK: 27239233    **
*-- BitWizard writes Linux device drivers for any device you may have! --*
The plan was simple, like my brother-in-law Phil. But unlike
Phil, this plan just might work.

_______________________________________________
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: Touching surfaces.

cacb
In reply to this post by rew
On 2016-03-18 09:31, Rogier Wolff wrote:

> I KNOW I can "fix" it by overlapping the objects.
>
> The problem is: occasionally you forget to preventively fix it, and
> you place an object exactly where it is supposed to go.
>
> The render looks fine, you laser or 3D print it, and... wasted time
> and material. I understand that according to openscad if rounding
> errors cause two surfaces to not-touch, then there are simply two
> objects. That is actually the easiest case as mathematically there is
> no problem.
>
> In my case however there WAS an error, I think caused by the planes
> being EXACTLY in the same spot.

The software cannot know your expectations, it can only know what your
instructions were. If the two objects happen to intersect based on your
instructions, they become thing as far as the software is concerned. If
not, they are two. You can only call the result an error after comparing
with your unstated expectations, the software has no way of knowing
these expectations (after all it isn't psychic).

I think the best you can hope for is that the software reports back how
many "lumps" (=independent bodies) the resulting object consists of
after boolean operations. If you have two objects you believe should be
unioned into one, and the software reports the result is consisting of
two lumps, then you have a chance of comparing the result with your
expectations. This is exactly what I have been doing when experimenting
with carve (another boolean engine).

So a suggestion could be that openscad reports the number of lumps in
the result.

Carsten Arnholm


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

Re: Touching surfaces.

nophead
OpenScad currently reports volumes for 3D which is lumps plus one and contours for 2D. However missing tabs that should be unioned would not change the number of lumps. Detached tabs would but that is not actually the original problem.

On 18 March 2016 at 09:53, <[hidden email]> wrote:
On 2016-03-18 09:31, Rogier Wolff wrote:
I KNOW I can "fix" it by overlapping the objects.

The problem is: occasionally you forget to preventively fix it, and
you place an object exactly where it is supposed to go.

The render looks fine, you laser or 3D print it, and... wasted time
and material. I understand that according to openscad if rounding
errors cause two surfaces to not-touch, then there are simply two
objects. That is actually the easiest case as mathematically there is
no problem.

In my case however there WAS an error, I think caused by the planes
being EXACTLY in the same spot.

The software cannot know your expectations, it can only know what your instructions were. If the two objects happen to intersect based on your instructions, they become thing as far as the software is concerned. If not, they are two. You can only call the result an error after comparing with your unstated expectations, the software has no way of knowing these expectations (after all it isn't psychic).

I think the best you can hope for is that the software reports back how many "lumps" (=independent bodies) the resulting object consists of after boolean operations. If you have two objects you believe should be unioned into one, and the software reports the result is consisting of two lumps, then you have a chance of comparing the result with your expectations. This is exactly what I have been doing when experimenting with carve (another boolean engine).

So a suggestion could be that openscad reports the number of lumps in the result.

Carsten Arnholm


_______________________________________________
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: Touching surfaces.

G. Wade Johnson
Sorry for butting in here. I was also taking the OP's comment as a
misunderstanding of the tool. But, in the explanation was a little
kernel that might be worth some thought as an enhancement.

When we want to force a union (and not deal with rounding errors
causing gaps), we always explain how to make one object a little larger
and union.

The OP suggested that if OpenSCAD could recognize the case where two
objects are within some epsilon and warn would be a good thing. That
made me think of other similar values that we already have: $fn, $fa,
and $fs.

What if we had a $epsilon, and OpenSCAD could use it to either warn of
objects that are within that distance or automatically union? Would
that help new users? I'm not sure how much effort it would be (since I
haven't look at the code in a long time), but maybe it's worth some
thought.

(The current behavior would remain if $epsilon is 0. For many cases,
problems would go away with $epsilon = 0.01. The designer could tweak
this value to allow items to be closer or force them to stay further
away.)

At the moment, I don't think this should be considered a proposal. Just
the beginnings of a thought experiment.

G. Wade

On Fri, 18 Mar 2016 10:05:50 +0000
nop head <[hidden email]> wrote:

> OpenScad currently reports volumes for 3D which is lumps plus one and
> contours for 2D. However missing tabs that should be unioned would not
> change the number of lumps. Detached tabs would but that is not
> actually the original problem.
>
> On 18 March 2016 at 09:53, <[hidden email]> wrote:
>
> > On 2016-03-18 09:31, Rogier Wolff wrote:
> >
> >> I KNOW I can "fix" it by overlapping the objects.
> >>
> >> The problem is: occasionally you forget to preventively fix it, and
> >> you place an object exactly where it is supposed to go.
> >>
> >> The render looks fine, you laser or 3D print it, and... wasted time
> >> and material. I understand that according to openscad if rounding
> >> errors cause two surfaces to not-touch, then there are simply two
> >> objects. That is actually the easiest case as mathematically there
> >> is no problem.
> >>
> >> In my case however there WAS an error, I think caused by the planes
> >> being EXACTLY in the same spot.
> >>
> >
> > The software cannot know your expectations, it can only know what
> > your instructions were. If the two objects happen to intersect
> > based on your instructions, they become thing as far as the
> > software is concerned. If not, they are two. You can only call the
> > result an error after comparing with your unstated expectations,
> > the software has no way of knowing these expectations (after all it
> > isn't psychic).
> >
> > I think the best you can hope for is that the software reports back
> > how many "lumps" (=independent bodies) the resulting object
> > consists of after boolean operations. If you have two objects you
> > believe should be unioned into one, and the software reports the
> > result is consisting of two lumps, then you have a chance of
> > comparing the result with your expectations. This is exactly what I
> > have been doing when experimenting with carve (another boolean
> > engine).
> >
> > So a suggestion could be that openscad reports the number of lumps
> > in the result.
> >
> > Carsten Arnholm
> >
> >
> > _______________________________________________
> > OpenSCAD mailing list
> > [hidden email]
> > http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
> >


--
If it doesn't have to be right, I can make it arbitrarily fast.
                                                    -- Rick Hoselton

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

Re: Touching surfaces.

macdarren
I would second this or something like this as a feature request.

I am a relatively new openSCAD user.
I make mostly mechanical pieces, and really like the programatic / parametric way of designing my parts
over traditional visual tools.  However the need to constantly fudge things just a bit is for me burdensome.  I have exact measurements (generated mathematically) but these can change and having to add in some delta to be certain that parts join to form a solid can get a bit tricky and seeing interior surface separations/flaws can be a challenge.

I like the idea of one or two epsilon type values.... that add some function but when set to 0 result in everything working just as it does now.

I would suggest maybe two values that if zero do nothing.
(for discussion called $op - overlapping plane and $sp - separating plane)
(these would typically be very small numbers like .001 or whatever is needed to cover up rounding)
(.001 seems to work most of the time for me, though in practice .01 is usually fine too)

$op positive will force the merging of objects separated by less than that value.
$sp positive would force separation of objects that due to rounding may touch or be separated by less than this amount.
(I need to think about $sp a bit, I feel like there is a similar need when differencing objects, where $op addresses unions how this other differencing/separating property would work I need to consider.)

Perhaps negative numbers would report as a warning but not actually make any change.

How to do this separation or merging might be a bit of a challenge but using some method similar to
what we do manually by adding or subtracting some small amount to allow for rounding errors to be masked
seems like good starting point.