Hi Ronaldo,
Sort of. While I’m pretty sure there are some redundancies in my code, it’s actually working slightly differently…
Rather than being the minkowski sum of the letters and a cone so that the top surface is the original letter, and letters get wider and with rounded corners, instead I’m using minkowski() to make the equivalent of a tool path to subtract from the letters – the chamfering reduces the top surface and the outer edges of letters are the original font.
Does that make sense? Have a look at the 2 side by side.
Both are potentially useful – I might make an updated 3D text library module that will allow you to select either and emboss or engrave, etc.
There’s probably still some unnecessary translations I could weed out and I could potentially subtract from a simple cube rather than fully described letters – this was a rough solution to the same problem the OP was having…
Cheers
Alex Gibson
+44 7813 810 765 @alexgibson3d 37 Royal Avenue, Reading RG31 4UR
admg consulting
edumaker limited
· Project management
· Operations & Process improvement
· 3D Printing
From: Discuss [mailto:discuss-bounces@lists.openscad.org] On Behalf Of Ronaldo Persiano
Sent: 07 February 2018 00:28
To: OpenSCAD general discussion
Subject: Re: [OpenSCAD] Chamfered 3D text
.
I guess your second text call should have the same parameters as the first one: text_height instead of text_depth*2.
Anyway, I think you will get the same result with a simpler code:
module admg_chamfered_text1(some_text_here,text_height,text_depth,chamfer_depth,chamfer_width){
minkowski() {
linear_extrude(text_depth*2)
text(some_text_here,text_height,valign="center",halign="center");
cylinder(chamfer_depth,r1=chamfer_width,r2=0);
}
}
2018-02-06 21:12 GMT-02:00 Alex Gibson alex@alexgibson.net:
Here’s my solution to the same problem, using Minkowski…
The linear extrude function has a "scale" parameter that can scale one end
of the extrusion. It seems like a logical and useful addition to this
would be an "offset" parameter, that would do the same thing, but offset
the other end instead of scaling. It would solve this problem and many
others.
I totally agree. For my sigil, which I intend to cast, I need all cut-out
vertical walls to be slightly tapered, so that the final wax image does not
break when the sigil is taken off.
An offset parameter rather than a taper parameter would greatly help for
detachable casting models.
--
Sent from: http://forum.openscad.org/
Yes, being able to offset an extrusion (such that each edge within the 2D
polygon is offset relative to itself rather than from the shape's overall
center c.f. how scale works) would be very useful.
--
Sent from: http://forum.openscad.org/
I am quite sure this has been discussed before but I couldn't find the
thread. The idea was rejected (or perhaps postponed) exactly because the
issues that may arise from offset An offset may change the number of
vertices and the topology of a shape. A connected set may become
disconnected and holes may disappear.
As the proponent, Whosawwhatis, said: " Of course, it might take some
consideration, obviously, to ensure that it correctly handles areas that
become zero-thickness (or negative-thickness) when a negative value for
offset it used, as well as ensuring that the resulting object remains
manifold when areas merge or holes close up. This makes it more complicated
to implement than the existing scale parameter, but I think it would be a
worthwhile addition."
2018-02-07 11:57 GMT-02:00 RayBellis openscad@ray.bellis.me.uk:
Yes, being able to offset an extrusion (such that each edge within the 2D
polygon is offset relative to itself rather than from the shape's overall
center c.f. how scale works) would be very useful.
--
Sent from: http://forum.openscad.org/
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
In the area in which I work professionally, we call that "letting perfection
be the enemy of the good".
In other words, just because it might not work in all conceivable
situations, doesn't mean it shouldn't be done.
--
Sent from: http://forum.openscad.org/
Gibson said: " Rather than being the minkowski sum of the letters and a
cone so that the top surface is the original letter, and letters get wider
and with rounded corners, instead I’m using minkowski() to make the
equivalent of a tool path to subtract from the letters – the chamfering
reduces the top surface and the outer edges of letters are the original
font. "
Thank you, now I understood your code. It avoids to round "convex letter
vertices" although the "concave vertices" are rounded what is less
noticeable. Nice solution.
This is something that could - in principle - be done in userspace if the
font geometry information were available.
I'm not sure how hard it would be to make a '2Drender()' or
'textgeometry()'. Failing that, I guess you could scrape character
geometry from postscript into a library.
--
Sent from: http://forum.openscad.org/
http://forum.openscad.org/file/t2140/beveleda.png
I think I'm getting the 'fins' from floating point rounding, and I have a
workaround, but it's a bit of a chore to implement.
roof.scad http://forum.openscad.org/file/t2140/roof.scad
beveleda.stl http://forum.openscad.org/file/t2140/beveleda.stl
--
Sent from: http://forum.openscad.org/
Ok, so I think I've got the strange stuff worked out. ...
a.scad http://forum.openscad.org/file/t2140/a.scad
text2.scad http://forum.openscad.org/file/t2140/text2.scad
roof2.scad http://forum.openscad.org/file/t2140/roof2.scad
Though it seems to run out of memory if I try to do "the quick brown fox
jumps over the lazy dog."
testtext.stl http://forum.openscad.org/file/t2140/testtext.stl
--
Sent from: http://forum.openscad.org/