"mesh not closed" in stl when using default style_lip=0

[61a58e50be]

I noticed some inconsistencies when working with stls generated by this lib. I was able to trace the cause back to the default style_lip=0. The problem does not appear when style_lip=1 is used.

Steps to reproduce:

1. render the default gridfinity-rebuilt-bins.scad from main branch - save as gridfinity-rebuilt-bins-default.stl
2. only change style_lip=1 - render & save as gridfinity-rebuilt-bins-style_lip_1.stl
3. use the minimal working sample code below to trigger either the error ERROR: The given mesh is not closed! Unable to convert to CGAL_Nef_Polyhedron. and/or don't get any output in openscad's 3d viewer.

working as expected:

difference(){
    import("./gridfinity-rebuilt-bins-style_lip_1.stl");
    cube([25,25,100], center=true);
}

does not work:

difference(){
    import("./gridfinity-rebuilt-bins-default.stl");
    cube([25,25,100], center=true);
}

[kennetek]

Interesting, I cannot replicate this error. I am using 2022.11.13.ci12787, a development snapshot with fast-csg enabled. I guess it must not work properly in the stable release of OpenSCAD. I honestly do not know how to fix that.

[61a58e50be]

I can confirm that when using with the latest development snapshot (2023.01.23) I also was able to successfully follow the steps without error. However, I'm even more stumped now because in the process of upgrading I tried a lot of combinations and the only one working was using fast-csg for both render steps. What bothers me is that when rendering the bin with v2023.01.23 WITHOUT fast-csg, I ran into the same error. However, the resulting .stl files are the same (as in same md5 sum) and somehow, there is still a difference for OpenSCAD.

using the stl rendered without fast-csg:

using the stl rendered with fast-csg

both stls are the same:

$>md5sum gridfinity-rebuilt-bins-default-2023.01.23*
55d410df333b852752e7566a7d582d07  gridfinity-rebuilt-bins-default-2023.01.23-fast_csg.stl
55d410df333b852752e7566a7d582d07  gridfinity-rebuilt-bins-default-2023.01.23.stl

I don't know how this should be caused this library or even the stl. Especially getting different results with two identical stls seems to me like this might rather be an OpenSCAD problem. Thanks for trying to reproduce the issue - I believe we can close this here since I also have no idea, how this should be caused by this library.