Negative ghosts

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

Negative ghosts

nophead
If I make an object using difference() or intersection() to remove
part of it then the object looks fine in opencsg but if I place it
next to another object such that the subtracted part is coincident
with the face of another object then the negative object becomes
visible. Is this a bug in opencsg or openscad?

Reply | Threaded
Open this post in threaded view
|

Re: Negative ghosts

Giles Bathgate-2

I think I know what you mean but an example scad script would still be good for reference.

On Sep 22, 2011 10:28 PM, "nop head" <[hidden email]> wrote:
> If I make an object using difference() or intersection() to remove
> part of it then the object looks fine in opencsg but if I place it
> next to another object such that the subtracted part is coincident
> with the face of another object then the negative object becomes
> visible. Is this a bug in opencsg or openscad?
> _______________________________________________
> OpenSCAD mailing list
> [hidden email]
> http://rocklinux.net/mailman/listinfo/openscad
Reply | Threaded
Open this post in threaded view
|

Re: Negative ghosts

Triffid Hunter
In reply to this post by nophead
I believe it's a side effect of abusing opengl Z-buffers to perform
difference operations. the objects render correctly with CGAL unless
an unrelated issue has also occurred.

Knowing that it's a z-buffer abuse issue doesn't suggest any quick fix to me.

On Fri, Sep 23, 2011 at 7:28 AM, nop head <[hidden email]> wrote:
> If I make an object using difference() or intersection() to remove
> part of it then the object looks fine in opencsg but if I place it
> next to another object such that the subtracted part is coincident
> with the face of another object then the negative object becomes
> visible. Is this a bug in opencsg or openscad?

Reply | Threaded
Open this post in threaded view
|

Re: Negative ghosts

William Adams
In reply to this post by Giles Bathgate-2
You can see the problem on this thing: http://www.thingiverse.com/thing:8661

Render the two halves at the exact same thickness.  Here it shows up by the color of the deleted part still being applied to the other piece.  I think it's actually a problem with OpenCSG.

-- William

===============================
- Shaping clay is easier than digging it out of the ground.


http://internationalwilliam.spaces.msn.com/



Date: Thu, 22 Sep 2011 22:33:49 +0100
From: [hidden email]
To: [hidden email]
Subject: Re: [OpenSCAD] Negative ghosts

I think I know what you mean but an example scad script would still be good for reference.
On Sep 22, 2011 10:28 PM, "nop head" <[hidden email]> wrote:
> If I make an object using difference() or intersection() to remove
> part of it then the object looks fine in opencsg but if I place it
> next to another object such that the subtracted part is coincident
> with the face of another object then the negative object becomes
> visible. Is this a bug in opencsg or openscad?
> _______________________________________________
> OpenSCAD mailing list
> [hidden email]
> http://rocklinux.net/mailman/listinfo/openscad

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

Re: Negative ghosts

nophead
Thanks, I tried to make a simple test case but I couldn't get it to
happen. It happens all the time in my models though. For example I
model a stepper motor with rounded corners by intersecting a cube with
a  cylinder. It looks fine on its own but if I draw it resting on a
surface I can see the shadow of the cylinder on the surface unless I
offset it slightly. The bodge factors I am adding get bigger and
bigger. I started with 0.01 but I am up to 0.03 in places now which is
approaching the accuracy of the print.

It does look like Z-buffer effects. I hadn't realised that is how
opencsg works. I am surprised it is so slow if it uses graphics
hardware. How does a few thousand primitives trouble a modern graphics
card? Surely it should do millions of triangles per second and
billions of pixels.

On 23 September 2011 02:29, William Adams <[hidden email]> wrote:

> You can see the problem on this thing: http://www.thingiverse.com/thing:8661
>
> Render the two halves at the exact same thickness.  Here it shows up by the
> color of the deleted part still being applied to the other piece.  I think
> it's actually a problem with OpenCSG.
>
> -- William
>
> ===============================
> - Shaping clay is easier than digging it out of the ground.
>
>
> http://internationalwilliam.spaces.msn.com/
>
>
> ________________________________
> Date: Thu, 22 Sep 2011 22:33:49 +0100
> From: [hidden email]
> To: [hidden email]
> Subject: Re: [OpenSCAD] Negative ghosts
>
> I think I know what you mean but an example scad script would still be good
> for reference.
> On Sep 22, 2011 10:28 PM, "nop head" <[hidden email]> wrote:
>> If I make an object using difference() or intersection() to remove
>> part of it then the object looks fine in opencsg but if I place it
>> next to another object such that the subtracted part is coincident
>> with the face of another object then the negative object becomes
>> visible. Is this a bug in opencsg or openscad?
>> _______________________________________________
>> OpenSCAD mailing list
>> [hidden email]
>> http://rocklinux.net/mailman/listinfo/openscad
>
> _______________________________________________ OpenSCAD mailing list
> [hidden email] http://rocklinux.net/mailman/listinfo/openscad
> _______________________________________________
> OpenSCAD mailing list
> [hidden email]
> http://rocklinux.net/mailman/listinfo/openscad
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Negative ghosts

kintel
Administrator
On Sep 23, 2011, at 20:07 PM, nop head wrote:

> It does look like Z-buffer effects. I hadn't realised that is how
> opencsg works. I am surprised it is so slow if it uses graphics
> hardware. How does a few thousand primitives trouble a modern graphics
> card? Surely it should do millions of triangles per second and
> billions of pixels.
>

Yep, this is an OpenCSG-related issue. The technical term for this is "Z buffer tearing".
There are ways to get around it, but in effect they all amount to knowing that you have two coincident surfaces and offsetting one if them either manually, or telling OpenGL to assume one is in front of the other. It might be possible to tweak some OpenGL code here and there to make this problem be less pronounced, but I haven't thought this through.

 -Marius



Reply | Threaded
Open this post in threaded view
|

Re: Negative ghosts

nophead
> Yep, this is an OpenCSG-related issue. The technical term for this is "Z buffer tearing".
> There are ways to get around it, but in effect they all amount to knowing that you have two coincident surfaces and offsetting one if them either manually, or telling OpenGL to assume one is in front of the other. It might be possible to tweak some OpenGL code here and there to make this problem be less pronounced, but I haven't thought this through.

Yes but there aren't any actually any coincident surfaces since the
negative object was subtracted and does not appear in the scene. It
does this even when there is a render() around the object. Doesn't
that use CGAL to compute the finished shape? Odd then that faces that
do not exist in that rendered shape can then show up in the OpenCSG
view.

Reply | Threaded
Open this post in threaded view
|

Re: Negative ghosts

Whosawhatsis
I'd be interested to see the code that still does this when you're
using render(). I've used it in the past to get rid of this effect.
The render() module will not get rid of it, of course, if the boolean
occurs outside it. That is, if you have one mesh that comes either
from CGAL through a render() statement or directly from a primitive or
primatives and another negative mesh (rendered or primitive) with a
coincident surface, the Z buffer tearing can still occur, but it
should not occur if they are both inside the same render() module. It
also should not occur with the surfaces of the negative portions of a
positive rendered mesh.

On Tue, Sep 27, 2011 at 11:22 AM, nop head <[hidden email]> wrote:

>> Yep, this is an OpenCSG-related issue. The technical term for this is "Z buffer tearing".
>> There are ways to get around it, but in effect they all amount to knowing that you have two coincident surfaces and offsetting one if them either manually, or telling OpenGL to assume one is in front of the other. It might be possible to tweak some OpenGL code here and there to make this problem be less pronounced, but I haven't thought this through.
>
> Yes but there aren't any actually any coincident surfaces since the
> negative object was subtracted and does not appear in the scene. It
> does this even when there is a render() around the object. Doesn't
> that use CGAL to compute the finished shape? Odd then that faces that
> do not exist in that rendered shape can then show up in the OpenCSG
> view.
> _______________________________________________
> OpenSCAD mailing list
> [hidden email]
> http://rocklinux.net/mailman/listinfo/openscad
>

Reply | Threaded
Open this post in threaded view
|

Re: Negative ghosts

kintel
Administrator
In reply to this post by nophead
On Sep 27, 2011, at 20:22 PM, nop head wrote:

> Yes but there aren't any actually any coincident surfaces since the
> negative object was subtracted and does not appear in the scene. It
> does this even when there is a render() around the object. Doesn't
> that use CGAL to compute the finished shape?

Yes, the render() statement uses CGAL to compute the geometry and there will thus be no geometry which can cause Z buffer tearing.
With OpenCSG, negative objects are rendered positive using a special rendering mode - that's why it shows up there.

On Sep 27, 2011, at 20:38 PM, Whosawhatsis wrote:

> I'd be interested to see the code that still does this when you're
> using render().

Me too - if that's the case, it sounds like a different issue.

 -Marius


Reply | Threaded
Open this post in threaded view
|

Re: Negative ghosts

kintel
Administrator
In reply to this post by nophead
On Sep 23, 2011, at 20:07 PM, nop head wrote:

> I am surprised it is so slow if it uses graphics
> hardware. How does a few thousand primitives trouble a modern graphics
> card? Surely it should do millions of triangles per second and
> billions of pixels.
>
Forgot about this - there are several causes for this:

Our rendering code is pretty naive and should be optimized. This is relatively high on my list

For OpenCSG to work correctly, the CSG graph has to be normalized, as described in this paper:
http://www.opencsg.org/data/csg_freenix2005_paper.pdf
This normalization can create huge chains of objects, and will significantly lower rendering performance.
I'm not intimately familiar with this, and it could be that it's possible to optimize this as well.

The creation of the CSG tree will in some cases use CGAL for computation - this causes the OpenCSG preview to require significant preprocessing. This doesn't inflict any penalty on the rendering itself though.

 -Marius


Reply | Threaded
Open this post in threaded view
|

Re: Negative ghosts

nophead
In reply to this post by kintel
On 27 September 2011 19:56, Marius Kintel <[hidden email]> wrote:

> On Sep 27, 2011, at 20:22 PM, nop head wrote:
>
>> Yes but there aren't any actually any coincident surfaces since the
>> negative object was subtracted and does not appear in the scene. It
>> does this even when there is a render() around the object. Doesn't
>> that use CGAL to compute the finished shape?
>
> Yes, the render() statement uses CGAL to compute the geometry and there will thus be no geometry which can cause Z buffer tearing.
> With OpenCSG, negative objects are rendered positive using a special rendering mode - that's why it shows up there.
>
> On Sep 27, 2011, at 20:38 PM, Whosawhatsis wrote:
>
>> I'd be interested to see the code that still does this when you're
>> using render().
>
> Me too - if that's the case, it sounds like a different issue.

My mistake. Render() does fix the problem.

>
>  -Marius
>
> _______________________________________________
> OpenSCAD mailing list
> [hidden email]
> http://rocklinux.net/mailman/listinfo/openscad
>