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

On 2 September 2018 at 10:47, FourthDr who_doctor@hotmail.com wrote:

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
Le mar. 4 sept. 2018 à 07:21, FourthDr who_doctor@hotmail.com a écrit :

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.

On 4 September 2018 at 08:21, Troberg troberg.anders@gmail.com wrote:

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

On 4 September 2018 at 10:32, FourthDr who_doctor@hotmail.com wrote:

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-(2x/L))
) (R/sqrt(pi)) * sqrt(hpi/180 - sin(2h)/2 + Cpow(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

i suggest you to code in openscad the entire objects/parts from your
view of the stl
it will make you print faster ;)
Le mer. 5 sept. 2018 à 03:03, FourthDr who_doctor@hotmail.com a écrit :

On 09/04/2018 09:02 PM, FourthDr wrote:

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

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

On 5 September 2018 at 15:46, Ed Nisley ed.nisley@pobox.com wrote:

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.

On 5 September 2018 at 16:28, FourthDr who_doctor@hotmail.com wrote:

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.

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

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 who_doctor@hotmail.com wrote:

On 2018-09-05 22:27, FourthDr wrote:

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

On Wed, Sep 05, 2018 at 04:47:07PM +0100, nop head wrote:

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. 

--
** R.E.Wolff@BitWizard.nl ** 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.

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 R.E.Wolff@bitwizard.nl wrote:

On 09/06/2018 12:35 AM, FourthDr wrote:

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