OpenSCAD snaps points to a grid. If the STL has points closer than the grid
spacing it will be corrupted on import.

On Thu, 6 Oct 2022 at 20:16, Raymond West raywest@raywest.com wrote:

Thanks,

If it snaps to a grid on import, i would hope it would snap to the same
grid when it generates the stl, too.

If it was not clear, what I was trying to say, I made a module to
generate a 3d shape , and I used the module twice, in a different
location. I then successfully exported that as cats.stl. I then imported
that, and could not f6 render the code below.

module cats(){
import("P:/Docs/openscad/cats.stl");
}
cats();
translate([500,0,0])cats();

'cats' is an stl generated by openscad. If I comment out the last line,
it renders. If I run it  'as is' there is no f6 render (messages as
quoted), but commented or not, f5 shows as should be. If, instead of the
translate 500, is there some other translate value that will work? I
will spend some more time, translate the same distance as in the
original cats.stl, see if that renders.

Perhaps may be easier to prove/disprove using a couple of cubes of
integer sides.

On 06/10/2022 20:39, nop head wrote:

Thanks,

If, maybe, sometimes. Not the sort of thing to be relied on, then.

In further testing, it works as I expected with cylinders or cubes, even
offsetting the translates by tiny amounts. But whatever triangles in the
stl are generated, they would be few and relatively large.

The cat was something I knocked together very quickly, just half a dozen
cylinders, a cone and a distorted sphere to represent the head, to show
my granddaughter. Now the cone and head would have small triangles where
they merge. I'll cut the head off, I expect it will render. (maybe
reducing $fn would sort it, too.)

It is not so much a problem, if the problem can be defined. It is
annoying when things/methods that have worked well before, come unstuck
because of some unknown factor

Best wishes,

Ray

PS I dismembered the cat, It still didn't work. I've attached the scad
file, which 'as is' will make a number of cylinders. If that is exported
as an stl named 'cats.stl', then you can run

module cats(){
import("P:/Docs/openscad/cats.stl"); //? your file
}
cats();
translate([500,0,0])cats();

as I mentioned before and it will not f6 for me. I may find out the
simplest stl that will not f6 when imported and translated.

Still doesn't solve my original lithopane quest, however.

Best wishes,

Ray

On 06/10/2022 21:29, Jordan Brown wrote:

The grid snap is a problem in OpenSCAD if you generate two vertices that
are closer than the snap distance. That is hard to avoid if you have two
curved surfaces meeting. For example unioning cylinders at an angle or
cones. While the geometry is in GGAL it is fine but as soon as it gets
converted to a Polyset it breaks. So exporting it to STL and importing it
again will break it and GCAL will complain if it has to operate on it. Also
if it gets cached as a Polyset it can break. Sometimes you have to flush
the cache before F6.

It is a long standing bug in OpenSCAD. If you snap a mesh to a grid you
have to mend the broken topology and that is hard.

Even without the grid snap the reduction in resolution when converting from
CGAL rationals to floating point can break the topology.

On Thu, 6 Oct 2022 at 22:22, Raymond West raywest@raywest.com wrote:

What was the non-dismembered cat.scad?

If their licences allow, drop a couple of your lithophane .STL's and I'll have a look at them.

First the error, CGAL is full of internal integrity checks on geometry.

They take the Garbage-in-Garbage-out approach seriously. You will see assertion violation, meaning the check failed.

99% of that will be an actually bad .STL or polyhedron (/gon). If you haven't worked out what bad is, lookup non-manifold & self-intersection.

<1% can be what nophead mentioned about the grid, I refer to it as the small number problem. I'll have a look when you post non-dismembered cat.

OpenSCAD has multiple forms of internal geometry, and depending on what you ask of it will use different libraries to process them.

If you have a single geometry (import or poly) it does not need to do CSG operations (union/intersection/difference) so CGAL is not called.

import-garbage-mesh -> export-garbage-mesh.

When you get two cats [or just add a cube(1)], even spaced apart, CGAL gets called to union them.

Only THEN are the CGAL internal checks performed, and if bad, gets the dreaded ERROR.

Additionally geometry is cached.

Unfortunately ATM if you had an ERROR, and do another F6, that bad section was cached, so CGAL does not get called a second time.

Thus you do not get a repeat of the ERROR. If you Design/Flush-caches then F6 will get the ERROR again.

As CGAL found the error, it did not produce any geometry, so it had nothing to display.

From: Raymond West [mailto:raywest@raywest.com]
Sent: Fri, 7 Oct 2022 07:20
To: OpenSCAD general discussion
Subject: [OpenSCAD] Re: error messages with 0penscad generated stl's.

Thanks,

If it snaps to a grid on import, i would hope it would snap to the same grid when it generates the stl, too.

If it was not clear, what I was trying to say, I made a module to generate a 3d shape , and I used the module twice, in a different location. I then successfully exported that as cats.stl. I then imported that, and could not f6 render the code below.

module cats(){
import("P:/Docs/openscad/cats.stl");
}
cats();
translate([500,0,0])cats();

'cats' is an stl generated by openscad. If I comment out the last line, it renders. If I run it  'as is' there is no f6 render (messages as quoted), but commented or not, f5 shows as should be. If, instead of the translate 500, is there some other translate value that will work? I will spend some more time, translate the same distance as in the original cats.stl, see if that renders.

Perhaps may be easier to prove/disprove using a couple of cubes of integer sides.

On 06/10/2022 20:39, nop head wrote:

OpenSCAD snaps points to a grid. If the STL has points closer than the grid spacing it will be corrupted on import.

So, I made a simple stl in openscad, loaded it and made two instances
and saved that as an stl. I can load that stl , but on duplicating that,
it would not render either - I had the following console error and
warning message.

Parsing design (AST generation)...

Saved backup file:
C:/Users/Ray/Documents/OpenSCAD/backups/unsaved-backup-LgmMliGJ.scad

Compiling design (CSG Tree generation)...

Rendering Polygon Mesh using CGAL...

ERROR: CGAL error in CGAL_Nef_polyhedron3(): CGAL ERROR: assertion
violation!

Expr: e_below != SHalfedge_handle()

File:
/mxe/usr/x86_64-w64-mingw32.static.posix/include/CGAL/Nef_3/SNC_FM_decorator.h

Line: 418

ERROR: CGAL error in CGAL_Nef_polyhedron3(): CGAL ERROR: assertion
violation!

Expr: e_below != SHalfedge_handle()

File:
/mxe/usr/x86_64-w64-mingw32.static.posix/include/CGAL/Nef_3/SNC_FM_decorator.h

Line: 418

WARNING: No top level geometry to render

On re-rendering again, I just had the warning message, but am i right in
thinking that the error message still applies? I sometimes find that
error messages sort of 'flash by' in the console.

What is the limit on the number of triangles in stl files that openscad
can handle, is it pc dependant? Is it possible that more
'understandable/explanatory error/warning messages (or even an error
number, and a more detailed explanation elsewhere) could be incorporated.

Best wishes,

Ray

ps, sorry about the colour change if it is present, and -OpenSCAD
https://www.openscad.org/version 2022.04.20.ci11719 (git 8238b8ccd)

OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org

OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org

--
This email has been checked for viruses by AVG antivirus software.
www.avg.com

Pretty large.
But the small number problem can happen with lots of tiny thin triangles, no so much the total
number, particularly if crowded into a small volume.
PC Memory eventually is the limitation, but the more faces the more CPU, depending on what
operation.
If you have plenty of memory it is worth increasing the cache sizes in Preferences.

Yes that is needed.
I just made the section in the wiki more prominent, but it probably needs a revamp:
https://en.wikibooks.org/w/index.php?title=OpenSCAD_User_Manual/Importing_Geometry&stable=0#import

--
This email has been checked for viruses by AVG antivirus software.
www.avg.com

On Thu, Oct 06, 2022 at 10:58:46PM +0100, nop head wrote:

My guess is that 99% of the brokenness is the zero-area-triangles that
occur when two points of a triangle snap to the same point. If you just delete
those on their way to geometry-processing, then you eliminate 99% of the
user-visible problems.

Current situation is that we're willing let the problem persist, why
not reduce the problem for the users? Currently we're victim-blaming
the users who give openscad an STL that is "faulty" in openscad's eyes.

How about a "scale=1.0"(*) extra argument to the import function? Another
workaround that shouldn't be too hard. Scale all numbers in the STL
so that the grid is relatively smaller. Should reduce some of the
problems. Scaling the model back will probably get you your problems back,
but as a workaround the user might output a 10x STL from openscad
and then scale it back in the slicer for instance.

Roger. 

(*) default is 1.0 to maintain compatibility with existing stuff.
recommendation is to try scale=10 when grid-snapping badness occurs.

--
** 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 down
your a is going up.  -- Chris Hadfield about flying up the space shuttle.

Maybe.
But 99% of the CGAL ERROR's I see here are bad STL's (actually bad*) or bad polygons.

• a large number of Thingivers STLs are faulty.

I'm not saying things can't be improved, but active developers are scarce ATM.

--
This email has been checked for viruses by AVG antivirus software.
www.avg.com