Ovals

classic Classic list List threaded Threaded
31 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Re: Ovals

shadowwynd
In the past I have used TinkerCAD to help with problematic models that don't open in OpenScad.  Open the model in tinkercad, make a tiny change (union with a small sphere) then export as a new STL.  Some of the files are produced this way I have been more palatable to openscad.

On Sep 5, 2018, at 11:47 AM, nop head <[hidden email]> wrote:

>But a render, which you would think uses the same process fails.

No preview is a totally different process to render. Preview just draws all the triangles in the correct order to show a pixel representation of the object. render calculates the geometry if there are any CSG ops (including the implict union) and then draws that. It uses the GCAL library and that expects it to be 2-manifold, without degenerate triangles.

I have never had much success with other people's STLs for 3D printing. Even if they are manifold they are often not correct for 3D printing on my machines. I mostly design everything I print from scratch in OpenSCAD.

On 5 September 2018 at 16:28, FourthDr <[hidden email]> wrote:
NopHead:

You've mentioned OpenSCAD's grid a few times before. But is that actually
documented anywhere? For example, if the designer of a model was made aware
that any export to stl needed to have triangles of a specific maximum size
there would be one less problem to deal with.

That is exactly what's needed, guide lines. Any shared stl should have the
following traits. Right now you have no idea what program the stl was
originally exported from or what settings where used.

If some one could document exact minimum traits an stl file needs to be
successfully imported, manipulated, and then exported from OpenSCAD that
would be very helpful.



--
Sent from: http://forum.openscad.org/

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: Ovals

cacb
In reply to this post by christophe malvasio
> Le mer. 5 sept. 2018 à 03:03, FourthDr <[hidden email]> a écrit :
>> I'm trying to get these two attached stl files split by tomorrow. I've been
>> tinkering with them for months. So far without success. Any one interested
>> in seeing if they can find and correct the two files for me? And maybe give
>> some tips and or suggest some software tools I have not already tried?
>> Cryptic CGAL errors don't really help me find and fix what OpenSCAD is
>> complaining about.
>>
>> back-cover-no-stand-2.stl
>> <http://forum.openscad.org/file/t1425/back-cover-no-stand-2.stl>
>> _LCD_face_plate_LCD_hole_open_(repaired).stl
>> <http://forum.openscad.org/file/t1425/_LCD_face_plate_LCD_hole_open_%28repaired%29.stl>
>> puzzlecutlib3.scad <http://forum.openscad.org/file/t1425/puzzlecutlib3.scad>
>>
>> Thanks for all the help.

For the fun of it, I checked your files in my own tool. The first one
(back-cover-no-stand-2.stl) reports no problems.

The second "repaired" _LCD_face_plate... reports numerous problems and a
fix is attempted (seems better although not 100% clean)

Here is a link to the fixed file (link will expire in 2 days). I don't
know if it works any better than what you had, but you can try.
https://www.expirebox.com/download/050b8ca1679fcea5bfa17ea49aa6fc21.html

What is reported is for example
- many collapsed/zero area faces
- many duplicated faces
- many non-manifold faces

It should be said that STL contains zero topology, so any claim of
non-manifoldness is a subjective interpretation of the data. For
exchanging between applications if would have been better to use a
format with explicit topology e.g. Wavefront OBJ. But STL is indeed very
common with all its issues.

Below is the log from my tool showing iterative attempts to fix your
file. The approach taken when interpreting the STL is quite different
from OpenSCADs "grid" approach so the result is likely not going to be
the same, but perhaps OpenSCAD likes the result better.

In iteration 0, the STL "polygon soup" is read. The high number of
initial non-manifold edges is normal for STL since it is a polygon soup
with no connectivity at all. From iteration 1, connectivity is
interpreted by merging vertices (with distance < dtol), and thus the
number of non-manifold edges is much reduced.

The vertex merging process leaves some zero area faces (with area <
atol) that are subsequently removed. Also, duplicate faces are removed.
After 6 iterations the only remaining issues are a few non-manifold
edges remain which cannot easily be resolved.

However, the resulting file is likely more usable in other programs,
maybe also in OpenSCAD. I could not test it in OpenSCAD since I am on
Kubuntu 18.04 and apparently there is no usable binary for 18.04.

------
Parameters:
   input_file = _LCD_face_plate_LCD_hole_open_(repaired).stl


polyhedron 0 ================= volume=35242.9, dtol=0.01, atol=1e-06,
maxiter=10
iteration 0: vertices=43758 faces=14586
              warning: 1 zero area faces.
              warning: nonmanifold edges: uc(1)=43758
              merged 38113 vertices
              removed 2612 collapsed or zero area faces
              split 32 faces
              removed 366 duplicate faces
              removed 161 nonmanifold faces
              removed 29 zero area faces
              total changes=41313
              warning: nonmanifold edges: uc(1)=61 uc(3)=71 uc(4)=57
uc(5)=1

 
 

iteration 1: vertices=5645 faces=11515
 

              warning: nonmanifold edges: uc(1)=61 uc(3)=71 uc(4)=57
uc(5)=1

              removed 6 unused vertices
 

              merged 434 vertices
 

              removed 790 collapsed or zero area faces
 

              split 8 faces
 

              removed 145 duplicate faces
 

              removed 71 nonmanifold faces
 

              removed 8 zero area faces
 

              total changes=1462
 

              warning: nonmanifold edges: uc(1)=26 uc(3)=27 uc(4)=37
uc(6)=1 uc(7)=1

 
 

iteration 2: vertices=5205 faces=10514
 

              warning: nonmanifold edges: uc(1)=26 uc(3)=27 uc(4)=37
uc(6)=1 uc(7)=1
              removed 5 unused vertices
              merged 114 vertices
              removed 227 collapsed or zero area faces
              split 2 faces
              removed 42 duplicate faces
              removed 30 nonmanifold faces
              removed 4 zero area faces
              total changes=424
              warning: nonmanifold edges: uc(1)=9 uc(3)=6 uc(4)=19

iteration 3: vertices=5086 faces=10213
              warning: nonmanifold edges: uc(1)=9 uc(3)=6 uc(4)=19
              removed 4 unused vertices
              merged 19 vertices
              removed 40 collapsed or zero area faces
              split 6 faces
              removed 5 duplicate faces
              removed 2 nonmanifold faces
              removed 6 zero area faces
              total changes=82
              warning: nonmanifold edges: uc(1)=4 uc(3)=12 uc(4)=15

iteration 4: vertices=5063 faces=10172
              warning: nonmanifold edges: uc(1)=4 uc(3)=12 uc(4)=15
              removed 1 unused vertex
              split 2 faces
              removed 1 duplicate face
              removed 2 nonmanifold faces
              removed 4 zero area faces
              total changes=10
              warning: nonmanifold edges: uc(1)=1 uc(3)=7 uc(4)=15

iteration 5: vertices=5062 faces=10168
              warning: nonmanifold edges: uc(1)=1 uc(3)=7 uc(4)=15
              removed 1 unused vertex
              total changes=1
              warning: nonmanifold edges: uc(1)=1 uc(3)=7 uc(4)=15

iteration 6: vertices=5061 faces=10168
              warning: nonmanifold edges: uc(1)=1 uc(3)=7 uc(4)=15
              total changes=0
              warning: nonmanifold edges: uc(1)=1 uc(3)=7 uc(4)=15

Summary:
              polyhedron 0: vertices=5061 faces=10168 : warning:
nonmanifold edges: uc(1)=1 uc(3)=7 uc(4)=15

Writing: _LCD_face_plate_LCD_hole_open_(repaired)_polyfix.stl

... abm_polyfix finished, time used: 0d 00h 00m 01s

-----


When you have as many issues as in this example, you cannot expect
import + booleans will work very well, if at all. Even my attempted fix
may still be problematic, but you can try.

It could be that the "repaired" version you provided has more problems
than the original. With such issues it isn't a surprise that using it in
OpenSCAD was a problem.

Carsten Arnholm

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: Ovals

FourthDr
In reply to this post by nophead
NopHead:

What do you mean by "2-manifold"? I thought manifold was well, manifold.
There is some other type of manifold?



--
Sent from: http://forum.openscad.org/

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: Ovals

nophead
It is the technical term for the topology of the bounding surface of a three dimensional shape, I think.

There are other degrees of manifoldness for other dimensions but it is beyond my knowledge of maths.

On 5 September 2018 at 21:27, FourthDr <[hidden email]> wrote:
NopHead:

What do you mean by "2-manifold"? I thought manifold was well, manifold.
There is some other type of manifold?



--
Sent from: http://forum.openscad.org/

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: Ovals

FourthDr
In reply to this post by cacb
Cacb:

Very interesting. What tool are you using? I tried the ployfixed LCD file
and OpenSCAD is still throwing a CGAL error. I did fix the back cover part
so I know it is manifold. That's why I don't understand why OpenSCAD doesn't
work. The preview works fine. But when I click render I get a blank screen
and this message:

Compiling design (CSG Tree generation)...
Rendering Polygon Mesh using CGAL...
Geometries in cache: 33
Geometry cache size in bytes: 3560328
CGAL Polyhedrons in cache: 32
CGAL cache size in bytes: 1232672
Total rendering time: 0 hours, 0 minutes, 0 seconds
Rendering finished.

OpenSCAD appears to just ignore the file and render nothing. What's going on
there? I'm stumped. Please see attached unaltered LCD stl below. The file
was collected from Thingiverse thing #1922863 here:
https://www.thingiverse.com/thing:1922863
<https://www.thingiverse.com/thing:1922863>  

_LCD_face_plate_LCD_hole_open.STL
<http://forum.openscad.org/file/t1425/_LCD_face_plate_LCD_hole_open.STL>  



--
Sent from: http://forum.openscad.org/

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: Ovals

FourthDr
This post was updated on .
In reply to this post by cacb
Cacb:

Here is the top half of that bottom that doesn't render, even though it is
manifold and appears to have no problems. Since we are taking about the
bottom half already. This one has a major problem.  I just tried to open it
in Tinkercad, and once I finished importing it the whole top part vanished.
Looks like some one made the top half of bits and pieces but didn't fuse
them together properly. I can't figure out how to fix it either. Care to
take a swipe?

FRONT_COVER.stl <http://forum.openscad.org/file/t1425/FRONT_COVER.stl



--
Sent from: http://forum.openscad.org/

_______________________________________________
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: Ovals

cacb
In reply to this post by FourthDr
On 2018-09-05 22:27, FourthDr wrote:
> What do you mean by "2-manifold"? I thought manifold was well,
> manifold.
> There is some other type of manifold?

2-manifold edge means that edge is referenced by exactly 2 faces.
1-manifold edge means it is referenced by exactly 1 face and that face
is then obviously not contributing to a closed volume boundary. In
general, an edge being N-manifold means the edge is referenced by N
faces. In loose language you could say a face is non-manifold if it
refers to at least one edge that is not 2-manifold.

In 3d-printing it is common to require all edges to be 2-manifold,
because the faces will then unambiguously define one or more closed
volumes. If you had a more sophisticated representation of volumes with
sub-volumes using e.g. different materials, it would make a lot of sense
to allow N-manifold edges for N>2, but it is not possible within a
single STL.

An STL file contains disconnected triangles ("polygon soup"), i.e. faces
with exactly 3 edges. An edge runs between 2 vertices. A vertex has XYZ
coordinates.  Strictly speaking, in STL files all edges are 1-manifold,
because there is no concept of edge or vertex sharing, all vertices (and
coordinates) are repeated for every triangle, hence it is a "polygon
soup". It is up to the software reading the STL file to have a guess at
what matches what and which manifoldness it is supposed to represent,
and this often leads to conflicting interpretations. STL is (somewhat)
OK for slicer programs, but not really a good choice for import to CAD
programs, due to the interpretation issues mentioned. As mentioned,
there are other formats that are less ambiguous, including WaveFront
OBJ.

Carsten Arnholm

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
rew
Reply | Threaded
Open this post in threaded view
|

Re: Ovals

rew
In reply to this post by nophead
On Wed, Sep 05, 2018 at 04:47:07PM +0100, nop head wrote:

> I have never had much success with other people's STLs for 3D
> printing.  Even if they are manifold they are often not correct for
> 3D printing on my machines. I mostly design everything I print from
> scratch in OpenSCAD.

For SOME stuff I import "their" STL and add the things I need for
printing on my printer. I think "brim" is overrated. It adds material
where the object doesn't need it and not enough where it does.

For stuff that is high and long, and tends to pull the ends off the
bed, I now add a half cone of a few layers high to the ends. Works
great. Except when there end up being STL errors.

        Roger.

--
** [hidden email] ** http://www.BitWizard.nl/ ** +31-15-2600998 **
**    Delftechpark 26 2628 XH  Delft, The Netherlands. KVK: 27239233    **
*-- BitWizard writes Linux device drivers for any device you may have! --*
The plan was simple, like my brother-in-law Phil. But unlike
Phil, this plan just might work.

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: Ovals

nophead
Yes but brim adds just more outlines that can be removed easily. If you add it to the model it will be fully incorporated, how do you remove it from the print?

On 6 September 2018 at 11:09, Rogier Wolff <[hidden email]> wrote:
On Wed, Sep 05, 2018 at 04:47:07PM +0100, nop head wrote:

> I have never had much success with other people's STLs for 3D
> printing.  Even if they are manifold they are often not correct for
> 3D printing on my machines. I mostly design everything I print from
> scratch in OpenSCAD.

For SOME stuff I import "their" STL and add the things I need for
printing on my printer. I think "brim" is overrated. It adds material
where the object doesn't need it and not enough where it does.

For stuff that is high and long, and tends to pull the ends off the
bed, I now add a half cone of a few layers high to the ends. Works
great. Except when there end up being STL errors.

        Roger.

--
** [hidden email] ** http://www.BitWizard.nl/ ** +31-15-2600998 **
**    Delftechpark 26 2628 XH  Delft, The Netherlands. KVK: 27239233    **
*-- BitWizard writes Linux device drivers for any device you may have! --*
The plan was simple, like my brother-in-law Phil. But unlike
Phil, this plan just might work.

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: Ovals

ednisley
In reply to this post by FourthDr
On 09/06/2018 12:35 AM, FourthDr wrote:
> the whole top part vanished

The inside surface of the lid is oriented incorrectly (there's no
"inside") and the outside surface has a bunch of self-intersecting
triangles. Slic3r's auto-repair algorithm gets it mostly right, although
the rectangular openings seem covered with Z-fighting membranes.

It's a wonder 3D printing works at all ...

--
Ed
https://softsolder.com

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
 --
Ed
softsolder.com
rew
Reply | Threaded
Open this post in threaded view
|

Re: Ovals

rew
In reply to this post by nophead
On Thu, Sep 06, 2018 at 11:22:37AM +0100, nop head wrote:
> Yes but brim adds just more outlines that can be removed easily. If you add
> it to the model it will be fully incorporated, how do you remove it from
> the print?

IF it is easy to remove, because adjoining lines do not adhere
perfectly to eachother, the brim doesn't serve the purpose we have for
it to help adhering the object to the platform. So IMHO, IF the brim
works, it is also plastic-wise "incorporated into the object" as you
say.

In practise, that is one of the problems: On the first layer the
adhesion between adjacent lines is not perfect. Then the print fails.

"tri" is the object I want,
print_tri () is how I print it.

The half cones snap off by hand. The "cube" to stabilize the whole
thing while printing can be snipped of with side-cutting pliers.

Printing this-side-up worked better for me. I don't remember if it was
surface finish or something else that prompted me to print it this
way.

        Roger.

$fs = 0.2;

module hcone (d, h)
{
  difference () {
     cylinder (d1=d, d2=0, h= h);
     translate ([0,-d/2-1,-1]) cube ([d/2+1, d+2,h+2]);
  }
}

module tri (l=100)
{
  hull ()
  for (i=[0:120:240])
    rotate (i) translate ([10,0,0]) cylinder (d=3, h=l);
}

module print_tri ()
{
  cy = 16;
  cz = 12;
  cx = 0.8;
  len = 80;
  translate ([0,0,11.5]) rotate ([0,90,0]) tri (l=len);

  translate ([0,-cy/2,0]) cube ( [cx, cy,cz]);
  hcone (20,1);

  translate ([len,cy/2,0]) rotate (180) cube ( [cx,cy,cz]);
  translate ([len,0,0]) rotate (180) hcone (20,1);
}

print_tri ();




>
> On 6 September 2018 at 11:09, Rogier Wolff <[hidden email]> wrote:
>
> > On Wed, Sep 05, 2018 at 04:47:07PM +0100, nop head wrote:
> >
> > > I have never had much success with other people's STLs for 3D
> > > printing.  Even if they are manifold they are often not correct for
> > > 3D printing on my machines. I mostly design everything I print from
> > > scratch in OpenSCAD.
> >
> > For SOME stuff I import "their" STL and add the things I need for
> > printing on my printer. I think "brim" is overrated. It adds material
> > where the object doesn't need it and not enough where it does.
> >
> > For stuff that is high and long, and tends to pull the ends off the
> > bed, I now add a half cone of a few layers high to the ends. Works
> > great. Except when there end up being STL errors.
> >
> >         Roger.
> >
> > --
> > ** [hidden email] ** http://www.BitWizard.nl/ ** +31-15-2600998 **
> > **    Delftechpark 26 2628 XH  Delft, The Netherlands. KVK: 27239233    **
> > *-- BitWizard writes Linux device drivers for any device you may have! --*
> > The plan was simple, like my brother-in-law Phil. But unlike
> > Phil, this plan just might work.
> >
> > _______________________________________________
> > OpenSCAD mailing list
> > [hidden email]
> > http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
> >

> _______________________________________________
> OpenSCAD mailing list
> [hidden email]
> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org


--
** [hidden email] ** http://www.BitWizard.nl/ ** +31-15-2600998 **
**    Delftechpark 26 2628 XH  Delft, The Netherlands. KVK: 27239233    **
*-- BitWizard writes Linux device drivers for any device you may have! --*
The plan was simple, like my brother-in-law Phil. But unlike
Phil, this plan just might work.

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
12