Unexpected Crazing on Coincident Surfaces

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

Unexpected Crazing on Coincident Surfaces

Huxley
I am well aware of the issue with rendering coincident surfaces, but I'm
seeing crazing (that is areas of alternating colors covering a surface)
when I don't actually have coincident surfaces.  I was hoping that
someone could tell me if this is a known issue, or if I am doing
something wrong.

I've reduced the problem down to the following script:

color("Green")
        translate([2,2,0])
                cube([98,98,1]);
difference(convexity=4)
{
        translate([0,0,1])
                cube([102,102,2]);
        translate([1,1,0])
                cube([100,100,4]);
}

Perhaps I'm doing something wrong, but the renderer appears to be
rendering surfaces that should have been removed by the difference
operator.

Is there any way to avoid this issue without adjusting the elevation of
one of the pieces?

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

Re: Unexpected Crazing on Coincident Surfaces

nophead
If you precede difference() with render() it solves the problem.

OpenSCAD uses OpenCSG to draw the preview. That always draws all the objects, even the negative ones and doesn't cope with coincident surfaces. render() will calculate the actual geometry with CGAL so the common surface is removed.

On 11 October 2017 at 19:46, Linda Huxley <[hidden email]> wrote:
I am well aware of the issue with rendering coincident surfaces, but I'm seeing crazing (that is areas of alternating colors covering a surface) when I don't actually have coincident surfaces.  I was hoping that someone could tell me if this is a known issue, or if I am doing something wrong.

I've reduced the problem down to the following script:

color("Green")
        translate([2,2,0])
                cube([98,98,1]);
difference(convexity=4)
{
        translate([0,0,1])
                cube([102,102,2]);
        translate([1,1,0])
                cube([100,100,4]);
}

Perhaps I'm doing something wrong, but the renderer appears to be rendering surfaces that should have been removed by the difference operator.

Is there any way to avoid this issue without adjusting the elevation of one of the pieces?

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

Re: Unexpected Crazing on Coincident Surfaces

Neon22
In reply to this post by Huxley
This is probably the visualisation in the viewer rather than a fault in
the actual object.
In order to get interactive speed simple tricks are used in the OpenGL
framebuffer code to simulate the result of the much more lengthy 'real'
code which is run when you hit F6.

This causes visual annoyances which we all have to accept. So try again
using F6 to render the object into its finished form. compare with F5
for interactive feedback.



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

Re: Unexpected Crazing on Coincident Surfaces

MichaelAtOz
Administrator
So if you resolve the coincident faces, including the differing ones it
works.

color("Green")
        translate([2,2,-0.005])
                cube([98,98,1]);
   
difference(convexity=4)
{
        translate([0,0,1])
                cube([102,102,2]);
        translate([1,1,0.005])
                cube([100,100,4]);
}




-----
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!
--
Sent from: http://forum.openscad.org/

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

Re: Unexpected Crazing on Coincident Surfaces

mmccool
In reply to this post by Huxley
In preview mode (F6) OpenSCAD is using a library that does CSG in the depth buffer of the graphics card using finite precision.  So even with not-quite coincident surfaces you may see this effect due to quantization.   Just remember it's a "preview" mode and not perfect.  If your model is correct when you compile it (which uses higher, in fact "infinite precision" arithmetic), don't worry about it.

As a second note, the CSG preview library does not work well on non-NVIDIA GPUs.  In particular it does not work well on integrated Intel GPUs (unfortunately... see my signature).   As far as I know that is just a matter of people not debugging it for those GPUs.  Probably.

Michael McCool, Principal Engineer, Intel
SSG/DPD/Technology Pathfinding and Innovation

> On Oct 12, 2017, at 3:46, Linda Huxley <[hidden email]> wrote:
>
> I am well aware of the issue with rendering coincident surfaces, but I'm seeing crazing (that is areas of alternating colors covering a surface) when I don't actually have coincident surfaces.  I was hoping that someone could tell me if this is a known issue, or if I am doing something wrong.
>
> I've reduced the problem down to the following script:
>
> color("Green")
>    translate([2,2,0])
>        cube([98,98,1]);
> difference(convexity=4)
> {
>    translate([0,0,1])
>        cube([102,102,2]);
>    translate([1,1,0])
>        cube([100,100,4]);
> }
>
> Perhaps I'm doing something wrong, but the renderer appears to be rendering surfaces that should have been removed by the difference operator.
>
> Is there any way to avoid this issue without adjusting the elevation of one of the pieces?
>
> _______________________________________________
> 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
|

Re: Unexpected Crazing on Coincident Surfaces

codifies
Can't speak for windows drivers but I've noticed little difference with
previews on my desktop or laptop
nvidia vs intel HD5500

the whole issue is mute in any case the few times that this issue as
caused actual problems (not being able
to see into an object  I'm "boolean-ing" simply changing the size of
whatever I'm subtracting by a very tiny
amount gets rid of the issue entirely (I only tend to boolean 2 objects
at a time, even if I need say 3 holes
in something I just use successive operations)

and as already pointed out a *preview* isn't intended to be perfect....

On 12/10/17 07:01, Michael McCool wrote:

> In preview mode (F6) OpenSCAD is using a library that does CSG in the depth buffer of the graphics card using finite precision.  So even with not-quite coincident surfaces you may see this effect due to quantization.   Just remember it's a "preview" mode and not perfect.  If your model is correct when you compile it (which uses higher, in fact "infinite precision" arithmetic), don't worry about it.
>
> As a second note, the CSG preview library does not work well on non-NVIDIA GPUs.  In particular it does not work well on integrated Intel GPUs (unfortunately... see my signature).   As far as I know that is just a matter of people not debugging it for those GPUs.  Probably.
>
> Michael McCool, Principal Engineer, Intel
> SSG/DPD/Technology Pathfinding and Innovation
>
>> On Oct 12, 2017, at 3:46, Linda Huxley <[hidden email]> wrote:
>>
>> I am well aware of the issue with rendering coincident surfaces, but I'm seeing crazing (that is areas of alternating colors covering a surface) when I don't actually have coincident surfaces.  I was hoping that someone could tell me if this is a known issue, or if I am doing something wrong.
>>
>> I've reduced the problem down to the following script:
>>
>> color("Green")
>>     translate([2,2,0])
>>         cube([98,98,1]);
>> difference(convexity=4)
>> {
>>     translate([0,0,1])
>>         cube([102,102,2]);
>>     translate([1,1,0])
>>         cube([100,100,4]);
>> }
>>
>> Perhaps I'm doing something wrong, but the renderer appears to be rendering surfaces that should have been removed by the difference operator.
>>
>> Is there any way to avoid this issue without adjusting the elevation of one of the pieces?
>>
>> _______________________________________________
>> 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


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

Re: Unexpected Crazing on Coincident Surfaces

mmccool
Regarding the issue with Intel GPUs, the problem may have been resolved with recent updates to Intel OpenGL drivers, Intel HW, or the OpenCSG library.  I sure hope so.  I'll have to try again.  My main interest in seeing this fixed is being able to use OpenSCAD on a laptop, although it's good to hear OpenCSG now works on Intel desktop GPUs.  As an aside, I haven't really tested on AMD GPUs...

I should mention I've seen the problem on both Ubuntu and Windows.

Anyhow, it doesn't sound like that is the problem that started this thread.

Michael McCool, Principal Engineer, Intel
SSG/DPD/Technology Pathfinding and Innovation

> On Oct 12, 2017, at 15:43, Mr C Camacho <[hidden email]> wrote:
>
> Can't speak for windows drivers but I've noticed little difference with previews on my desktop or laptop
> nvidia vs intel HD5500
>
> the whole issue is mute in any case the few times that this issue as caused actual problems (not being able
> to see into an object  I'm "boolean-ing" simply changing the size of whatever I'm subtracting by a very tiny
> amount gets rid of the issue entirely (I only tend to boolean 2 objects at a time, even if I need say 3 holes
> in something I just use successive operations)
>
> and as already pointed out a *preview* isn't intended to be perfect....
>
>> On 12/10/17 07:01, Michael McCool wrote:
>> In preview mode (F6) OpenSCAD is using a library that does CSG in the depth buffer of the graphics card using finite precision.  So even with not-quite coincident surfaces you may see this effect due to quantization.   Just remember it's a "preview" mode and not perfect.  If your model is correct when you compile it (which uses higher, in fact "infinite precision" arithmetic), don't worry about it.
>>
>> As a second note, the CSG preview library does not work well on non-NVIDIA GPUs.  In particular it does not work well on integrated Intel GPUs (unfortunately... see my signature).   As far as I know that is just a matter of people not debugging it for those GPUs.  Probably.
>>
>> Michael McCool, Principal Engineer, Intel
>> SSG/DPD/Technology Pathfinding and Innovation
>>
>>> On Oct 12, 2017, at 3:46, Linda Huxley <[hidden email]> wrote:
>>>
>>> I am well aware of the issue with rendering coincident surfaces, but I'm seeing crazing (that is areas of alternating colors covering a surface) when I don't actually have coincident surfaces.  I was hoping that someone could tell me if this is a known issue, or if I am doing something wrong.
>>>
>>> I've reduced the problem down to the following script:
>>>
>>> color("Green")
>>>    translate([2,2,0])
>>>        cube([98,98,1]);
>>> difference(convexity=4)
>>> {
>>>    translate([0,0,1])
>>>        cube([102,102,2]);
>>>    translate([1,1,0])
>>>        cube([100,100,4]);
>>> }
>>>
>>> Perhaps I'm doing something wrong, but the renderer appears to be rendering surfaces that should have been removed by the difference operator.
>>>
>>> Is there any way to avoid this issue without adjusting the elevation of one of the pieces?
>>>
>>> _______________________________________________
>>> 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
>
>
> _______________________________________________
> 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
|

Re: Unexpected Crazing on Coincident Surfaces

codifies
sorry to be clear I was talking about nvidia on my desktop vs intel
HG5500 on my laptop

I've use OpenSCAD mainly on my laptop for 3d printing work for quite
some time without issue...

talking more generally on Intel GPU's I'm a fan, open source robust
driver, enough grunt even
for immersive 3d game (okay you have to tone down all the effects!) but
whats not to love!

If it wasn't for the wife the desktop would be largely redundant...

shame about Intel ME..... but nothings perfect....


On 12/10/17 07:55, Michael McCool wrote:

> Regarding the issue with Intel GPUs, the problem may have been resolved with recent updates to Intel OpenGL drivers, Intel HW, or the OpenCSG library.  I sure hope so.  I'll have to try again.  My main interest in seeing this fixed is being able to use OpenSCAD on a laptop, although it's good to hear OpenCSG now works on Intel desktop GPUs.  As an aside, I haven't really tested on AMD GPUs...
>
> I should mention I've seen the problem on both Ubuntu and Windows.
>
> Anyhow, it doesn't sound like that is the problem that started this thread.
>
> Michael McCool, Principal Engineer, Intel
> SSG/DPD/Technology Pathfinding and Innovation
>
>> On Oct 12, 2017, at 15:43, Mr C Camacho <[hidden email]> wrote:
>>
>> Can't speak for windows drivers but I've noticed little difference with previews on my desktop or laptop
>> nvidia vs intel HD5500
>>
>> the whole issue is mute in any case the few times that this issue as caused actual problems (not being able
>> to see into an object  I'm "boolean-ing" simply changing the size of whatever I'm subtracting by a very tiny
>> amount gets rid of the issue entirely (I only tend to boolean 2 objects at a time, even if I need say 3 holes
>> in something I just use successive operations)
>>
>> and as already pointed out a *preview* isn't intended to be perfect....
>>
>>> On 12/10/17 07:01, Michael McCool wrote:
>>> In preview mode (F6) OpenSCAD is using a library that does CSG in the depth buffer of the graphics card using finite precision.  So even with not-quite coincident surfaces you may see this effect due to quantization.   Just remember it's a "preview" mode and not perfect.  If your model is correct when you compile it (which uses higher, in fact "infinite precision" arithmetic), don't worry about it.
>>>
>>> As a second note, the CSG preview library does not work well on non-NVIDIA GPUs.  In particular it does not work well on integrated Intel GPUs (unfortunately... see my signature).   As far as I know that is just a matter of people not debugging it for those GPUs.  Probably.
>>>
>>> Michael McCool, Principal Engineer, Intel
>>> SSG/DPD/Technology Pathfinding and Innovation
>>>
>>>> On Oct 12, 2017, at 3:46, Linda Huxley <[hidden email]> wrote:
>>>>
>>>> I am well aware of the issue with rendering coincident surfaces, but I'm seeing crazing (that is areas of alternating colors covering a surface) when I don't actually have coincident surfaces.  I was hoping that someone could tell me if this is a known issue, or if I am doing something wrong.
>>>>
>>>> I've reduced the problem down to the following script:
>>>>
>>>> color("Green")
>>>>     translate([2,2,0])
>>>>         cube([98,98,1]);
>>>> difference(convexity=4)
>>>> {
>>>>     translate([0,0,1])
>>>>         cube([102,102,2]);
>>>>     translate([1,1,0])
>>>>         cube([100,100,4]);
>>>> }
>>>>
>>>> Perhaps I'm doing something wrong, but the renderer appears to be rendering surfaces that should have been removed by the difference operator.
>>>>
>>>> Is there any way to avoid this issue without adjusting the elevation of one of the pieces?
>>>>
>>>> _______________________________________________
>>>> 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
>>
>> _______________________________________________
>> 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


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

Re: Unexpected Crazing on Coincident Surfaces

Huxley
In reply to this post by nophead
Thanks nop head,

The render trick worked.  That just saved me from a major rework.

Your description of render would certainly be a helpful addition to the
OpenSCAD user manual, which currently says "Needs description."

On 2017-10-11 13:39, nop head wrote:

> If you precede difference() with render() it solves the problem.
>
> OpenSCAD uses OpenCSG to draw the preview. That always draws all the
> objects, even the negative ones and doesn't cope with coincident
> surfaces. render() will calculate the actual geometry with CGAL so the
> common surface is removed.
>
> On 11 October 2017 at 19:46, Linda Huxley <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>     I am well aware of the issue with rendering coincident surfaces, but
>     I'm seeing crazing (that is areas of alternating colors covering a
>     surface) when I don't actually have coincident surfaces.  I was
>     hoping that someone could tell me if this is a known issue, or if I
>     am doing something wrong.
>
>     I've reduced the problem down to the following script:
>
>     color("Green")
>              translate([2,2,0])
>                      cube([98,98,1]);
>     difference(convexity=4)
>     {
>              translate([0,0,1])
>                      cube([102,102,2]);
>              translate([1,1,0])
>                      cube([100,100,4]);
>     }
>
>     Perhaps I'm doing something wrong, but the renderer appears to be
>     rendering surfaces that should have been removed by the difference
>     operator.
>
>     Is there any way to avoid this issue without adjusting the elevation
>     of one of the pieces?
>
>     _______________________________________________
>     OpenSCAD mailing list
>     [hidden email] <mailto:[hidden email]>
>     http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org <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
>

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