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, <arnholm@arnholm.org> 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 > Discuss@lists.openscad.org > http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org >

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 <nop.head@gmail.com> 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, <arnholm@arnholm.org> 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 > > Discuss@lists.openscad.org > > 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

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. -- View this message in context: http://forum.openscad.org/Touching-surfaces-tp16508p16574.html Sent from the OpenSCAD mailing list archive at Nabble.com.