I build everething with a tolerance of 0.01 where i add or subtract the tolarance accordingly when drawing diferances, but i never found a solution to the close to view problem.Its usfull to no it only does it in perspective view though, i never noticed that before.Sent via the Samsung Galaxy S7, an AT&T 4G LTE smartphone
-------- Original message --------From: Rogier Wolff R.E.Wolff@BitWizard.nl Date: 12/22/22  1:22 PM  (GMT+00:00) To: OpenSCAD general discussion Mailing-list discuss@lists.openscad.org Subject: [OpenSCAD] Re: preview difference() glitch On Tue, Dec 20, 2022 at 04:42:26PM +0000, nop head wrote:> Yes, OpenCSG is used to draw the preview without calculating any of the> geometry. It just draws all the primitive objects with different graphics> modes.What it boils down to is that most people don't understand how say "acube" ends up on the screen. A quick computer graphics lesson:Let us work towards the situation where we put: difference () {cube (10);translate ([5,5,5]) cube (10);} on the screen. But first lets do the first cube only. In practice, these things often only work on triangles, Not sure ifnowadays that's still true, but for now lets pretend we can work withsquares too.The cube has 6 faces. For each face, we first compare the normal tothe viewing vector. If it is facing away from the camera(i.e. anglebetween them is less than 90 degrees), we can ignore it.This leaves us with just three faces we need to draw. We transform thecube's coorinates to screen coordinates and simply draw the pixelsinside the quadrilaterals with the proper color depending on the anglebetween the normal, viewing angle and the light source.Now if we want to draw a second cube (not a difference, like above,but a union), things get a bit fishy: Depending on the drawing orderyou get to see faces that should be obscured by the othercube. So... for each pixel, we calculate the distance from the viewingplane and store that together with the color of the pixel.Now while drawing a pixel instead of just drawing it, we compare thedepth value. If the current depth value is further away than what'salready drawn, we ignore this pixel of this face, otherwise we draw asnormal and update the depth value.Now you can pretty quickly get a reasonable preview for multipleobjects combined.But how to draw the difference?  For the "negative" cube in my examplecase we need to turn things around: We ignore faces pointing towardsus, and draw faces pointing away from us. Also the depth rule turnsaround: We only draw pixels that are DEEPER than the pixel alreadydrawn.Now this is going to be "messy" to implement. Corner cases everywhereand things like that, but this is the principle. All in all, this isthe X billion pixels per second that graphics cards claim to be ableto handle. So this also includes all the pixels that do NOT end up onyour screen.It also explains the Z-fighting that you sometimes see: Two planesin theory at precisely the same depth so it depends on floating pointrounding errors if one is in front of the other or not. Roger. -- ** R.E.Wolff@BitWizard.nl ** https://www.BitWizard.nl/ ** +31-15-2049110 ****    Delftechpark 11 2628 XJ  Delft, The Netherlands.  KVK: 27239233    **f equals m times a. When your f is steady, and your m is going downyour a is going up.  -- Chris Hadfield about flying up the space shuttle._______________________________________________OpenSCAD mailing listTo unsubscribe send an email to discuss-leave@lists.openscad.org

Would i be correct in saying that the Preview is rendered by the underlying graphics library on the GPU and the Render is renderd by openscad on the GPU?Sent via the Samsung Galaxy S7, an AT&T 4G LTE smartphone
-------- Original message --------From: Rogier Wolff R.E.Wolff@BitWizard.nl Date: 12/22/22  1:22 PM  (GMT+00:00) To: OpenSCAD general discussion Mailing-list discuss@lists.openscad.org Subject: [OpenSCAD] Re: preview difference() glitch On Tue, Dec 20, 2022 at 04:42:26PM +0000, nop head wrote:> Yes, OpenCSG is used to draw the preview without calculating any of the> geometry. It just draws all the primitive objects with different graphics> modes.What it boils down to is that most people don't understand how say "acube" ends up on the screen. A quick computer graphics lesson:Let us work towards the situation where we put: difference () {cube (10);translate ([5,5,5]) cube (10);} on the screen. But first lets do the first cube only. In practice, these things often only work on triangles, Not sure ifnowadays that's still true, but for now lets pretend we can work withsquares too.The cube has 6 faces. For each face, we first compare the normal tothe viewing vector. If it is facing away from the camera(i.e. anglebetween them is less than 90 degrees), we can ignore it.This leaves us with just three faces we need to draw. We transform thecube's coorinates to screen coordinates and simply draw the pixelsinside the quadrilaterals with the proper color depending on the anglebetween the normal, viewing angle and the light source.Now if we want to draw a second cube (not a difference, like above,but a union), things get a bit fishy: Depending on the drawing orderyou get to see faces that should be obscured by the othercube. So... for each pixel, we calculate the distance from the viewingplane and store that together with the color of the pixel.Now while drawing a pixel instead of just drawing it, we compare thedepth value. If the current depth value is further away than what'salready drawn, we ignore this pixel of this face, otherwise we draw asnormal and update the depth value.Now you can pretty quickly get a reasonable preview for multipleobjects combined.But how to draw the difference?  For the "negative" cube in my examplecase we need to turn things around: We ignore faces pointing towardsus, and draw faces pointing away from us. Also the depth rule turnsaround: We only draw pixels that are DEEPER than the pixel alreadydrawn.Now this is going to be "messy" to implement. Corner cases everywhereand things like that, but this is the principle. All in all, this isthe X billion pixels per second that graphics cards claim to be ableto handle. So this also includes all the pixels that do NOT end up onyour screen.It also explains the Z-fighting that you sometimes see: Two planesin theory at precisely the same depth so it depends on floating pointrounding errors if one is in front of the other or not. Roger. -- ** R.E.Wolff@BitWizard.nl ** https://www.BitWizard.nl/ ** +31-15-2049110 ****    Delftechpark 11 2628 XJ  Delft, The Netherlands.  KVK: 27239233    **f equals m times a. When your f is steady, and your m is going downyour a is going up.  -- Chris Hadfield about flying up the space shuttle._______________________________________________OpenSCAD mailing listTo unsubscribe send an email to discuss-leave@lists.openscad.org

Typo sorry. Try that againWould i be correct in saying that the Preview is rendered by the underlying graphics library on the GPU and the Render is renderd by openscad on the CPU?Sent via the Samsung Galaxy S7, an AT&T 4G LTE smartphone
-------- Original message --------From: Rogier Wolff R.E.Wolff@BitWizard.nl Date: 12/22/22  1:22 PM  (GMT+00:00) To: OpenSCAD general discussion Mailing-list discuss@lists.openscad.org Subject: [OpenSCAD] Re: preview difference() glitch On Tue, Dec 20, 2022 at 04:42:26PM +0000, nop head wrote:> Yes, OpenCSG is used to draw the preview without calculating any of the> geometry. It just draws all the primitive objects with different graphics> modes.What it boils down to is that most people don't understand how say "acube" ends up on the screen. A quick computer graphics lesson:Let us work towards the situation where we put: difference () {cube (10);translate ([5,5,5]) cube (10);} on the screen. But first lets do the first cube only. In practice, these things often only work on triangles, Not sure ifnowadays that's still true, but for now lets pretend we can work withsquares too.The cube has 6 faces. For each face, we first compare the normal tothe viewing vector. If it is facing away from the camera(i.e. anglebetween them is less than 90 degrees), we can ignore it.This leaves us with just three faces we need to draw. We transform thecube's coorinates to screen coordinates and simply draw the pixelsinside the quadrilaterals with the proper color depending on the anglebetween the normal, viewing angle and the light source.Now if we want to draw a second cube (not a difference, like above,but a union), things get a bit fishy: Depending on the drawing orderyou get to see faces that should be obscured by the othercube. So... for each pixel, we calculate the distance from the viewingplane and store that together with the color of the pixel.Now while drawing a pixel instead of just drawing it, we compare thedepth value. If the current depth value is further away than what'salready drawn, we ignore this pixel of this face, otherwise we draw asnormal and update the depth value.Now you can pretty quickly get a reasonable preview for multipleobjects combined.But how to draw the difference?  For the "negative" cube in my examplecase we need to turn things around: We ignore faces pointing towardsus, and draw faces pointing away from us. Also the depth rule turnsaround: We only draw pixels that are DEEPER than the pixel alreadydrawn.Now this is going to be "messy" to implement. Corner cases everywhereand things like that, but this is the principle. All in all, this isthe X billion pixels per second that graphics cards claim to be ableto handle. So this also includes all the pixels that do NOT end up onyour screen.It also explains the Z-fighting that you sometimes see: Two planesin theory at precisely the same depth so it depends on floating pointrounding errors if one is in front of the other or not. Roger. -- ** R.E.Wolff@BitWizard.nl ** https://www.BitWizard.nl/ ** +31-15-2049110 ****    Delftechpark 11 2628 XJ  Delft, The Netherlands.  KVK: 27239233    **f equals m times a. When your f is steady, and your m is going downyour a is going up.  -- Chris Hadfield about flying up the space shuttle._______________________________________________OpenSCAD mailing listTo unsubscribe send an email to discuss-leave@lists.openscad.org

Yeah, I don't think you ever need to make it conditional, and usually
you don't have to make it particularly small either.

Just make the negative and intersecting objects a little bigger in the
appropriate axes, so that they protrude beyond the object that remains.
  I use +1, and for a hole that goes all the way through use *3 and center.

a = 5;
b = a*2;

difference() {
    cube(b);
    #translate([a,a,a]) cylinder(h=a+1, d=a);
}

translate([20,0,0]) {
    intersection() {
        cylinder(h=b, d=b);
        #translate([0,-a-1,-1])
            cube([a+1, b+2, b+2]);
    }
}

translate([30,0,0]) {
    difference() {
        cube(b);
        #translate([a,a,0])
            cylinder(h=b*3, d=a, center=true);
    }
}

What's harder is if you want to make things be multiple colors, because
then you're dealing with surfaces that are supposed to be visible.