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

STL were never designed to be an editable format, when is says "Export STL" it means this is a one direction journey. Got that? If you desire to try to reverse this you do it at your own peril.

OpenSCAD exports STL, it does not expect to import them error free (its own STL, or anybody elses for that matter, the fact it bothers to import them at all is just due a generous gesture by the openSCAD developers) due to the inherent imprecise data structures of STLs. Fortunately for the 3D printers slicers the errors are "ironed out". Editting them is another matter entirely. Just consider yourselves lucky you have anything.
Cheers, RobW

On 7 October 2022 7:29:39 am AEDT, Jordan Brown openscad@jordan.maileater.net wrote:

I actually had a go at fixing the grid snap myself a few years ago. I fixed
the degenerate triangles but that didn't fix the issue because a lot of the
problems are self intersections, so I gave up. Basically if you have a
sharp edge then vertices from different faces can snap together creating a
self intersection. Also very thin triangles can snap one vertex one way and
another another way such that its winding order gets flipped.

I don't know any free tools that will fix self intersections. The free
version of NetFabb studio detects them but you need a paid version to fix
them.

On Fri, 7 Oct 2022 at 10:48, Rob Ward rl.ward@bigpond.com wrote:

On 2022-10-07 11:48, Rob Ward wrote:

Pretty much correct. As I have pointed out more than once, STL is not
suitable for import because it does not include any topology, but this
statement is ignored so the problem comes up again and again. The
topology must be guessed by the importing program and that process is
likely to fail for STL in many cases. Also, OpenSCAD makes some
decisions on import that causes further problems.

That STL "does not include any topology" means that STL is just a
"triangle soup". There is no explicit information about which triangles
are connected to which other triangles. Said differently: there are no
shared vertices even though this is essential information.

OpenSCAD supports import of OFF files. Unlike STL, the OFF format
contains explicit information about shared vertices. Therefore OFF is a
much better choice than STL for import. If you can control the format of
the exported file, choose OFF over STL.

If all you have is STL, you are essentially out of luck, but you can try
one of the repair programs and save the result to OFF and import that in
OpenSCAD. It may or may not work. One such repair program is polyfix,
part of AngelCAD
https://github.com/arnholm/angelcad/releases/tag/V1.5-06

Carsten Arnholm

On 10/7/22 05:50, Rob Ward wrote:

Lets look at this from a different angle. Is there a format we CAN
export to Cura or one of the other slicers, that IS
recoverable by re-importing it into OpenSCAD?

If there is such a 2-way path, we who feed 3d printers from OpenSCAD
should be using it as a backup recovery.
Kudo's and huge thank you's if it gives back editable text,

Take care & stay well everybody.

Cheers, Gene Heskett.

"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law respectable.

• Louis D. Brandeis
  Genes Web page http://geneslinuxbox.net:6309/

OpenSCAD uses an internal representation called a PolySet that is just a
polygon soup, no better than STLs except it uses doubles but snaps them to
a grid.

STLs import fine if they have a valid mesh that doesn't self intersect and
doesn't have vertices closer than the snap grid.

On Fri, 7 Oct 2022 at 17:05, gene heskett gheskett@shentel.net wrote:

Thanks for all the suggestions.

Openscad will export both off and obj format files, but will not import
obj format, 'as is' . However, the contents/layout of each are similar
enough to be able to convert one to the other, if the obj only includes
vertices and faces. Cura does not import or export off files, but can
generate obj's from stl's . In my brief testing, the cura produced obj's
do not include anything other the v and f's. I can check that out.

Plenty of things to try out. I am not expecting much of an improvement,
but I think there is a better chance that errors can be
detected/corrected in a polyhedron, compared to an stl.

Initially a handcranked conversion should be easy with a text editor
that counts lines,

If the problematic stl's will have errors corrected within cura, then
that would be useful.

On 07/10/2022 15:45, arnholm@arnholm.org wrote:

On Fri, Oct 7, 2022 at 12:12 nop head nop.head@gmail.com wrote:

Say no more…

-Kenneth Sloan

On 10/7/22 12:13, nop head wrote:

I take it your answer was to me, but that does not give back an editable
file. Something you can easily add a
missing nut pocket to use a for instance.

Take care & stay well.

Cheers, Gene Heskett.

"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law respectable.

• Louis D. Brandeis
  Genes Web page http://geneslinuxbox.net:6309/

When OpenSCAD generates geometry it is just a mesh, all the geometric
information is lost even before it is saved to STL or OBJ, etc.

On Sat, 8 Oct 2022 at 01:19, gene heskett gheskett@shentel.net wrote:

I tried again, the next morning, and it imported fine. This was in a new
instance of openscad. It has been pointed out to me to 'flush the
cache'. Starting afresh does that, of course.

So, it seems that objects generated and exported by openscad can be
imported and manipulated, which was as I had expected provided I
remember to flush the cache, if it's towards the end of a lengthy session.

However, repeating the situation a number of times, I expect it could be
like photocopying photocopies - either ends up all black or all white.

On 06/10/2022 22:22, Raymond West wrote: