I have run into micro-curve problems for a few text characters when manipulating these as 3D solids – especially booleaning text shapes into or out of other solids.
These micro-curves seem inherent in the system font or in its conversion into Rhino. (Helvetica Bold, in this case).
Suggestions to check for micro-curve problems and, if found, rebuild closed text curves before putting them to use in 3D shapes?
~Dave
The problem is the text fonts were never intended for the accuracy needed for surface modeling.
A good approach is to create the text shapes as curves. Turn on their control points and clean up the messy ones. The least number of points that accurately defines the shape is the best.
If you still have a character that won’t make good surfaces, use the CurveBoolean command to quickly clean up the loops.
Ah well… Pretty much what I’ve been doing. Unfortunately, this is tedious and prone to errors – usually found too late after many other operations and booleans fail.
No automated method to find potentially troublesome areas? Was hoping there might be a way to easily find curves with very small distances between points to focus on rebuilding these curves first.
Alternatively, maybe a method to check the integrity of closed curves? (Sort of like Select Bad Objects)
I’ve noticed problems often occur in letterforms where a straight line transitions to a tangential curve (such as the bottom of a lowercase “t”) which is comprised of many many close points. One can rebuild these sections and reduce points as a start, for sure – but should one also try and change the degree from 3 to 2 for these curves?
(not sure why so many close points are using 3 degree curves – some weird bezier conversion?)
Nothing automatic. It’s just a slog.
Be smart about it. When you clean up character curves, save them so you can use the cleaned up version next time you need the same letters or words.
I do lots of work with text that ends up modeled 3d, and have found that trying to clean up all the little bits and dense control points is more time consuming and error prone than tracing over a large picture frame image. And there are no surprises later.
@abrahamwechter: By “tracing”, do you mean manually redrawing or are you using some other method to speed things up?
@John_Brock, @dan: Given the known issues with 3D text (due to base geometry) – which users of this feature need to learn about the hard way – maybe y’all would be kind enough to alert users to this possible issue and a few tips for repair in the Help section?
Even better would be to improve the reliability of this feature at some point in the future (especially welcomed by the 3D printing crowd). I’d like a pony, too. 
I agree that Text curves are crappy. But in general to be successful at modeling in Rhino you will need to learn to efficiently identify bad curves and make good curves (either from scratch or to repair bad curves). And don’t expect much help from Mcneel. Their attitude has always been that if the user uses a tool that produces crappy geometry then the user must want crappy geometry. It took years of complaining to get a rudimentary function to identify bad objects because McNeel kept insisting that users don’t want to be told about bad geometry. Even today some bad objects are still not identified because Mcneel thinks some users will be offended.
That said. If all you are doing is using the solid Text objects with nothing else added, It should work for subtracting from other solids. As long as you don’t try to do anything like round the corners with fillets or add draft it should succeed.
I do just draw the letters. Using a 3D Connexion Space Mouse helps me keep moving quickly while I am zoomed in pretty tight. I should qualify this by saying that though I often use traced text, the quantity of letters is quite small-usually less than 10. If I had to do a large quantity I’d need to try to find a better way.
@jim: I’m with you on the need for clean base geometry! Truthfully, since 3D text is a “Rhino Feature”, I will confess to letting my guard down and assuming (you know what they say!) that the geometry was clean. See what happens when ya’ start trusting The Man! 
@dan: I could be the only rube out there, but if not, maybe McNeel & Crüe might want to add some cautionary info and/or suggestions in the Help — if only to keep swearing to a minimum (assuming this can’t be fixed up better)?
One of the workshops that I like to teach, especially to new users, involves text, distortions, and watertight modeling for 3D printing. Lots of different fonts and letters involved and tight timeframes. For this reason, I’d really like to come up with a VERY streamlined method to cleanup text. Here, the priority is less on highly “accurate” letterforms than it is on getting text shapes that behave well as a polysurface solid that can be tweaked a bit with relative impunity.
Enclosed is a file of some tests I ran on a few conversion methods and I am VERY open to suggestions for better strategies!
Spoiler: Using FitCrv with 2Degree and accuracy of .001" seems promising in terms of shape and results with 65% fewer points on a test letter that caused problems on a production project. Could prolly lower the accuracy for even fewer points, most likely.
(As a side note for anyone interested in this topic, it’s unclear to me why the original text, with tightly spaced curves, are 3rd degree curves instead of 2nd degree. I suspect this fact alone may be causing some micro loops to get created where a line may have a very, very small (and impossible to detect) reversal in amplitude? Start extruding these anomalies into a solid and all kinds of funky stuff might be happening?..)
~Dave
Text_Object_Micro_Curves_Example.3dm (1.5 MB)
Type curves are classically Bézier splines (like in Illustrator) - a bunch of connected single spans of degree 3 with 4 points. The problem is often that the joints between the spans are not tangent.
–Mitch
Thanks, Mitch. Is this an inherent problem with Bézier curves or is this a problem related to how Illustrator handles them (or other?)
~Dave
Neither.
It’s a result of using a typeface font for a purpose it was never intended for.
Clean surface modeling requires better curves than are needed for printing purposes.
No, but there are rarely tools or controls for maintaining tangency between adjoining spans in illustration/font generation software - as nobody really cares if it looks good enough by eye…
–Mitch
It all depends on what you are doing. If all you are doing is creating solid Text objects and subtracting them from other solids it should work. If you want to do something more complicated like trying to create letters with draft or fillets added it can be a huge problem.
Could this be prototyped as a script? I guess I’m trying to better understand what constitutes “a very streamlined method.”
Yes. A script would be great.
By “streamlined”, I’m thinking anything that allows for one or two operations to be applied to all the curves of desired text – a batch, if you will – that cleans them up so they can become semi-reliable polysurface solids.
The alternative – of manually sorting through and cleaning up individual letterforms – is what is hoped to be avoided.
Ideally, the 3D text command would incorporate this new function and return clean geometry. But if that’s too high a hill, some guidance on what to do to make this command work better would be a good start.
I see a few options:
A) IDEAL: Improve 3D text command to produce reliable surfaces/solids from curves that are cleaned up as a result of the command.
B) Provide instruction if command can’t be fixed that describes what can and can’t be done or what to look out for, why, and workarounds and/or supplemental scripts.
C) Identify approved fonts if all fonts can’t be used or have this function call up a handful of McNeel fonts that are cleaned up, rather than system fonts and wonky downloaded fonts from fontgasm.com
D) Failing any of the above, ditch the whole 3D font thing. It’s weak sauce as is and just sows seeds of doubt about Rhino as a whole.
Can this be fixed? Dunno. I’m now trying FitCrv with a degree of 2 and the lowest tolerance I can tolerate right now for batches of text, but honestly have no idea if this will work or is the best approach. ~Dave
Over the years in any 3D app fonts have been problematic, and it usually has more to do with the fonts and how they were originally created than anything else.
Back in the days when most fonts were created by font houses using fontographer they tended to yield cleaner beside curves, but could still be problematic.
In the last decade as it became fashionable to crank out new fonts by people who had less skill in the art tools emerged that could auto generate the outlines from scanned art and the explosion of “arty” looking fonts came to the forefront. Traditional artists started drawing fonts by hand,scanning them, and feeding that to software to generate a font and these types of fonts behaved miserably in ANY 3D application.
The bottom line is that beziers (which all fonts in the postscript world use under the hood) are not even vaguely the same thing as nurbs, particularly where cusps and bent lines are concerned.
For the most part, when I’ve had to do anything text related I’ve had far better luck converting text to bezier outlines in illustrator, importing that then cleaning up the outlines by hand in whatever modeling app I’m using after pre cleaning it up in illustrator first.
To get a feel for just how bad many fonts are under the hood, put the text down in illustrator, convert that to outlines, then examine that very closely in illustrator.
You’ll quickly see a myriad of sins that postscript printers can handle well but a nurbs environment will choke on.
It’s my educated guess that it might be possible to build fonts with less issues on import, some aspects of typography inherently will generate less than clean conversions to nurbs without some manual intervention just due to the very different mechanisms between nurbs curves and beziers.
The problem is that what works for one user may not work so well for another. You haven’t provided much detail on what you are doing but solving the the problem you are encountering may not be much help to others who are doing something different.
To get this right Rhino would have to provide the user with several options.
The first option would be to do nothing (what Rhino is doing now).
Another option would be to repair the small continuity mismatches between bezier segments. The user would set a small angle tolerance and every place where the bezier segments connect that are below that tolerance would be fixed.
Another option could be to convert the curves to tangent lines and arcs. Rhino has a command called “Convert” that is supposed to do this but the curves Convert command produces are every bit as crappy as Font curves for pretty much the same reasons.
Another option would be to do a bspline fitting. IMO a good algorithm that would do that would divide the curves into segments based on curvature. Parts of the curves that are straight (or very close to straight) would be made as straight lines and the curved regions of the curves would be divided into high and low curvature. In my experience you can get simpler cleaner curves if you don’t try include high and low curvature in the same curve.
Without knowing what you are doing with the curves one can only guess but that should produce a result that is better than the original with a minimum of control points.
Actually Beziers are exactly the same thing as NURBS. Use ConvertToBezier on any NURBS curve and you will see that the NURBS and Bezier form describe the exact same shape. Convenience is the main reason Rhino )and others) uses NURBS. It would be a lot more difficult to do the same things using only Beziers.
The primary problem with Font curves is that they often have small discontinuities between Bezier segments. Another problem may be areas with very high curvature. And another problem that DigiFabLab doesn’t seem to like is that you have many small curve segments that describe a shape that could be defined by one NURBS curve.
One nice thing about Fonts is that there function is mostly visual. That means you are free to change the shape and nobody cares as long as it still looks good.
@jim: I’m actually not trying to solve a specific problem. I was simply trying to understand what 3D Text — as a tool — currently can and can not do in Rhino. I now (to my dismay) understand both.
The hope now is to explore what 3D Text could (or, from my point of view if it is to be included in Rhino, should) do in Rhino.
@LewnWorx: I’ve witnessed the computational font world evolve for a long time (32 years) and your observations make sense about the decline of “craft”. If Rhino is to utilize what I think is a (potentially) exciting feature, some type of conversion would be most welcome, if not necessary, in terms of importing font curves or as part of the 3D Text tool in Rhino. This “cleaning-up” could be an option for those who wish/need to retain 100% integrity of lettershape over polysurface/solid suitability.
@John_Brock: Other than the obvious visual differences for creating/editing, can you point us to a resource that explains the differences between NURBS curves and Bezier (which are confusingly called “Handle”) curves in Rhino?
~Dave