Differencing failing

classic Classic list List threaded Threaded
21 messages Options
12
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Differencing failing

dbvanhorn


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

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

Re: Differencing failing

dbvanhorn
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 <[hidden email]> 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

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

Re: Differencing failing

MichaelAtOz
Administrator
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!
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Differencing failing

MichaelAtOz
Administrator
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!
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Differencing failing

dbvanhorn
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 <[hidden email]> 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
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org



--
K1FZY (WA4TPW) SK  9/29/37-4/13/15

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

Re: Differencing failing

nophead
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 <[hidden email]> 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 <[hidden email]> 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
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org



--
K1FZY (WA4TPW) SK  9/29/37-4/13/15

_______________________________________________
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
|  
Report Content as Inappropriate

Re: Differencing failing

dbvanhorn
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org



--
K1FZY (WA4TPW) SK  9/29/37-4/13/15

_______________________________________________
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




--
K1FZY (WA4TPW) SK  9/29/37-4/13/15

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

Re: Differencing failing

dbvanhorn
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org



--
K1FZY (WA4TPW) SK  9/29/37-4/13/15

_______________________________________________
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




--
K1FZY (WA4TPW) SK  9/29/37-4/13/15



--
K1FZY (WA4TPW) SK  9/29/37-4/13/15

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

Re: Differencing failing

dbvanhorn
In reply to this post by dbvanhorn

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
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Differencing failing

nophead
> 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 <[hidden email]> 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
[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
|  
Report Content as Inappropriate

Re: Differencing failing

dbvanhorn

Ok, you might be on to something here.

I changed the differencing object "C" to this:

File C:

module C () {   
  translate ([0,0,-10]){
    cylinder (20,r=.5);
  }
}

//C();


In D, I added colors (not working right) and render, and when the colors are working, the hole in the bottom sphere is red and green.


File D:

include <A.scad>;
include <B.scad>;

expand = 2;

$fn=300;

module D () {
    union(){
            render (){color ([0,1,0]){ A();}}
        translate ([0,0,expand*1]){
            render (){color ([0,1,0]){ B();}}
        }
    }
}

D();






--
K1FZY (WA4TPW) SK  9/29/37-4/13/15

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

Re: Differencing failing

nophead
If you want the color()s to work put them before the render() instead of after.

On 2 August 2017 at 20:00, david vanhorn <[hidden email]> wrote:

Ok, you might be on to something here.

I changed the differencing object "C" to this:

File C:

module C () {   
  translate ([0,0,-10]){
    cylinder (20,r=.5);
  }
}

//C();


In D, I added colors (not working right) and render, and when the colors are working, the hole in the bottom sphere is red and green.


File D:

include <A.scad>;
include <B.scad>;

expand = 2;

$fn=300;

module D () {
    union(){
            render (){color ([0,1,0]){ A();}}
        translate ([0,0,expand*1]){
            render (){color ([0,1,0]){ B();}}
        }
    }
}

D();






--
K1FZY (WA4TPW) SK  9/29/37-4/13/15

_______________________________________________
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
|  
Report Content as Inappropriate

Re: Differencing failing

MichaelAtOz
Administrator
In reply to this post by dbvanhorn
> 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?

Have a look at the Design menu items, Display AST Tree & Display CSG Tree for whats what. And see code below.

> 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"

see code below for one way. You need more variables if you want it to work multi-level.

> Of course it works just fine.

When you reproduce it let us know, difficult to look at it ATM.
If you failed to comment out the C() call in C.scad (and save the file) that would cause what you describe.

A-B-C-D.zip



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!
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Differencing failing

nophead
To avoid having to comment out invocations use use <X.scad> instead of include <X.scad>. That allows access to modules but ignores instantiations.

On 3 August 2017 at 04:45, MichaelAtOz <[hidden email]> wrote:
> 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?

Have a look at the Design menu items, Display AST Tree & Display CSG Tree
for whats what. And see code below.

> 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"

see code below for one way. You need more variables if you want it to work
multi-level.

> Of course it works just fine.

When you reproduce it let us know, difficult to look at it ATM.
If you failed to comment out the C() call in C.scad (and save the file) that
would cause what you describe.

A-B-C-D.zip <http://forum.openscad.org/file/n22004/A-B-C-D.zip>







-----
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-tp21984p22004.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
|  
Report Content as Inappropriate

Re: Differencing failing

Gadgetmind
In reply to this post by nophead
On 2017-08-02 19:26, nop head wrote:
> 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've been bitten by this, but it seems to depend on version of OpenSCAD
and OpenCSG. The preview also works fine if orthogonal is selected.


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

Re: Differencing failing

Gadgetmind
In reply to this post by dbvanhorn
On 2017-08-02 18:29, david vanhorn wrote:
> So I generated a simple test case, which isn't too painful.  Of course
> it works just fine.

I have an issue where objects that have common negative space subtracted
from them don't get their individual colours. I'd love to report it but
every simple test I create works just fine!


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

Re: Differencing failing

dbvanhorn
Ok, I'm working back through my files, converting everything I can to "use" rather than "include" and resolving any issues.

I'm also renaming the files to indicate their level in the tree.

I'm working on a file now which uses files that use other files.
I started a preview, and I get "WARNING Nomalized tree is growing past 200000 elements Aborting normalization"
and Normalized CSG tree has 18800 elements (somewhat less than 200000...)

How do I resolve this?  My most complicated object is the torus,

module Torus(Major,Minor){   
    rotate_extrude(angle = 45, convexity = 144){
        translate([Major, 0, 0]){
            circle(r = Minor, $fn = 144);
        }// end of translate
    }// end rotate extrude
}// end of module

This is used in a number of places. 

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

Re: Differencing failing

nophead
convexity = 144 seems like a huge number and for a toroid it should be only need to be 2.

I don't know if that creates more csg tree elements but I can't think what else does.

On 3 August 2017 at 20:41, david vanhorn <[hidden email]> wrote:
Ok, I'm working back through my files, converting everything I can to "use" rather than "include" and resolving any issues.

I'm also renaming the files to indicate their level in the tree.

I'm working on a file now which uses files that use other files.
I started a preview, and I get "WARNING Nomalized tree is growing past 200000 elements Aborting normalization"
and Normalized CSG tree has 18800 elements (somewhat less than 200000...)

How do I resolve this?  My most complicated object is the torus,

module Torus(Major,Minor){   
    rotate_extrude(angle = 45, convexity = 144){
        translate([Major, 0, 0]){
            circle(r = Minor, $fn = 144);
        }// end of translate
    }// end rotate extrude
}// end of module

This is used in a number of places. 

_______________________________________________
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
|  
Report Content as Inappropriate

Re: Differencing failing

dbvanhorn
Ok, I'll dial that back and see what happens.

On Thu, Aug 3, 2017 at 2:40 PM, nop head <[hidden email]> wrote:
convexity = 144 seems like a huge number and for a toroid it should be only need to be 2.

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

Re: Differencing failing

dbvanhorn

Ok, dialing back the convexity got it.  I found that as an example somewhere. It was working so I didn't mess with it.

I have rebuilt all my files to "use" rather than "Include" but I'm having one issue.
I have a variable called CrossSection which is either true or undefined.
If undefined the modules are supposed to be complete, and if true they are supposed to difference with a large cube to create a cross section view.
Apparently the value of CrossSection isn't being passed down to the modules. I can clip it in the main view, but then all the faces are green, and there is a bunch of artifacting where parts of the model that were differenced out are allowing me to see through the model.



--
K1FZY (WA4TPW) SK  9/29/37-4/13/15

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
12
Loading...