[OpenSCAD] Ovals

[FourthDr]

I see in the documentation how to create a sphere. But how would I create an
oval shape?



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

[nop head]

Use scale() with different scale factors on each axis on a circle, cylinder
or sphere.

Post by FourthDr
I see in the documentation how to create a sphere. But how would I create an
oval shape?
--
Sent from: http://forum.openscad.org/
_______________________________________________
OpenSCAD mailing list
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org

[FourthDr]

Hi Nophead:

I'm actually looking to create an ogive nose cone with a spherical point.
There was a model on Thingiverse someone made that included what looked like
a nice set of cones snub ogive, ogive, and conical, plus a few others. But
when I tried to cut it to fit my printer it crashed OpenSCAD. Upon closer
inspection, the model was full of errors that where not easily fixed. So I
thought I'd try and make my own. I'm looking to create the cone plus a base
that fits a body tube and includes a loop to attach a shock cord for a model
rocket. See attached model: nosecone.zip
<http://forum.openscad.org/file/t1425/nosecone.zip>

Model Rocket Kit <https://www.thingiverse.com/thing:685617>





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

[christophe malvasio]

the nosecone of this rocket does not look oval
basic : hull( ){translate([0,0,($Z-$1_
diameter])sphere($1_diameter);cylinder($2_diameter);}
printers are not very good with spheres

Post by FourthDr
I'm actually looking to create an ogive nose cone with a spherical point.
There was a model on Thingiverse someone made that included what looked like
a nice set of cones snub ogive, ogive, and conical, plus a few others. But
when I tried to cut it to fit my printer it crashed OpenSCAD. Upon closer
inspection, the model was full of errors that where not easily fixed. So I
thought I'd try and make my own. I'm looking to create the cone plus a base
that fits a body tube and includes a loop to attach a shock cord for a model
rocket. See attached model: nosecone.zip
<http://forum.openscad.org/file/t1425/nosecone.zip>
Model Rocket Kit <https://www.thingiverse.com/thing:685617>
--
Sent from: http://forum.openscad.org/
_______________________________________________
OpenSCAD mailing list
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org

[Troberg]

How I would have done the nose cone:

A succession of spheres of appropriate sizes (just calculate the diameter at
different heights), hull() them together. It doesn't take many spheres to
get a good, smooth surface.

Then, of course, cut off the bottom with difference().

If you want it hollow, make another, scale it down a bit, and use
difference() to hollow the first one out.



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

[nop head]

I had to look up https://en.wikipedia.org/wiki/Ogive. Looks like you can
rotate_extrude the intersection of a circle and a square.

Post by Troberg
A succession of spheres of appropriate sizes (just calculate the diameter at
different heights), hull() them together. It doesn't take many spheres to
get a good, smooth surface.
Then, of course, cut off the bottom with difference().
If you want it hollow, make another, scale it down a bit, and use
difference() to hollow the first one out.
--
Sent from: http://forum.openscad.org/
_______________________________________________
OpenSCAD mailing list
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org

[FourthDr]

Troberg:

Not quite sure I visualize how you are suggesting I code up a cone. Would
that produce a true ogive? And then how would I add a spherical tip instead
of the usual point? Have some example code?



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

[nop head]

From the diagram on Wikipedia I saw that half the cross section of an ogive
is the intersection of a circle and a rectangle.



To blunt the point you need to position another circle that is tangential
to the first one and truncate the ogive at the tangential point and then
hull it with a semi circle.

Using the formula here: http://mathworld.wolfram.com/TangentCircles.html

Post by FourthDr
Not quite sure I visualize how you are suggesting I code up a cone. Would
that produce a true ogive? And then how would I add a spherical tip instead
of the usual point? Have some example code?
--
Sent from: http://forum.openscad.org/
_______________________________________________
OpenSCAD mailing list
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org

[cbernhardt]

Or, if you have access to a CAD program that creates DXF files you could draw
the ogive shape as a cross section of a shell and import it.
<Loading Image...>



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

[jsc]

On the subject of rocket nosecones, I created an OpenSCAD model some time ago
to generate Haack series shapes:

https://www.thingiverse.com/thing:804129

These shapes are calculated to minimize drag in supersonic flows, so not
something that is functionally useful for model rockets. Still, I thought it
might be of interest.

Some work would need to be done to make it suitable for fitting to a rocket.



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

[Revar Desmera]

Post by jsc
On the subject of rocket nosecones, I created an OpenSCAD model some time ago
https://www.thingiverse.com/thing:804129
These shapes are calculated to minimize drag in supersonic flows, so not
something that is functionally useful for model rockets. Still, I thought it
might be of interest.
Some work would need to be done to make it suitable for fitting to a rocket.

Of course I only see this post AFTER I wrote my own. :)
Well, I might as well post it:


pi = 3.1415926536;

function haack(x, L, R, C) = let(
h = acos(1-(2*x/L))
) (R/sqrt(pi)) * sqrt(h*pi/180 - sin(2*h)/2 + C*pow(sin(h),3));

function haack_series(L, R, C, steps) = [
for(i = [0:steps]) let(x = i*L/steps) [x, haack(x, L, R, C)]
];

// L is the length of the nosecone.
// R is the radius of the nosecone base.
// C should be 0 for a Von-Kármán ogive.
// steps is the granularity of the shape along the length.
module haack_nosecone(L, R, C=0, steps=100) {
pts=concat(
haack_series(L, R, C, steps),
[[L, R], [L, 0], [0, 0]]
);
translate([0,0,L]) {
rotate_extrude(angle=360, convexity=2) {
rotate([0,0,-90]) polygon(points=pts);
}
}
}

haack_nosecone(L=80, R=50, C=0);




- Revar

[FourthDr]

This post might be inappropriate. Click to display it.

[FourthDr]

The whole reason for this exercise in the first place is because I needed to
cut the part into two to fit my printer using the pizzlecut library. I think
I can eventually get this working since it's just basically a geometric
shape problem.

But with other models, this is a huge problem. I can't just easily redesign
more complex designs/shapes. Especially, since I don't always have the
original design files just an stl file. So any time there is some problem no
matter how small with the model OpenSCAD throws a hissyfit. Sometimes I can
"fix" the model where OpenSCAD will accept it. Bust most of the time not.

Case and point, I have two models attached below that I need cut into two
parts. They both look and preview fine. My slic3r has no problems. But when
I try to cut them, OpenSCAD will not render them. And in worst case such as
with the nose cone will actually crash OpenSCAD with a C++ error.

It's too bad there is not a way to just cut with defects and all. It just
needs to be accepted by a slicer and look ok to the eye. A diagnostic tool
of some sort that could fix these problem would be great. Or that could
point out problems and give suggestions on fixing them so OpenSCAD will
accept the file.

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.





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

[christophe malvasio]

i suggest you to code in openscad the entire objects/parts from your
view of the stl
it will make you print faster ;)

Post by FourthDr
The whole reason for this exercise in the first place is because I needed to
cut the part into two to fit my printer using the pizzlecut library. I think
I can eventually get this working since it's just basically a geometric
shape problem.
But with other models, this is a huge problem. I can't just easily redesign
more complex designs/shapes. Especially, since I don't always have the
original design files just an stl file. So any time there is some problem no
matter how small with the model OpenSCAD throws a hissyfit. Sometimes I can
"fix" the model where OpenSCAD will accept it. Bust most of the time not.
Case and point, I have two models attached below that I need cut into two
parts. They both look and preview fine. My slic3r has no problems. But when
I try to cut them, OpenSCAD will not render them. And in worst case such as
with the nose cone will actually crash OpenSCAD with a C++ error.
It's too bad there is not a way to just cut with defects and all. It just
needs to be accepted by a slicer and look ok to the eye. A diagnostic tool
of some sort that could fix these problem would be great. Or that could
point out problems and give suggestions on fixing them so OpenSCAD will
accept the file.
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.
--
Sent from: http://forum.openscad.org/
_______________________________________________
OpenSCAD mailing list
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org

[FourthDr]

That's simply not possible. I don't have the ability or programming skills to
do that. I would need to have the help of some sort of automated tool to
repair any model I might need to print. Or lots of help from some one that
is highly skilled in OpenSCAD.



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

[Carsten Arnholm]

Post by FourthDr
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

[FourthDr]

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/

[FourthDr]

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. Case to
take a swipe?

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



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

[Ed Nisley]

Post by FourthDr
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 Nisley]

This post might be inappropriate. Click to display it.

[nop head]

Or manifold STL files with vertices closer than the OpenSCAD grid. They
actually become non-manifold during import.

Post by Ed Nisley

Post by FourthDr
They both look and preview fine.

Meshlab shows both have the usual assortment of mesh errors and are
non-manifold: hot death on a stick for further operations.
My (admittedly limited) experience with automatic mesh repair suggests the
algorithms generally make the choices I expect, but sometimes produce
weirdly shaped patches, if not completely bizarre shapes, around the
non-manifold geometry. The fact a "repaired" STL file still contains
geometry errors shows the automation doesn't always get it right.
Agreed, OpenSCAD shouldn't fall over dead when handed a broken STL file,
but AFAICT the explosion happens deep in the CGAL machinery where it's out
of anyone's control. The only defense seems to be not handing it
non-manifold models.
Which rules out many attractive STLs scattered around the Interwebs ...
--
Ed
https://softsolder.com
_______________________________________________
OpenSCAD mailing list
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org

[FourthDr]

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/

[nop head]

Post by FourthDr
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.

The grid is defined here:
https://github.com/openscad/openscad/blob/c6a485651fa29f1a878ea454558192492f7467ec/src/grid.h#L14

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.

Post by FourthDr
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
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org

[Ezra Reynolds]

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.

Post by FourthDr
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.
The grid is defined here: https://github.com/openscad/openscad/blob/c6a485651fa29f1a878ea454558192492f7467ec/src/grid.h#L14
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.

Post by FourthDr
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
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org

_______________________________________________
OpenSCAD mailing list
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org

[FourthDr]

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/

[nop head]

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.

Post by FourthDr
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
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org

[a***@arnholm.org]

Post by FourthDr
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

[Rogier Wolff]

Post by nop head
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.

[nop head]

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?

Post by Rogier Wolff

Post by nop head
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.
--
** 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
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org

[Rogier Wolff]

Post by nop head
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 ();

Post by nop head

Post by Rogier Wolff

Post by nop head
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.
--
** 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
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org

_______________________________________________
OpenSCAD mailing list
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org

[FourthDr]

What I don't understand is how it can preview a broken stl with no problem.
But a render, which you would think uses the same process fails.

There needs to be some kind of built-in utility that can tell you just where
in the mesh it is having a problems. It's impossible to figure out a
problem, if the cause it shrouded inside of a black box. There is basically
no visualization of problem areas. Or helpful error messages.

The only way I was able to see one of the major flaws in the nose cone was
when I imported it into Tinkercad and tried to slice the cone off the base.
It was then that by chance after separating the cone from the base that I
saw a ton of artifact triangles still connected to the cone-less base. Then
I knew there where major issues with the model. But OpenSCAD said nothing
about it other than crashing when I tried to render.

So once I know there are problems. What's the easiest way to identify and
repair them without being an export. Every time I try to manually repair an
stl it breaks another part of the model in some way.



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