I am modeling an object that consists of four parts, two of which are fairly complicated shapes. In the final view, I need to see all four parts at various degrees of separation. The two complicated parts are both differenced by a common "core" which creates internal space. When I view either one in it's own file, they are fine. When I view one of the two complicated parts in the assembly, it appears as if the "core" difference didn't happen. It's complicated, and I wouldn't want to have people trying to thread through it. Here's generally what I'm trying to do: First file: module PartA () { difference () { WholeA(); Core(); } } PartA(); Part A displays properly with Core cut out of it. Now comment out the invocation of part A and save the file. Next file: module PartB () { difference () { WholeB(); Core(); } } PartB(); Part B displays properly with Core cut out of it. Now comment out the invocation of part B and save the file. Whole assembly: include the files for part A and part B Z=2; module Project(){ union(){ translate ([0,0,(Z*1)]){ PartA(); } translate ([0,0,(Z*2)]){ PartB(); } } } Project(); Part A and Part B display. Part A displays correctly, and part B looks like the core didn't get subtracted. If I # the core, I see it in this view. I don't understand why part B is acting this way. Any ideas? -- K1FZY (WA4TPW) SK 9/29/37-4/13/15

If I # the core, I see it in this view. even if I only include part B. (as expected) On Tue, Aug 1, 2017 at 10:36 AM, david vanhorn <kc6ete@gmail.com> wrote: > > > I am modeling an object that consists of four parts, two of which are > fairly complicated shapes. > In the final view, I need to see all four parts at various degrees of > separation. > > The two complicated parts are both differenced by a common "core" which > creates internal space. > > When I view either one in it's own file, they are fine. > > When I view one of the two complicated parts in the assembly, it appears > as if the "core" > difference didn't happen. > > It's complicated, and I wouldn't want to have people trying to thread > through it. > Here's generally what I'm trying to do: > > > First file: > > module PartA () { > difference () { > WholeA(); > Core(); > } > } > > > PartA(); > > Part A displays properly with Core cut out of it. > Now comment out the invocation of part A and save the file. > > > > Next file: > > module PartB () { > difference () { > WholeB(); > Core(); > } > } > > PartB(); > > Part B displays properly with Core cut out of it. > Now comment out the invocation of part B and save the file. > > > Whole assembly: > include the files for part A and part B > > Z=2; > > > module Project(){ > union(){ > > translate ([0,0,(Z*1)]){ > PartA(); > } > > translate ([0,0,(Z*2)]){ > PartB(); > } > > > } > } > > Project(); > > Part A and Part B display. > Part A displays correctly, and part B looks like the core didn't get > subtracted. > If I # the core, I see it in this view. > > I don't understand why part B is acting this way. > > Any ideas? > > > > > > > -- > K1FZY (WA4TPW) SK 9/29/37-4/13/15 > -- K1FZY (WA4TPW) SK 9/29/37-4/13/15

In the union do the A & B parts overlap? If one has a solid section overlapping the hollow core of the other, I'm presuming the solid is unioned thus filling in the core. ?? ----- Admin - PM me if you need anything, or if I've done something stupid... Unless specifically shown otherwise above, my contribution is in the Public Domain; to the extent possible under law, I have waived all copyright and related or neighbouring rights to this work. Obviously inclusion of works of previous authors is not included in the above. The TPP is no simple “trade agreement.” Fight it! http://www.ourfairdeal.org/ time is running out! -- View this message in context: http://forum.openscad.org/Differencing-failing-tp21984p21987.html Sent from the OpenSCAD mailing list archive at Nabble.com.

BTW, as a generalisation it is always better to union positive objects, then difference the negatives. ----- Admin - PM me if you need anything, or if I've done something stupid... Unless specifically shown otherwise above, my contribution is in the Public Domain; to the extent possible under law, I have waived all copyright and related or neighbouring rights to this work. Obviously inclusion of works of previous authors is not included in the above. The TPP is no simple “trade agreement.” Fight it! http://www.ourfairdeal.org/ time is running out! -- View this message in context: http://forum.openscad.org/Differencing-failing-tp21984p21988.html Sent from the OpenSCAD mailing list archive at Nabble.com.

In the final file, I am simply positioning positive objects. In the construction files, I am taking the approach of unioning up all the constructive geometry and then differencing out the union(s) of the subtractive parts. The A and B parts don't overlap. They do come close, but that's part of the design. I don't know if the core part is somehow being brought in as part of the A and B objects and then in the construction file, it is overlapping itself and causing issues. Not even sure if that's possible. On Tue, Aug 1, 2017 at 6:44 PM, MichaelAtOz <oz.at.michael@gmail.com> wrote: > BTW, as a generalisation it is always better to union positive objects, > then > difference the negatives. > > > > ----- > Admin - PM me if you need anything, or if I've done something stupid... > > Unless specifically shown otherwise above, my contribution is in the > Public Domain; to the extent possible under law, I have waived all > copyright and related or neighbouring rights to this work. Obviously > inclusion of works of previous authors is not included in the above. > > The TPP is no simple “trade agreement.” Fight it! > http://www.ourfairdeal.org/ time is running out! > -- > View this message in context: http://forum.openscad.org/ > Differencing-failing-tp21984p21988.html > Sent from the OpenSCAD mailing list archive at Nabble.com. > > _______________________________________________ > OpenSCAD mailing list > Discuss@lists.openscad.org > http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org > -- K1FZY (WA4TPW) SK 9/29/37-4/13/15

It's hard to say without the source code but you could try putting render() in your PartA and PartB modules. On 2 August 2017 at 16:08, david vanhorn <kc6ete@gmail.com> wrote: > In the final file, I am simply positioning positive objects. > > In the construction files, I am taking the approach of unioning up all the > constructive geometry and then differencing out the union(s) of the > subtractive parts. > > The A and B parts don't overlap. They do come close, but that's part of > the design. I don't know if the core part is somehow being brought in as > part of the A and B objects and then in the construction file, it is > overlapping itself and causing issues. Not even sure if that's possible. > > > > > On Tue, Aug 1, 2017 at 6:44 PM, MichaelAtOz <oz.at.michael@gmail.com> > wrote: > >> BTW, as a generalisation it is always better to union positive objects, >> then >> difference the negatives. >> >> >> >> ----- >> Admin - PM me if you need anything, or if I've done something stupid... >> >> Unless specifically shown otherwise above, my contribution is in the >> Public Domain; to the extent possible under law, I have waived all >> copyright and related or neighbouring rights to this work. Obviously >> inclusion of works of previous authors is not included in the above. >> >> The TPP is no simple “trade agreement.” Fight it! >> http://www.ourfairdeal.org/ time is running out! >> -- >> View this message in context: http://forum.openscad.org/Diff >> erencing-failing-tp21984p21988.html >> Sent from the OpenSCAD mailing list archive at Nabble.com. >> >> _______________________________________________ >> OpenSCAD mailing list >> Discuss@lists.openscad.org >> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org >> > > > > -- > K1FZY (WA4TPW) SK 9/29/37-4/13/15 > > _______________________________________________ > OpenSCAD mailing list > Discuss@lists.openscad.org > http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org > >

I know. and it's a big project, some dozen files, and I don't want to inflict that on anyone. I'll try adding the render tonight and see what happens. If it persists, I'll try to boil it down to a simpler test case. I'm sure I'm doing something wrong, the sheer complexity makes that virtually certain. Can you clarify for me though, if I difference a cube from a sphere, and make that a module, when I use that module in another file, does the cube "exist" in the second file, or is the complex (sphere - cube) shape passed up? Part of my issue may lie in the fact that there are the four major parts, which I need working in their own files so they can be printed, and then I need to pull them into this "exploded assembly" file to look at how things are fitting together. I don't yet have an elegant way to say "if I'm running from this file, then invoke the object so I can see it and create STL file, but if I'm running from some other file then don't invoke the object" On Wed, Aug 2, 2017 at 9:38 AM, nop head <nop.head@gmail.com> wrote: > It's hard to say without the source code but you could try putting > render() in your PartA and PartB modules. > > On 2 August 2017 at 16:08, david vanhorn <kc6ete@gmail.com> wrote: > >> In the final file, I am simply positioning positive objects. >> >> In the construction files, I am taking the approach of unioning up all >> the constructive geometry and then differencing out the union(s) of the >> subtractive parts. >> >> The A and B parts don't overlap. They do come close, but that's part of >> the design. I don't know if the core part is somehow being brought in as >> part of the A and B objects and then in the construction file, it is >> overlapping itself and causing issues. Not even sure if that's possible. >> >> >> >> >> On Tue, Aug 1, 2017 at 6:44 PM, MichaelAtOz <oz.at.michael@gmail.com> >> wrote: >> >>> BTW, as a generalisation it is always better to union positive objects, >>> then >>> difference the negatives. >>> >>> >>> >>> ----- >>> Admin - PM me if you need anything, or if I've done something stupid... >>> >>> Unless specifically shown otherwise above, my contribution is in the >>> Public Domain; to the extent possible under law, I have waived all >>> copyright and related or neighbouring rights to this work. Obviously >>> inclusion of works of previous authors is not included in the above. >>> >>> The TPP is no simple “trade agreement.” Fight it! >>> http://www.ourfairdeal.org/ time is running out! >>> -- >>> View this message in context: http://forum.openscad.org/Diff >>> erencing-failing-tp21984p21988.html >>> Sent from the OpenSCAD mailing list archive at Nabble.com. >>> >>> _______________________________________________ >>> OpenSCAD mailing list >>> Discuss@lists.openscad.org >>> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org >>> >> >> >> >> -- >> K1FZY (WA4TPW) SK 9/29/37-4/13/15 >> >> _______________________________________________ >> 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 > > -- K1FZY (WA4TPW) SK 9/29/37-4/13/15

So I generated a simple test case, which isn't too painful. Of course it works just fine. Object C is subtracted from objects A and B, and then both A and B are used in file D to create an "assembly view" C.scad: module C () { cube (1,0); } //C(); // for working on the object itself. A.scad: include <c.scad> $fn=100; module A () { difference (){ sphere (r=1); C(); } } //A(); B.scad: include <c.scad> $fn=100; module B () { difference (){ sphere (r=1); C(); } } //B(); D.scad: include <A.scad>; include <B.scad>; expand = 3; // change this to "disassemble" the parts. $fn=100; module D () { union(){ translate ([0,0,expand*0]){ A(); } translate ([0,0,expand*1]){ B(); } } } D(); Of course this is trivial and does not need to be broken up like this but it's a far less painful version to illustrate what's happening. In my views the bottom sphere "A" would have no section cut out of it. The real objects and differencing objects are way more complicated, but constructed by first unioning everything, then differencing out the parts I don't want. On Wed, Aug 2, 2017 at 10:23 AM, david vanhorn <kc6ete@gmail.com> wrote: > I know. and it's a big project, some dozen files, and I don't want to > inflict that on anyone. > > I'll try adding the render tonight and see what happens. > > If it persists, I'll try to boil it down to a simpler test case. I'm sure > I'm doing something wrong, the sheer complexity makes that virtually > certain. > > Can you clarify for me though, if I difference a cube from a sphere, and > make that a module, when I use that module in another file, does the cube > "exist" in the second file, or is the complex (sphere - cube) shape passed > up? > > Part of my issue may lie in the fact that there are the four major parts, > which I need working in their own files so they can be printed, and then I > need to pull them into this "exploded assembly" file to look at how things > are fitting together. I don't yet have an elegant way to say "if I'm > running from this file, then invoke the object so I can see it and create > STL file, but if I'm running from some other file then don't invoke the > object" > > > > On Wed, Aug 2, 2017 at 9:38 AM, nop head <nop.head@gmail.com> wrote: > >> It's hard to say without the source code but you could try putting >> render() in your PartA and PartB modules. >> >> On 2 August 2017 at 16:08, david vanhorn <kc6ete@gmail.com> wrote: >> >>> In the final file, I am simply positioning positive objects. >>> >>> In the construction files, I am taking the approach of unioning up all >>> the constructive geometry and then differencing out the union(s) of the >>> subtractive parts. >>> >>> The A and B parts don't overlap. They do come close, but that's part of >>> the design. I don't know if the core part is somehow being brought in as >>> part of the A and B objects and then in the construction file, it is >>> overlapping itself and causing issues. Not even sure if that's possible. >>> >>> >>> >>> >>> On Tue, Aug 1, 2017 at 6:44 PM, MichaelAtOz <oz.at.michael@gmail.com> >>> wrote: >>> >>>> BTW, as a generalisation it is always better to union positive objects, >>>> then >>>> difference the negatives. >>>> >>>> >>>> >>>> ----- >>>> Admin - PM me if you need anything, or if I've done something stupid... >>>> >>>> Unless specifically shown otherwise above, my contribution is in the >>>> Public Domain; to the extent possible under law, I have waived all >>>> copyright and related or neighbouring rights to this work. Obviously >>>> inclusion of works of previous authors is not included in the above. >>>> >>>> The TPP is no simple “trade agreement.” Fight it! >>>> http://www.ourfairdeal.org/ time is running out! >>>> -- >>>> View this message in context: http://forum.openscad.org/Diff >>>> erencing-failing-tp21984p21988.html >>>> Sent from the OpenSCAD mailing list archive at Nabble.com. >>>> >>>> _______________________________________________ >>>> OpenSCAD mailing list >>>> Discuss@lists.openscad.org >>>> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org >>>> >>> >>> >>> >>> -- >>> K1FZY (WA4TPW) SK 9/29/37-4/13/15 >>> >>> _______________________________________________ >>> 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 >> >> > > > -- > K1FZY (WA4TPW) SK 9/29/37-4/13/15 > -- K1FZY (WA4TPW) SK 9/29/37-4/13/15

I should also say that the "C" object in the real parts is long, and would extend far enough in + an - Z to overlap with objects above and below. What's happening to me almost looks like the C object differencing B is somehow overlapping with itself in the A object, and canceling itself out... ??

> if I difference a cube from a sphere, and make that a module, when I use that module in another file, does the cube "exist" in the second file, or is the complex (sphere - cube) shape passed up? During an F5 preview all the primitive shapes (both positive and negative) are all drawn in various rendering modes. With render(), or F6 then the actual shape is calculated and passed up as a polyhedron. Does it look different if you zoom far out? During F6 all the primitive shapes, including the negative ones need to be inside the clipping volume or they don't get drawn. That can make a difference go wrong. I always render my top level objects, otherwise negative objects can interfere if they line up exactly. Normally it just causes Z fighting rather than making something disappear. On 2 August 2017 at 18:33, david vanhorn <kc6ete@gmail.com> wrote: > > I should also say that the "C" object in the real parts is long, and would > extend far enough in + an - Z to overlap with objects above and below. > > What's happening to me almost looks like the C object differencing B is > somehow overlapping with itself in the A object, and canceling itself > out... ?? > > _______________________________________________ > OpenSCAD mailing list > Discuss@lists.openscad.org > http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org > >