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 R.E.Wolff@bitwizard.nl wrote:

On 03/17/2016 09:13 AM, Rogier Wolff wrote:

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

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.

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 andrew@plumb.org wrote:

nophead wrote

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

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

--
View this message in context: http://forum.openscad.org/Touching-surfaces-tp16508p16515.html
Sent from the OpenSCAD mailing list archive at Nabble.com.

On Thu, Mar 17, 2016 at 01:31:47PM +0000, nop head 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. 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. 

--
** R.E.Wolff@BitWizard.nl ** 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.

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 R.E.Wolff@bitwizard.nl wrote:

On 2016-03-18 09:31, Rogier Wolff wrote:

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