RW
Rob Ward
Fri, Oct 7, 2022 9:48 AM
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:
There are two components to your problem.
1) OpenSCAD doesn't always like to import its own output.
Not much that I can say about this. It seems pretty wrong, but I am
sure there are reasons why fixing it is hard. I haven't looked.
2) OpenSCAD's behavior in the face of importing STLs that it does not
like is ... strange.
If you have an STL (or, for that matter, a polyhedron()) that isn't
quite right, OpenSCAD will do one of three things:
- F5 - will probably work, because it doesn't actually analyze the
geometry.
- F6 of the troublesome object alone - will probably work, because
analyzing the geometry is somehow optimized away.
- F6 of the troublesome object in conjunction with anything else -
analyzes the geometry and fails.
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:
>There are two components to your problem.
>
>1) OpenSCAD doesn't always like to import its own output.
>
>Not much that I can say about this. It seems pretty wrong, but I am
>sure there are reasons why fixing it is hard. I haven't looked.
>
>2) OpenSCAD's behavior in the face of importing STLs that it does not
>like is ... strange.
>
>If you have an STL (or, for that matter, a polyhedron()) that isn't
>quite right, OpenSCAD will do one of three things:
>
> * F5 - will probably work, because it doesn't actually analyze the
> geometry.
> * F6 of the troublesome object alone - will probably work, because
> analyzing the geometry is somehow optimized away.
> * F6 of the troublesome object in conjunction with anything else -
> analyzes the geometry and fails.
>
NH
nop head
Fri, Oct 7, 2022 10:03 AM
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:
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:
There are two components to your problem.
- OpenSCAD doesn't always like to import its own output.
Not much that I can say about this. It seems pretty wrong, but I am sure
there are reasons why fixing it is hard. I haven't looked.
- OpenSCAD's behavior in the face of importing STLs that it does not
like is ... strange.
If you have an STL (or, for that matter, a polyhedron()) that isn't quite
right, OpenSCAD will do one of three things:
- F5 - will probably work, because it doesn't actually analyze the
geometry.
- F6 of the troublesome object alone - will probably work, because
analyzing the geometry is somehow optimized away.
- F6 of the troublesome object in conjunction with anything else -
analyzes the geometry and fails.
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:
> 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:
>>
>> There are two components to your problem.
>>
>> 1) OpenSCAD doesn't always like to import its own output.
>>
>> Not much that I can say about this. It seems pretty wrong, but I am sure
>> there are reasons why fixing it is hard. I haven't looked.
>>
>> 2) OpenSCAD's behavior in the face of importing STLs that it does not
>> like is ... strange.
>>
>> If you have an STL (or, for that matter, a polyhedron()) that isn't quite
>> right, OpenSCAD will do one of three things:
>>
>> - F5 - will probably work, because it doesn't actually analyze the
>> geometry.
>> - F6 of the troublesome object alone - will probably work, because
>> analyzing the geometry is somehow optimized away.
>> - F6 of the troublesome object in conjunction with anything else -
>> analyzes the geometry and fails.
>>
>>
>> _______________________________________________
> OpenSCAD mailing list
> To unsubscribe send an email to discuss-leave@lists.openscad.org
>
A
arnholm@arnholm.org
Fri, Oct 7, 2022 2:45 PM
On 2022-10-07 11:48, Rob Ward wrote:
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.
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 2022-10-07 11:48, Rob Ward wrote:
> 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.
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
GH
gene heskett
Fri, Oct 7, 2022 4:04 PM
On 10/7/22 05:50, Rob Ward wrote:
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:
There are two components to your problem.
1) OpenSCAD doesn't always like to import its own output.
Not much that I can say about this. It seems pretty wrong, but I am
sure there are reasons why fixing it is hard. I haven't looked.
2) OpenSCAD's behavior in the face of importing STLs that it does not
like is ... strange.
If you have an STL (or, for that matter, a polyhedron()) that isn't
quite right, OpenSCAD will do one of three things:
- F5 - will probably work, because it doesn't actually analyze the
geometry.
- F6 of the troublesome object alone - will probably work, because
analyzing the geometry is somehow optimized away.
- F6 of the troublesome object in conjunction with anything else -
analyzes the geometry and fails.
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.
On 10/7/22 05:50, Rob Ward wrote:
> 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:
>> There are two components to your problem.
>>
>> 1) OpenSCAD doesn't always like to import its own output.
>>
>> Not much that I can say about this. It seems pretty wrong, but I am
>> sure there are reasons why fixing it is hard. I haven't looked.
>>
>> 2) OpenSCAD's behavior in the face of importing STLs that it does not
>> like is ... strange.
>>
>> If you have an STL (or, for that matter, a polyhedron()) that isn't
>> quite right, OpenSCAD will do one of three things:
>>
>> * F5 - will probably work, because it doesn't actually analyze the
>> geometry.
>> * F6 of the troublesome object alone - will probably work, because
>> analyzing the geometry is somehow optimized away.
>> * F6 of the troublesome object in conjunction with anything else -
>> analyzes the geometry and fails.
>>
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/>
NH
nop head
Fri, Oct 7, 2022 4:11 PM
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:
On 10/7/22 05:50, Rob Ward wrote:
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 <
There are two components to your problem.
- OpenSCAD doesn't always like to import its own output.
Not much that I can say about this. It seems pretty wrong, but I am
sure there are reasons why fixing it is hard. I haven't looked.
- OpenSCAD's behavior in the face of importing STLs that it does not
like is ... strange.
If you have an STL (or, for that matter, a polyhedron()) that isn't
quite right, OpenSCAD will do one of three things:
- F5 - will probably work, because it doesn't actually analyze the
geometry.
- F6 of the troublesome object alone - will probably work, because
analyzing the geometry is somehow optimized away.
- F6 of the troublesome object in conjunction with anything else -
analyzes the geometry and fails.
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.
OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org
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:
> On 10/7/22 05:50, Rob Ward wrote:
> > 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:
> >> There are two components to your problem.
> >>
> >> 1) OpenSCAD doesn't always like to import its own output.
> >>
> >> Not much that I can say about this. It seems pretty wrong, but I am
> >> sure there are reasons why fixing it is hard. I haven't looked.
> >>
> >> 2) OpenSCAD's behavior in the face of importing STLs that it does not
> >> like is ... strange.
> >>
> >> If you have an STL (or, for that matter, a polyhedron()) that isn't
> >> quite right, OpenSCAD will do one of three things:
> >>
> >> * F5 - will probably work, because it doesn't actually analyze the
> >> geometry.
> >> * F6 of the troublesome object alone - will probably work, because
> >> analyzing the geometry is somehow optimized away.
> >> * F6 of the troublesome object in conjunction with anything else -
> >> analyzes the geometry and fails.
> >>
> 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 mailing list
> To unsubscribe send an email to discuss-leave@lists.openscad.org
>
RW
Raymond West
Fri, Oct 7, 2022 4:15 PM
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 2022-10-07 11:48, Rob Ward wrote:
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.
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
OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org
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 2022-10-07 11:48, Rob Ward wrote:
>> 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.
>
> 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
> _______________________________________________
> OpenSCAD mailing list
> To unsubscribe send an email to discuss-leave@lists.openscad.org
KR
Kenneth R Sloan
Fri, Oct 7, 2022 4:20 PM
OpenSCAD uses an internal representation called a PolySet that is just a
polygon soup,
On Fri, Oct 7, 2022 at 12:12 nop head <nop.head@gmail.com> wrote:
> OpenSCAD uses an internal representation called a PolySet that is just a
> polygon soup,
>
Say no more…
> --
-Kenneth Sloan
GH
gene heskett
Sat, Oct 8, 2022 12:18 AM
On 10/7/22 12:13, nop head wrote:
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:
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.
On 10/7/22 12:13, nop head wrote:
> 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:
>
>
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/>
NH
nop head
Sat, Oct 8, 2022 9:39 AM
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:
On 10/7/22 12:13, nop head wrote:
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
a grid.
STLs import fine if they have a valid mesh that doesn't self intersect
doesn't have vertices closer than the snap grid.
On Fri, 7 Oct 2022 at 17:05, gene heskett gheskett@shentel.net 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.
OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org
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:
> On 10/7/22 12:13, nop head wrote:
> > 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:
> >
> >
> 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/>
> _______________________________________________
> OpenSCAD mailing list
> To unsubscribe send an email to discuss-leave@lists.openscad.org
>
RW
Ray West
Sun, Oct 9, 2022 10:52 AM
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:
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:
There are two components to your problem.
1) OpenSCAD doesn't always like to import its own output.
Not much that I can say about this. It seems pretty wrong, but I am
sure there are reasons why fixing it is hard. I haven't looked.
2) OpenSCAD's behavior in the face of importing STLs that it does
not like is ... strange.
If you have an STL (or, for that matter, a polyhedron()) that isn't
quite right, OpenSCAD will do one of three things:
- F5 - will probably work, because it doesn't actually analyze the
geometry.
- F6 of the troublesome object alone - will probably work, because
analyzing the geometry is somehow optimized away.
- F6 of the troublesome object in conjunction with anything else -
analyzes the geometry and fails.
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:
>
> 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:
>> There are two components to your problem.
>>
>> 1) OpenSCAD doesn't always like to import its own output.
>>
>> Not much that I can say about this. It seems pretty wrong, but I am
>> sure there are reasons why fixing it is hard. I haven't looked.
>>
>> 2) OpenSCAD's behavior in the face of importing STLs that it does
>> not like is ... strange.
>>
>> If you have an STL (or, for that matter, a polyhedron()) that isn't
>> quite right, OpenSCAD will do one of three things:
>>
>> * F5 - will probably work, because it doesn't actually analyze the
>> geometry.
>> * F6 of the troublesome object alone - will probably work, because
>> analyzing the geometry is somehow optimized away.
>> * F6 of the troublesome object in conjunction with anything else -
>> analyzes the geometry and fails.
>>
>>
>
> _______________________________________________
> OpenSCAD mailing list
> To unsubscribe send an email todiscuss-leave@lists.openscad.org
