math bug (feature?)

classic Classic list List threaded Threaded
47 messages Options
123
Reply | Threaded
Open this post in threaded view
|

math bug (feature?)

Jesse Guardiani
Often, when I'm punching holes in things, I notice a thin film over a hole, where there should be nothing. My quick hack fix is to just add 0.001 /* math fix */ to the height of the cylinder, and the hole goes all the way through as it should.

These aren't measurement errors. They're computation errors.

Is this caused by rounding errors? What's the recommended workaround?

--
Jesse
CreateThis.com

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566
Reply | Threaded
Open this post in threaded view
|

Re: math bug (feature?)

kintel
Administrator
On 2013-06-22, at 23:36 , Jesse Guardiani wrote:
>
> Is this caused by rounding errors? What's the recommended workaround?
>
These only appear in the preview view. We don't actually compute geometry there, we just send it to OpenGL and use OpenGL's built-in depth buffer (with a few tricks) to rendering something visually resembling what you've designed. This depth buffer has a very limited precision and you thus get "z buffer fighting" when rendering coincident positive and negative surfaces. It might be possible for the underlying library (OpenCSG) to fix this. Until then, make sure that your negative volumes overshoot a bit. I usually overshoot by a good margin (like 25% of the total length or so) as that helps debugging when highlighting individual objects.

 -Marius

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566
Reply | Threaded
Open this post in threaded view
|

Re: math bug (feature?)

Jesse Guardiani
Thanks Marius,

That makes sense. Good to know too.

--
Jesse



On Sat, Jun 22, 2013 at 11:47 PM, Marius Kintel <[hidden email]> wrote:
On 2013-06-22, at 23:36 , Jesse Guardiani wrote:
>
> Is this caused by rounding errors? What's the recommended workaround?
>
These only appear in the preview view. We don't actually compute geometry there, we just send it to OpenGL and use OpenGL's built-in depth buffer (with a few tricks) to rendering something visually resembling what you've designed. This depth buffer has a very limited precision and you thus get "z buffer fighting" when rendering coincident positive and negative surfaces. It might be possible for the underlying library (OpenCSG) to fix this. Until then, make sure that your negative volumes overshoot a bit. I usually overshoot by a good margin (like 25% of the total length or so) as that helps debugging when highlighting individual objects.

 -Marius

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566
Reply | Threaded
Open this post in threaded view
|

Re: math bug (feature?)

devlaam
In reply to this post by kintel
Actually, i see this more as a feature because you
can quickly view if two objects end at the same
place. From the code this can be hard, since
mine is all parametrized.


On 23-06-13 05:47, Marius Kintel wrote:

> On 2013-06-22, at 23:36 , Jesse Guardiani wrote:
>>
>> Is this caused by rounding errors? What's the recommended workaround?
>>
> These only appear in the preview view. We don't actually compute geometry there, we just send it to OpenGL and use OpenGL's built-in depth buffer (with a few tricks) to rendering something visually resembling what you've designed. This depth buffer has a very limited precision and you thus get "z buffer fighting" when rendering coincident positive and negative surfaces. It might be possible for the underlying library (OpenCSG) to fix this. Until then, make sure that your negative volumes overshoot a bit. I usually overshoot by a good margin (like 25% of the total length or so) as that helps debugging when highlighting individual objects.
>
>   -Marius
>
> _______________________________________________
> OpenSCAD mailing list
> [hidden email]
> http://rocklinux.net/mailman/listinfo/openscad
> http://openscad.org - https://flattr.com/thing/121566
>

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566
Reply | Threaded
Open this post in threaded view
|

Re: math bug (feature?)

David Powell
i tend to think that it can be seen as  justified as it is from an engineering point of view as it "highlights " the fact that your doing an absolute  difference 
ie    difference(){cube ([10,10,10],center=true); cylinder(h=10,r=3,center=true);)  to show where you intend to drill a hole by the process , where to drill the hole though the drill would need to pass though the object by an amount that would ensure there's no "flash"(thin skin) left on the one end

for what should be difference(){cube ([10,10,10],center=true); cylinder(h=10+hTol,r=3+rTol,center=true);) where hTol is the actual amount of drill travel needed and rTol the size tolerance value of the hole that such a drill would make 

but in a lot of cases of doing pure CSG for say 3d printed part generation does appear to get in the way  and be a "bug" rather than a "feature" of something that is rely a bug anyway 


On Sun, Jun 23, 2013 at 7:07 AM, Ruud Vlaming <[hidden email]> wrote:
Actually, i see this more as a feature because you
can quickly view if two objects end at the same
place. From the code this can be hard, since
mine is all parametrized.


On 23-06-13 05:47, Marius Kintel wrote:
> On 2013-06-22, at 23:36 , Jesse Guardiani wrote:
>>
>> Is this caused by rounding errors? What's the recommended workaround?
>>
> These only appear in the preview view. We don't actually compute geometry there, we just send it to OpenGL and use OpenGL's built-in depth buffer (with a few tricks) to rendering something visually resembling what you've designed. This depth buffer has a very limited precision and you thus get "z buffer fighting" when rendering coincident positive and negative surfaces. It might be possible for the underlying library (OpenCSG) to fix this. Until then, make sure that your negative volumes overshoot a bit. I usually overshoot by a good margin (like 25% of the total length or so) as that helps debugging when highlighting individual objects.
>
>   -Marius
>
> _______________________________________________
> OpenSCAD mailing list
> [hidden email]
> http://rocklinux.net/mailman/listinfo/openscad
> http://openscad.org - https://flattr.com/thing/121566
>

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566
Reply | Threaded
Open this post in threaded view
|

Re: math bug (feature?)

rduarte
If nothing else, it's a good teaching tool when explaining why coincident faces are an issue when trying to make a manifold model.

On Jun 23, 2013, at 8:24 AM, "David Powell" <[hidden email]> wrote:

i tend to think that it can be seen as  justified as it is from an engineering point of view as it "highlights " the fact that your doing an absolute  difference 
ie    difference(){cube ([10,10,10],center=true); cylinder(h=10,r=3,center=true);)  to show where you intend to drill a hole by the process , where to drill the hole though the drill would need to pass though the object by an amount that would ensure there's no "flash"(thin skin) left on the one end

for what should be difference(){cube ([10,10,10],center=true); cylinder(h=10+hTol,r=3+rTol,center=true);) where hTol is the actual amount of drill travel needed and rTol the size tolerance value of the hole that such a drill would make 

but in a lot of cases of doing pure CSG for say 3d printed part generation does appear to get in the way  and be a "bug" rather than a "feature" of something that is rely a bug anyway 


On Sun, Jun 23, 2013 at 7:07 AM, Ruud Vlaming <[hidden email]> wrote:
Actually, i see this more as a feature because you
can quickly view if two objects end at the same
place. From the code this can be hard, since
mine is all parametrized.


On 23-06-13 05:47, Marius Kintel wrote:
> On 2013-06-22, at 23:36 , Jesse Guardiani wrote:
>>
>> Is this caused by rounding errors? What's the recommended workaround?
>>
> These only appear in the preview view. We don't actually compute geometry there, we just send it to OpenGL and use OpenGL's built-in depth buffer (with a few tricks) to rendering something visually resembling what you've designed. This depth buffer has a very limited precision and you thus get "z buffer fighting" when rendering coincident positive and negative surfaces. It might be possible for the underlying library (OpenCSG) to fix this. Until then, make sure that your negative volumes overshoot a bit. I usually overshoot by a good margin (like 25% of the total length or so) as that helps debugging when highlighting individual objects.
>
>   -Marius
>
> _______________________________________________
> OpenSCAD mailing list
> [hidden email]
> http://rocklinux.net/mailman/listinfo/openscad
> http://openscad.org - https://flattr.com/thing/121566
>

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566
Reply | Threaded
Open this post in threaded view
|

Re: math bug (feature?)

Torsten Wagner
Hi, 

I would say more bug then feature.
Esp. if you do not work with center, you end up with something like (stolen from David)

difference(){cube ([10,10,10],center=false); translate([-1,0,0]) cylinder(h=12,r=3,center=false);}

Which actually introduce one more command and the question why the cylinder is 12 long if all I can see from the result it should be 10 long.... that is the question you ask yourself looking at the code a few month later. 
Visually, not adding any overshoot, makes it sometimes impossible to see details of the underlying object.


difference(){cube ([10,10,10],center=false); translate([-1,0,0]) cylinder(h=10+2,r=3,center=false);}
helps a bit but still tends to irritate.

Is this only a rendering problem of the preview? If you create a STL out of it, would it be correct?
In that case, I would say it is a minor graphical problem, which should be fixed if there is time.
If e.g. the STL export might get broken by this, it might be problem which require a more urgent attention.
E.g., assuming the STL export is wrong, there is nothing about this in the manual, which might trap a lot of people starting with OpenSCAD for 3D printing.

Greetings

Torwag







On 23 June 2013 14:44, rduarte <[hidden email]> wrote:
If nothing else, it's a good teaching tool when explaining why coincident faces are an issue when trying to make a manifold model.

On Jun 23, 2013, at 8:24 AM, "David Powell" <[hidden email]> wrote:

i tend to think that it can be seen as  justified as it is from an engineering point of view as it "highlights " the fact that your doing an absolute  difference 
ie    difference(){cube ([10,10,10],center=true); cylinder(h=10,r=3,center=true);)  to show where you intend to drill a hole by the process , where to drill the hole though the drill would need to pass though the object by an amount that would ensure there's no "flash"(thin skin) left on the one end

for what should be difference(){cube ([10,10,10],center=true); cylinder(h=10+hTol,r=3+rTol,center=true);) where hTol is the actual amount of drill travel needed and rTol the size tolerance value of the hole that such a drill would make 

but in a lot of cases of doing pure CSG for say 3d printed part generation does appear to get in the way  and be a "bug" rather than a "feature" of something that is rely a bug anyway 


On Sun, Jun 23, 2013 at 7:07 AM, Ruud Vlaming <[hidden email]> wrote:
Actually, i see this more as a feature because you
can quickly view if two objects end at the same
place. From the code this can be hard, since
mine is all parametrized.


On 23-06-13 05:47, Marius Kintel wrote:
> On 2013-06-22, at 23:36 , Jesse Guardiani wrote:
>>
>> Is this caused by rounding errors? What's the recommended workaround?
>>
> These only appear in the preview view. We don't actually compute geometry there, we just send it to OpenGL and use OpenGL's built-in depth buffer (with a few tricks) to rendering something visually resembling what you've designed. This depth buffer has a very limited precision and you thus get "z buffer fighting" when rendering coincident positive and negative surfaces. It might be possible for the underlying library (OpenCSG) to fix this. Until then, make sure that your negative volumes overshoot a bit. I usually overshoot by a good margin (like 25% of the total length or so) as that helps debugging when highlighting individual objects.
>
>   -Marius
>
> _______________________________________________
> OpenSCAD mailing list
> [hidden email]
> http://rocklinux.net/mailman/listinfo/openscad
> http://openscad.org - https://flattr.com/thing/121566
>

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566
Reply | Threaded
Open this post in threaded view
|

Re: math bug (feature?)

nophead
It isn't simply a display bug. You don't get manifold objects if you do CSG with coincident faces, so there should always be some overlap.




On 23 June 2013 14:18, Torsten Wagner <[hidden email]> wrote:
Hi, 

I would say more bug then feature.
Esp. if you do not work with center, you end up with something like (stolen from David)

difference(){cube ([10,10,10],center=false); translate([-1,0,0]) cylinder(h=12,r=3,center=false);}

Which actually introduce one more command and the question why the cylinder is 12 long if all I can see from the result it should be 10 long.... that is the question you ask yourself looking at the code a few month later. 
Visually, not adding any overshoot, makes it sometimes impossible to see details of the underlying object.


difference(){cube ([10,10,10],center=false); translate([-1,0,0]) cylinder(h=10+2,r=3,center=false);}
helps a bit but still tends to irritate.

Is this only a rendering problem of the preview? If you create a STL out of it, would it be correct?
In that case, I would say it is a minor graphical problem, which should be fixed if there is time.
If e.g. the STL export might get broken by this, it might be problem which require a more urgent attention.
E.g., assuming the STL export is wrong, there is nothing about this in the manual, which might trap a lot of people starting with OpenSCAD for 3D printing.

Greetings

Torwag







On 23 June 2013 14:44, rduarte <[hidden email]> wrote:
If nothing else, it's a good teaching tool when explaining why coincident faces are an issue when trying to make a manifold model.

On Jun 23, 2013, at 8:24 AM, "David Powell" <[hidden email]> wrote:

i tend to think that it can be seen as  justified as it is from an engineering point of view as it "highlights " the fact that your doing an absolute  difference 
ie    difference(){cube ([10,10,10],center=true); cylinder(h=10,r=3,center=true);)  to show where you intend to drill a hole by the process , where to drill the hole though the drill would need to pass though the object by an amount that would ensure there's no "flash"(thin skin) left on the one end

for what should be difference(){cube ([10,10,10],center=true); cylinder(h=10+hTol,r=3+rTol,center=true);) where hTol is the actual amount of drill travel needed and rTol the size tolerance value of the hole that such a drill would make 

but in a lot of cases of doing pure CSG for say 3d printed part generation does appear to get in the way  and be a "bug" rather than a "feature" of something that is rely a bug anyway 


On Sun, Jun 23, 2013 at 7:07 AM, Ruud Vlaming <[hidden email]> wrote:
Actually, i see this more as a feature because you
can quickly view if two objects end at the same
place. From the code this can be hard, since
mine is all parametrized.


On 23-06-13 05:47, Marius Kintel wrote:
> On 2013-06-22, at 23:36 , Jesse Guardiani wrote:
>>
>> Is this caused by rounding errors? What's the recommended workaround?
>>
> These only appear in the preview view. We don't actually compute geometry there, we just send it to OpenGL and use OpenGL's built-in depth buffer (with a few tricks) to rendering something visually resembling what you've designed. This depth buffer has a very limited precision and you thus get "z buffer fighting" when rendering coincident positive and negative surfaces. It might be possible for the underlying library (OpenCSG) to fix this. Until then, make sure that your negative volumes overshoot a bit. I usually overshoot by a good margin (like 25% of the total length or so) as that helps debugging when highlighting individual objects.
>
>   -Marius
>
> _______________________________________________
> OpenSCAD mailing list
> [hidden email]
> http://rocklinux.net/mailman/listinfo/openscad
> http://openscad.org - https://flattr.com/thing/121566
>

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566
Reply | Threaded
Open this post in threaded view
|

Re: math bug (feature?)

David Powell
In reply to this post by Torsten Wagner
but that still does raise the issue that there is a need to be able to highlight graphically on the output maybe in full compile the points where a object does fails to be a manifold or other problem arias obtained during the actual compile where it would be more useful 


On Sun, Jun 23, 2013 at 2:18 PM, Torsten Wagner <[hidden email]> wrote:
Hi, 

I would say more bug then feature.
Esp. if you do not work with center, you end up with something like (stolen from David)

difference(){cube ([10,10,10],center=false); translate([-1,0,0]) cylinder(h=12,r=3,center=false);}

Which actually introduce one more command and the question why the cylinder is 12 long if all I can see from the result it should be 10 long.... that is the question you ask yourself looking at the code a few month later. 
Visually, not adding any overshoot, makes it sometimes impossible to see details of the underlying object.


difference(){cube ([10,10,10],center=false); translate([-1,0,0]) cylinder(h=10+2,r=3,center=false);}
helps a bit but still tends to irritate.

Is this only a rendering problem of the preview? If you create a STL out of it, would it be correct?
In that case, I would say it is a minor graphical problem, which should be fixed if there is time.
If e.g. the STL export might get broken by this, it might be problem which require a more urgent attention.
E.g., assuming the STL export is wrong, there is nothing about this in the manual, which might trap a lot of people starting with OpenSCAD for 3D printing.

Greetings

Torwag







On 23 June 2013 14:44, rduarte <[hidden email]> wrote:
If nothing else, it's a good teaching tool when explaining why coincident faces are an issue when trying to make a manifold model.

On Jun 23, 2013, at 8:24 AM, "David Powell" <[hidden email]> wrote:

i tend to think that it can be seen as  justified as it is from an engineering point of view as it "highlights " the fact that your doing an absolute  difference 
ie    difference(){cube ([10,10,10],center=true); cylinder(h=10,r=3,center=true);)  to show where you intend to drill a hole by the process , where to drill the hole though the drill would need to pass though the object by an amount that would ensure there's no "flash"(thin skin) left on the one end

for what should be difference(){cube ([10,10,10],center=true); cylinder(h=10+hTol,r=3+rTol,center=true);) where hTol is the actual amount of drill travel needed and rTol the size tolerance value of the hole that such a drill would make 

but in a lot of cases of doing pure CSG for say 3d printed part generation does appear to get in the way  and be a "bug" rather than a "feature" of something that is rely a bug anyway 


On Sun, Jun 23, 2013 at 7:07 AM, Ruud Vlaming <[hidden email]> wrote:
Actually, i see this more as a feature because you
can quickly view if two objects end at the same
place. From the code this can be hard, since
mine is all parametrized.


On 23-06-13 05:47, Marius Kintel wrote:
> On 2013-06-22, at 23:36 , Jesse Guardiani wrote:
>>
>> Is this caused by rounding errors? What's the recommended workaround?
>>
> These only appear in the preview view. We don't actually compute geometry there, we just send it to OpenGL and use OpenGL's built-in depth buffer (with a few tricks) to rendering something visually resembling what you've designed. This depth buffer has a very limited precision and you thus get "z buffer fighting" when rendering coincident positive and negative surfaces. It might be possible for the underlying library (OpenCSG) to fix this. Until then, make sure that your negative volumes overshoot a bit. I usually overshoot by a good margin (like 25% of the total length or so) as that helps debugging when highlighting individual objects.
>
>   -Marius
>
> _______________________________________________
> OpenSCAD mailing list
> [hidden email]
> http://rocklinux.net/mailman/listinfo/openscad
> http://openscad.org - https://flattr.com/thing/121566
>

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566
Reply | Threaded
Open this post in threaded view
|

Re: math bug (feature?)

David Powell
In reply to this post by nophead

main();

module thisobject(a)

{

cube(10,10,10,center=a);

}


module main()

{

a=true;

difference()

{

translate([0,0,0])

thisobject(a);

translate([6,0,0])

thisobject(a);

translate([-6,-6,0])

thisobject(a);

translate([-6.0000001,4,0.0000001])

thisobject(a);

}}


that although trying to get it so it did not produce a manifold it seems to do quite well

and makes one with an error  that is hard to visualise where in preview 



On Sun, Jun 23, 2013 at 2:28 PM, nop head <[hidden email]> wrote:
It isn't simply a display bug. You don't get manifold objects if you do CSG with coincident faces, so there should always be some overlap.




On 23 June 2013 14:18, Torsten Wagner <[hidden email]> wrote:
Hi, 

I would say more bug then feature.
Esp. if you do not work with center, you end up with something like (stolen from David)

difference(){cube ([10,10,10],center=false); translate([-1,0,0]) cylinder(h=12,r=3,center=false);}

Which actually introduce one more command and the question why the cylinder is 12 long if all I can see from the result it should be 10 long.... that is the question you ask yourself looking at the code a few month later. 
Visually, not adding any overshoot, makes it sometimes impossible to see details of the underlying object.


difference(){cube ([10,10,10],center=false); translate([-1,0,0]) cylinder(h=10+2,r=3,center=false);}
helps a bit but still tends to irritate.

Is this only a rendering problem of the preview? If you create a STL out of it, would it be correct?
In that case, I would say it is a minor graphical problem, which should be fixed if there is time.
If e.g. the STL export might get broken by this, it might be problem which require a more urgent attention.
E.g., assuming the STL export is wrong, there is nothing about this in the manual, which might trap a lot of people starting with OpenSCAD for 3D printing.

Greetings

Torwag







On 23 June 2013 14:44, rduarte <[hidden email]> wrote:
If nothing else, it's a good teaching tool when explaining why coincident faces are an issue when trying to make a manifold model.

On Jun 23, 2013, at 8:24 AM, "David Powell" <[hidden email]> wrote:

i tend to think that it can be seen as  justified as it is from an engineering point of view as it "highlights " the fact that your doing an absolute  difference 
ie    difference(){cube ([10,10,10],center=true); cylinder(h=10,r=3,center=true);)  to show where you intend to drill a hole by the process , where to drill the hole though the drill would need to pass though the object by an amount that would ensure there's no "flash"(thin skin) left on the one end

for what should be difference(){cube ([10,10,10],center=true); cylinder(h=10+hTol,r=3+rTol,center=true);) where hTol is the actual amount of drill travel needed and rTol the size tolerance value of the hole that such a drill would make 

but in a lot of cases of doing pure CSG for say 3d printed part generation does appear to get in the way  and be a "bug" rather than a "feature" of something that is rely a bug anyway 


On Sun, Jun 23, 2013 at 7:07 AM, Ruud Vlaming <[hidden email]> wrote:
Actually, i see this more as a feature because you
can quickly view if two objects end at the same
place. From the code this can be hard, since
mine is all parametrized.


On 23-06-13 05:47, Marius Kintel wrote:
> On 2013-06-22, at 23:36 , Jesse Guardiani wrote:
>>
>> Is this caused by rounding errors? What's the recommended workaround?
>>
> These only appear in the preview view. We don't actually compute geometry there, we just send it to OpenGL and use OpenGL's built-in depth buffer (with a few tricks) to rendering something visually resembling what you've designed. This depth buffer has a very limited precision and you thus get "z buffer fighting" when rendering coincident positive and negative surfaces. It might be possible for the underlying library (OpenCSG) to fix this. Until then, make sure that your negative volumes overshoot a bit. I usually overshoot by a good margin (like 25% of the total length or so) as that helps debugging when highlighting individual objects.
>
>   -Marius
>
> _______________________________________________
> OpenSCAD mailing list
> [hidden email]
> http://rocklinux.net/mailman/listinfo/openscad
> http://openscad.org - https://flattr.com/thing/121566
>

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566
Reply | Threaded
Open this post in threaded view
|

Re: math bug (feature?)

marcosscriven
In reply to this post by David Powell
>It isn't simply a display bug. You don't get manifold objects if you do CSG with coincident faces, so there should always be some overlap.

Actually, so long as the boolean operations are regularised (which in CGAL there appears to be the option for: http://www.cgal.org/Manual/latest/doc_html/cgal_manual/Nef_3/Chapter_main.html#Section_29.4), then CSG ops on b-rep polygons with coincident faces *do* still yield manifold objects.

There's some extra stuff that needs to happen over and above simple CSG ops - for instance checking whether boundary points to be included in the result, depends on whether the interior of the polys are also coincident, for example.

Marcos
Reply | Threaded
Open this post in threaded view
|

Re: math bug (feature?)

nophead
"CSG ops on b-rep polygons"

This fragment confuses me. Did you mean boolean ops on b-rep polygons? My (limited) understanding is CSG and b-rep are alternative ways of representing solids. b-rep seems to not suffer from the same problems as CSG when you do boolean operations.

Also I think openscad can have a manifold shape in its representation but when converted to STL it becomes non-manifold due to floating point representation not being exact.



On 23 June 2013 16:11, marcosscriven <[hidden email]> wrote:
>It isn't simply a display bug. You don't get manifold objects if you do CSG
with coincident faces, so there should always be some overlap.

Actually, so long as the boolean operations are regularised (which in CGAL
there appears to be the option for:
http://www.cgal.org/Manual/latest/doc_html/cgal_manual/Nef_3/Chapter_main.html#Section_29.4),
then CSG ops on b-rep polygons with coincident faces *do* still yield
manifold objects.

There's some extra stuff that needs to happen over and above simple CSG ops
- for instance checking whether boundary points to be included in the
result, depends on whether the interior of the polys are also coincident,
for example.

Marcos



--
View this message in context: http://forum.openscad.org/math-bug-feature-tp4870p4886.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566
Reply | Threaded
Open this post in threaded view
|

Re: math bug (feature?)

Doug Mcnutt
In reply to this post by David Powell
The discussion has shown examples that seem always to be in simple integers, likely inches in the writer's brain if he's in the US of A.

The very thin surface might well be the result of fundamental limits to the accuracy of an IEEE float or double when fractions are involved.  It's quite impossible to store a US dime, 1/10 of a dollar, in a float without a tiny error. In binary 1/10  is 0.00011001100110011... forever just as in base 10 1/3 = 0.33333... forever. IEEE doubles roll over after 52 bits which is roughly 14 decimal digits.

Folks who see the problem might try using binary fractions in their inputs. It would be the old fashioned way of describing parts of an inch in parts like 1/16, 5/32 and the like. Those numbers are exactly representable as floats.  But then dividing a box into 5 parts will create impossible numbers anyway.

--

-->  Halloween  == Oct 31 == Dec 25 == Christmas  <--
_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566
Reply | Threaded
Open this post in threaded view
|

Re: math bug (feature?)

marcosscriven
In reply to this post by nophead
In the context of this discussion, I thought you were saying the issue with coincident faces was not just a visual thing (z-fighting in the image based CSG), but a fundamental problem of coincident faces in CSG representations?

I guess the term CSG can mean both an *unevaluated* representation of a model, but also the actual application/evaluation (to produce a b-rep, mesh, whatever).

If you happen to the CG bible "Computer Graphics - Principles and Practice", the table on page 538 describes what I mean, although slide 10 here appears to have been lifted verbatim from that book: http://www.slideshare.net/KRvEsL/solid-modeling




Reply | Threaded
Open this post in threaded view
|

Re: math bug (feature?)

G. Wade Johnson
In reply to this post by Torsten Wagner
Sorry to butt in, but as a programmer, I normally handle this kind of
issue the same way I would in any code.

On Sun, 23 Jun 2013 15:18:21 +0200
Torsten Wagner <[hidden email]> wrote:

> Hi,
>
> I would say more bug then feature.
> Esp. if you do not work with center, you end up with something like
> (stolen from David)
>
> difference(){cube ([10,10,10],center=false); translate([-1,0,0])
> cylinder(h=12,r=3,center=false);}
>
> Which actually introduce one more command and the question why the
> cylinder is 12 long if all I can see from the result it should be 10
> long.... that is the question you ask yourself looking at the code a
> few month later. Visually, not adding any overshoot, makes it
> sometimes impossible to see details of the underlying object.

I normally make a constant for this thing that I need to name.

overlap=2;
side=10;

difference() {
    cube ([side,side,side],center=false);
    translate([-overlap/2,0,0])
       cylinder(h=side+overlap,r=3,center=false);
}

Raw literals are hard to understand in any language. Giving them names
simplifies understanding later.

> difference(){cube ([10,10,10],center=false); translate([-1,0,0])
> cylinder(h=10+2,r=3,center=false);}
> helps a bit but still tends to irritate.

Using names also fixes the fact that the -1 and the +2 are related,
which may not be obvious when you come back to this in 6 months.

G. Wade

> Is this only a rendering problem of the preview? If you create a STL
> out of it, would it be correct?
> In that case, I would say it is a minor graphical problem, which
> should be fixed if there is time.
> If e.g. the STL export might get broken by this, it might be problem
> which require a more urgent attention.
> E.g., assuming the STL export is wrong, there is nothing about this
> in the manual, which might trap a lot of people starting with
> OpenSCAD for 3D printing.
>
> Greetings
>
> Torwag
>
>
>
>
>
>
>
> On 23 June 2013 14:44, rduarte <[hidden email]> wrote:
>
> >  If nothing else, it's a good teaching tool when explaining why
> > coincident faces are an issue when trying to make a manifold model.
> >
> > On Jun 23, 2013, at 8:24 AM, "David Powell"
> > <[hidden email]> wrote:
> >
> >   i tend to think that it can be seen as  justified as it is from an
> > engineering point of view as it "highlights " the fact that your
> > doing an absolute  difference
> > ie    difference(){cube ([10,10,10],center=true);
> > cylinder(h=10,r=3,center=true);)  to show where you intend to drill
> > a hole by the process , where to drill the hole though the drill
> > would need to pass though the object by an amount that would ensure
> > there's no "flash"(thin skin) left on the one end
> >
> >  for what should be difference(){cube ([10,10,10],center=true);
> > cylinder(h=10+hTol,r=3+rTol,center=true);) where hTol is the actual
> > amount of drill travel needed and rTol the size tolerance value of
> > the hole that such a drill would make
> >
> >  but in a lot of cases of doing pure CSG for say 3d printed part
> > generation does appear to get in the way  and be a "bug" rather
> > than a "feature" of something that is rely a bug anyway
> >
> >
> > On Sun, Jun 23, 2013 at 7:07 AM, Ruud Vlaming
> > <[hidden email]>wrote:
> >
> >> Actually, i see this more as a feature because you
> >> can quickly view if two objects end at the same
> >> place. From the code this can be hard, since
> >> mine is all parametrized.
> >>
> >>
> >> On 23-06-13 05:47, Marius Kintel wrote:
> >> > On 2013-06-22, at 23:36 , Jesse Guardiani wrote:
> >> >>
> >> >> Is this caused by rounding errors? What's the recommended
> >> >> workaround?
> >> >>
> >> > These only appear in the preview view. We don't actually compute
> >> geometry there, we just send it to OpenGL and use OpenGL's
> >> built-in depth buffer (with a few tricks) to rendering something
> >> visually resembling what you've designed. This depth buffer has a
> >> very limited precision and you thus get "z buffer fighting" when
> >> rendering coincident positive and negative surfaces. It might be
> >> possible for the underlying library (OpenCSG) to fix this. Until
> >> then, make sure that your negative volumes overshoot a bit. I
> >> usually overshoot by a good margin (like 25% of the total length
> >> or so) as that helps debugging when highlighting individual
> >> objects.
> >> >
> >> >   -Marius
> >> >
> >> > _______________________________________________
> >> > OpenSCAD mailing list
> >> > [hidden email]
> >> > http://rocklinux.net/mailman/listinfo/openscad
> >> > http://openscad.org - https://flattr.com/thing/121566
> >> >
> >>
> >> _______________________________________________
> >> OpenSCAD mailing list
> >> [hidden email]
> >> http://rocklinux.net/mailman/listinfo/openscad
> >> http://openscad.org - https://flattr.com/thing/121566
> >>
> >
> >    _______________________________________________
> > OpenSCAD mailing list
> > [hidden email]
> > http://rocklinux.net/mailman/listinfo/openscad
> > http://openscad.org - https://flattr.com/thing/121566
> >
> >
> > _______________________________________________
> > OpenSCAD mailing list
> > [hidden email]
> > http://rocklinux.net/mailman/listinfo/openscad
> > http://openscad.org - https://flattr.com/thing/121566
> >


--
It is wise to remember that you are one of those who can be fooled some
of the time.                                      -- Laurence J. Peter
_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566
Reply | Threaded
Open this post in threaded view
|

Re: math bug (feature?)

nophead
In reply to this post by marcosscriven



On 23 June 2013 17:00, marcosscriven <[hidden email]> wrote:
In the context of this discussion, I thought you were saying the issue with
coincident faces was not just a visual thing (z-fighting in the image based
CSG), but a fundamental problem of coincident faces in CSG representations?

Yes according to Dr Adrian Bowyer it is fundamental, like quantum mechanics.
 

I guess the term CSG can mean both an *unevaluated* representation of a
model, but also the actual application/evaluation (to produce a b-rep, mesh,
whatever).

If you happen to the CG bible "Computer Graphics - Principles and Practice",
the table on page 538 describes what I mean, although slide 10 here appears
to have been lifted verbatim from that book:
http://www.slideshare.net/KRvEsL/solid-modeling

How is this ever going to make something manifold?

union() {

   cube(10);

   translate([10, 10, 0])

       cube(10);

}











--
View this message in context: http://forum.openscad.org/math-bug-feature-tp4870p4891.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566
Reply | Threaded
Open this post in threaded view
|

Re: math bug (feature?)

David Powell
In reply to this post by David Powell
with pure CSG math precision on that scale would is all well and good assuming that the output machine tolerance would be capable of of the same tolerance ,  at what point does this become 1/2 an atom thick and you actualy needing that amount of precision 
is the machine that's going to produce it capable of that precision anyway , 

given that the preview is limited precision for faster compile  at what level of precision is the output needed anyway , if the machine thats printing it only has a 0.001 tolerance , then it would also be more effective to round those values speeding up the full render also 

what is probably a better solution would auto fix the problem of not getting a manifold if the tolerance value is known prior to compile  and within the limits of the maths needed 

in that if a needed tolerance rounding is to 0.01mm the max precision needed would be 0.005  , that would stop it being an issue , that needs corrections to resolve  

but it would require the addition of a  tolerance setting option

this would have 3 good advantages , firstly resolving the coincident face issue in 99.9% of cases where the difference is too small or is actually 0 (equal size) , and there for producing a valid manifold , and secondly as the maths precision needed is much less could speed up the calculation time of the full render  


On Sun, Jun 23, 2013 at 4:51 PM, Doug Mcnutt <[hidden email]> wrote:
The discussion has shown examples that seem always to be in simple integers, likely inches in the writer's brain if he's in the US of A.

The very thin surface might well be the result of fundamental limits to the accuracy of an IEEE float or double when fractions are involved.  It's quite impossible to store a US dime, 1/10 of a dollar, in a float without a tiny error. In binary 1/10  is 0.00011001100110011... forever just as in base 10 1/3 = 0.33333... forever. IEEE doubles roll over after 52 bits which is roughly 14 decimal digits.

Folks who see the problem might try using binary fractions in their inputs. It would be the old fashioned way of describing parts of an inch in parts like 1/16, 5/32 and the like. Those numbers are exactly representable as floats.  But then dividing a box into 5 parts will create impossible numbers anyway.

--

-->  Halloween  == Oct 31 == Dec 25 == Christmas  <--
_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566
Reply | Threaded
Open this post in threaded view
|

Re: math bug (feature?)

marcosscriven
In reply to this post by nophead
To take your example:

union() {
   cube(10);
   translate([10, 10, 0])
       cube(10);
}

Using the *regularised* union (not just simply unioning the boundaries together), and evaluating that CSG operation, the duplicate boundary between those cubes would be removed.





Reply | Threaded
Open this post in threaded view
|

Re: math bug (feature?)

nophead
But what would the result be? It describes something non-manifold so if it makes something that is manifold it must not match the code.


On 23 June 2013 17:45, marcosscriven <[hidden email]> wrote:
To take your example:

union() {
   cube(10);
   translate([10, 10, 0])
       cube(10);
}

Using the *regularised* union (not just simply unioning the boundaries
together), and evaluating that CSG operation, the duplicate boundary between
those cubes would be removed.


<http://forum.openscad.org/file/n4898/Screen_Shot_2013-06-23_at_17.44.40.png>






--
View this message in context: http://forum.openscad.org/math-bug-feature-tp4870p4898.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566
Reply | Threaded
Open this post in threaded view
|

Re: math bug (feature?)

marcosscriven
What it describes depends on what 'union' means right? And so far as I read, 'union' can mean 'regularised union' in the context of CSG. You don't appear to be making that distinction.

To quote the CGAL page: http://www.cgal.org/Manual/latest/doc_html/cgal_manual/Nef_3/Chapter_main.html

"29.4   Regularized Set Operations

Since manifolds are not closed under boolean operations, Requicha proposes to use regularized set operations [KM76, Req80]. A set is regular, if it equals the closure of its interior. A regularized set operation is defined as the standard set operation followed by a regularization of the result. Regularized sets are closed under regularized set operations.

Regularized set operations are important since they simplify the class of solids to exclude lower dimensional features and the boundary belongs to the point set. These properties are considered to reflect the nature of physical solids more closely.

Regularized polyhedral sets are a subclass of Nef polyhedra. We provide the regularization operation as a shortcut for the consecutive execution of the interior and the closure operations.
"
123