Another new issue with boolean union

Rhino Rhino for Mac
1

I am having yet another issue with boolean union. And this time my new found skill of using ExtractSrf, DupBorder, Trim and Join does not work either.

This is what happens when I try a Boolean union of these two objects:

The top surface of the M gets removed. The cap command does not solve this.

When I do boolean difference the M from the A, and then ExtractSrf, DupBorder, and Trim this does not work either. The same thing happens.

Something seems to be wrong with that M object, but I can’t find what.

I have attached the file.

MA.3dm (60.8 KB)

2

It’s actually your A. See the front view in MA_zoom.3dm (36.4 KB)

3

Thank you Chuck! That was easy to fix.

Did you use a special tool to find this so quickly? I am sure that something like this will happen again, and being able to find these kind of issues quickly and easily would be very helpful.

I tried SelOpenPolysrf and ShowEdges, and could not find anything that way. I also went around the periphery or the letter (the wrong one) and obviously could not find it. Even if I had gone around the letter with the issue I am not sure if I would have found it. Seeing the file you uploaded at extreme magnification made me aware of the fact how small this issue really was.

What do you suggest I do when searching for the mistake when this happens again.

4

Hi Zews,

There is currently no special tool. I noticed that the boolean completed correctly, but the mesher failed. I could see this because the top and bottom of the M, after BooleanUnion, showed isocurves but were not shaded. Now, the inputs (M and A) are just simple extrusion objects, so there’s nothing more to them than the base curves and and something to say how far to extrude. That led me to look at those base curves, which can be found by exploding and DupBorder on the main letter faces. Turn the points on for these curves and zoom in where you see a bunch of points close together. That will usually show the problem.

I have been working on some ways to validate geometry before using it in a subsequent operation. This functionality will show up in a future version. I don’t know when, though. In your case, you would check the curves before extruding them to make the letters.

5

I have gone back to the original curves these objects were extruded from. The originals were first type converted to outlines via “Create Outlines” in Illustrator, then imported into Rhino and then extruded. The strange thing is, that at that location of the A the original curve in Illustrator is smooth and seems fine, it does not have that weird section. So I would not expect anything strange to happen. However, at the other end of the A (lower right hand corner) in Illustrator there is an anomaly.

When the curve got imported into Rhino, the anomaly you found was created, and the other one stayed the same. The one you found seemed to be the cause of the weird boolean union, but the other anomaly did not seem to have an effect on that.

6

What I do is get the base curves and turn on curvature graph - you probably need to turn the scale way down, but when you do, the spikes left in the graph are often where the problem lies. Zoom in.

-Pascal

7

Thank you pascal.

Yes, this shows the issues right away very clearly. I don’t even have to turn the Display Scale that far down to see very clearly where this is happening.

Now I just have to remember to do this with all curves when I import something to extrude. :smile:

8

On a semi-related note, a month ago I had several random Boolean union failures using the text generated as solids in MacRhino (not generated as curves from Illustrator–a notoriously unreliable method ).

Might errors occur in the original font (which I suspect is the case) or might there be a possible intermittent error in Rhino? The font was Impact. Was conducting a workshop so did not chase it down, but still have the file if this is a possible Rhino issue and is of interest. ~Dave

9

Yes. Fonts are notorious for the poor quality of their curves - they’re meant for print and on-screen display, not for manufacturing. As soon as you take them into the manufacturing realm, where curves need to be good quality and accurate - and often much larger than they are usually seen on-screen, many fonts go south.

–Mitch

10

I figured the fonts were the issue. While I know how to repair this problem, the challenge is not knowing you have a problem until you’re deep into a workflow. Also, this can be a bit unfortunate when giving a demo to students! :wink:

It would be a pretty cool feature if Rhino had some type of automated check routine (for line continuity) that could be run when using solid font creation—especially since the workflow for vector importing of fonts from Illustrator is truly wretched.

Even with the same fonts, Rhino seems to do a much better job. If this could be improved further (perfected?), that would be just ducky. ~Dave

11

I have been working on this for awhile now on and off as a project, I can throw a test version out here…

The attached script attempts to fix small non-tangency errors in planar curves like letterforms. It does so by analyzing the angle between the various polycurve’s segments and if the angle is within the “fix” limits, it adjusts the two neighboring sections by moving their common endpoint to be on a line between the next to last points of each curve - 3 points in line guarantees a tangency condition.

Depending on the input curves, there will be greater or less deviation, so always check the results. I added a check for an extremely sharp end such as Zews “A”, effectively a “flipped tangent” situation.

The input parameters are adjustable on the command line and preferences are sticky within the session.

I’m sure there will be stuff out there that will break this, so post examples of failures if you get them and I will try to fix. This is pretty subjective, you need to decide what the limit is for angles to leave as kinks.

FWIW, --Mitch

CheckFixNearTangentKinks.py (6.5 KB)

12

That’s pretty cool. When I get some breathing room time wise I’ll play with it.

Mark

13

I ran a couple of tests on some typefaces on my Windows box, file posted below. You will need to zoom in to see the differences, the originals are in red, the processed in green.

The tests convinced me that I had set the max limits too low (previously 30°), so I ran them up to 90°, modified script re-posted below. The typeface Mistral, which has a lot of strong kinks, I ran at 60° max setting. I notice that it smoothed in most spots, but not in all, so I need to take a look to see what’s not working there.

–Mitch

CheckFixNearTangentKinks.py (6.5 KB)

TypeFixExamples.3dm (1.4 MB)

1 Like
14

I have an update for the script, but I’ll wait until the downloads are working again… --Mitch

15

I was able to download both files fine.

But I am not sure I am doing this right. I have run the CurvatureGraph command on all four type examples in the file (Originals and Processed) and after that I ran your Python Script.

After that I ran CurvatureGraph again to see the result. Nothing to very little seemed to have changed, IOW, it did not seem to have changed the tangent kinks.

I then ran the same commands on the letter A that I was having issues with at the top of this thread. There was a change, but it did not solve the issue. In my case the only way to solve the issue was to run the CurvatureGraph command to find the location(s) of the issue, and then turn on Control Points and edit the curves.

16

You’re maybe confusing “tangent” and “kinks” as well as reading too much into the curvature graph.

There are 3 basic types of continuity in Rhino:

  • G0 continuous indicates positional continuity, i.e. the endpoints of
    the segments match, but the there is no tangency at the joint, it has
    an angle. An example would be the corner of a rectangle.

  • G1 continuous indicates tangent continuity - the segments are tangent
    at the joint within tolerance, but the radius of curvature on either
    side is different. An example would be a rectangle that has an
    arc-filleted corner, on one side the segment is a straight line, on
    the other a circular arc

  • G2 continuous indicates curvature continuity, not only are the
    segments tangent, but the radius of curvature on both sides of the
    joint are the same.

There is also G3 where not only is the curvature the same on both sides, but the rate of change of the curvature is the same as well. G4 means the rate of change of the rate of change is the same, etc…

Curvature graph will always show a “vertical” step at a tangent joint because the radii on both sides of the joint are not equal. That does not mean the joint is bad. Tangent joints are fine in most cases, depending on your needs. The height of the curvature graph represents the radius of curvature at the point along the curve.

Pasted image614Ă—803 25.7 KB

The problem with letterforms is that they often contain slight non-tangencies (G0 joints) of 0-2 degrees where they should be tangent, due to the inaccuracy of the type design and the fact that they were never intended for manufacturing. These slight non-tangencies wreak havoc with edge fillets when letters are extruded into solids; they may also cause other problems. The script simply aims to try and fix those without altering the letterform more than necessary.

Your “A” had a different problem - an inverted tangent - one where the joint forms a sharp point with a very small included angle. These are a bit harder to fix, the script does fix your example. The main issue with both these problem areas is determining the limit angle above/below which the the angle between segments should be left alone - i.e. there is supposed to be a real corner there. If you run the limit up too high, all the corners will round and you may destroy the geometry.

I will post some more examples in a bit. --Mitch

17

This is now officially getting way over my head. :flushed:

Do you think it is OK if I continue using CurvatureGraph to find the locations with potential issues in the imported fonts, and then fix those by turning on points and editing the curves where needed.

18

Mitch, thanks for the examples and explanations. It demystifies some stuff and helps get a more concrete view of the terminology for folks who’ve never looked at any of this. I’d used nurbs based stuff for several years before I ever had the whole degree thing explained and what kinks and knots really were. Once I got my head around that and began to know what to look for things like booleans and fillets working or not became a LOT less mysterious and frustrating.

As far as fonts go, I learned years ago to it’s just a lot less headache to bring them in and trace over the text if you plan on doing anything down the road with it beyond a simple extrude with no chamfer’s/fillets, as most of the typefaces are poorly designed at best from a nurbs standpoint. There’s one well know type foundry that almost all of it’s fonts came from designers who sketch them out on paper and scan them and feed that to an auto curve builder, and when you bring them into and Vector app for editing, every character has literally dozens to hundreds of points. Text is generally iffy at best, and total disaster more often than not depending on who created the font and whether they actually had a technical clue outside of the art of it all.

One question:

What’s “Faired”? I’ve seen that mentioned in a couple of your posts and other folks, and that’s a term I’ve never encountered before.

19

I still cannot wrap my head around “the whole degree thing”, and what knots and kinks really are. Is there another place online where this is explained a bit further?

Screen Shot 2015-06-04 at 9.05.13 AM.png1868Ă—868 21.1 KB

Yes, that was indeed the case when I imported these font curves from Illustrator. These curves all have a ridiculous number of points, many of them not necessary. Simple extruding worked fine, but as soon as I tried to do any fillets things started to get very messy.

It seems that the only solution would be to trace all the font curves with control point curves before extruding etc. These characters, there were about 30 of them, were extruded at different heights, and then flowed along a curve to make a bracelet to be 3D printed in metal. Tracing with control point curves would have increased the time I could afford to work on this way too much.

20

Hi guys,

Sorry for not getting back in here sooner, had a bunch of other projects on… So, the bad news is that although I finished the latest revision of my script and it does what it is supposed to do, in testing on letterforms with fillets, in the end it only helps a little… So it’s not going to be extremely useful, I’m afraid. I’ll try to explain:

There are two things that cause fillets to go nutz. One is that Rhino can’t figure how to extend/trim adjacent fillet sections to mate with each other. This often happens where there is a very slight kink in the edge/surfaces being filleted, or when they make an extremely sharp angle (angles in between those two generally work). So they end up being untrimmed at the joint and then the fillet fails to trim the base object. The script tries to fix those situations.

The other problem is when you try to wrap fillets around corners that are too tight for the fillet to fit (i.e. smaller than the fillet radius. The script does not address this situation, and as letterforms have many such tight curves, even if all the edges have good structure with no kinks, the fillets will often fail anyway. In order to make it work, you would have to remodel each letter to have no radii smaller than your future fillets.

To answer questions:

Yes. This will identify some potential trouble spots at least, especially if you see the graph “go crazy” as some points. But it will not necessarily guarantee successful filleting afterwards.

It’s a nautical term as far as I know, used to indicate the smoothness of the curves/surfaces used to design hulls. Smoother surfaces result in better hydrodynamics.

fair curves [¦fer ′kərvz] (naval architecture)
Curves which are smooth without sharp changes in direction over any portion of their length.

Well you can dive into McNeel’s explanation of NURBS geometry, it is a bit geeky/techy, but
maybe it will help. You don’t really need to be an expert on this stuff to use Rhino, of course, sometimes it just helps explain why things work like they do.

For the Illustrator-Rhino thing, Illustrator uses BĂ©zier splines - a predecessor and subset of NURBS, the mathematics of which was pioneered by Pierre BĂ©zier and Paul de Casteljau, both French automotive/aeronautical engineers.

The BĂ©zier splines used in Illustrator (and also many type fonts) are all single span degree 3 curves with 4 control points. For complex curves, they are hooked together end to end, but the tangency at the joints is not guaranteed. Depending on how they were drawn in Illustrator and also I guess how they are translated into NURBS by Rhino, they can have a LOT of points, lots more than are really needed to describe the curve within tolerance.

So it can make much cleaner geometry if you take time to fix/rebuild them, but this process is not an automatic one-click operation. It also takes some experience to know what methods of fixing might be best/fastest (if they need to be fixed at all) for your application. I would not want to trace over them though, I still think some more automatic methods like a judicious Rebuild of certain sections, using FitCrv and or Fair will go faster. I have a tendency to make a copy of the curves in a contrasting color and lock the originals, then start fixing the copies, making sure they don’t deviate too much from the originals.

–Mitch