Bridge Letters for Plasma/Laser Cut

I was wondering if there is a Python script out there that serves as this function.
I can do this manually with square tool and the Curve Boolean command, I am looking for something that works a little more quickly.

The video shows how I currently use the tool in another program. I make designs with letters quite frequently. Having this kind of quick function in rhino would be a huge time saver. Is the possible with a script, or is there a better solution?


create the letters as surfaces then create a little surface and use Orient with option copy and scale 1d followed by BooleanUnion, MergeAllFaces, and Silhouette.

1 Like


Thank you so much for the the help. While doing these types of jobs I usually only work with curves, I just didn’t think about using surfaces…Great idea! Though not as quick and simple as what I am doing today with curves, but definitely an improvement and gets the job done. Maybe I can write a script to do all 3 operations in one shot. Thank you.

I do have a follow-up question. Should there be difference creating letters as surfaces opposed to creating letters as curves and making them planer surfaces.

Boolean Union doesn’t seem to work correctly if I create the letter as curves and make a planer surface out of it. Do you see that or am I missing something. A curve is a curve and planer is planer… so I confused why the it does not act the same. I’ve tried it with a few different files with the same results.
Please see attached file.
LetterTEST.3dm (2.5 MB)

hey Jason,

yes i think there might be some general bug. its not even about using planar surface on curved letters, or surfaced letters straight out of the box, but may have something to do with in which order one creates the little surface. i could not find the “cause” yet, in some sequence it makes a proper boolean operation in others not, with the same surfaced letters like it would depend on how far i zoom in or whatever, or be it the weather? :smiley: very strange indeed.

@pascal can you have a look?

1 Like

What I would do:

  • create all objects as curves
  • select all curve objects, use CurveBoolean, set Delete Input to “All”
  • Ignore the prompt, click outside the objects (inspired by @Helvetosaur)
  • Click on all the parts you want to cut out
    And hey presto!


And you can do this for the entire text in one go.


@maxz - that is way we have been doing it when we do work in rhino. Problem is, that some of our decorative work has a lot of scrollwork and holes. It has been easy forget to click on every scroll or hole we want to punch out. That is why we revert back to the old software to just connect the letters. Less room for error.

@RichardZ - thank you for looking at that file. On second look, it appears that curve letters that have holes in them have the issue ( A,D,B,O,R…ect.) Letters that like L,H,J E…ect. do not share this issue. It has to do something enclosure of a inner closed line that cause the issue. I am not sure why that is or how to solve it. I have been playing around with it and have not come up with a solution yet.

Too bad that a similar solution does not work the same way for curves.

I made macro that does everything in one click… works pretty well.
! _BooleanUnion _Enter
_MergeAllFaces _Enter
_Silhouette _Enter
_SelPrev _Delete _SelLast

i cant confirm that, i had the same letter working once and once not.

but it should, lets wait till pascal has some time.

cool will try :slight_smile:

omg… it drove me nuts… i tried now on the same surfaced letter and had it failing and working seemingly completely erratic and after fiddling for more than an hour i think i found out what “leads” to it -> believe it or not it depends on wether you draw the surface CW or CCW at least after many times trying this was still repeatable.

but that was not the end of the story because directions seem to change. if you draw a rectangular surface with SrfPt in a specific direction a proper BooleanUnion works only with further SrfPt surfaces which where drawn in the same chronologic direction.

here a file with two surfaces one fails the other works, on the same letter.
@pascal if you have time please check this out.

weathery-boolean.3dm (52.4 KB)

This seems to me do be a pretty weird way to use Boolean operations… but if you must, at least make sure all the surface normals are pointing the same way.


sounds almost like a compliment.

i didnt think about the normals i must admit, but drawing a flat surface on cplane one would probably not expect having to worry about that or are you going to tell me that this was intended that the normals change depending on which direction one draws the points?

Easy enough to check: yes they do. And BooleanUnion on two overlapping surfaces with opposite normal directions results in the overlap becoming a void. With coinciding normal directions the overlap becomes a separate surface (as part of an open polysurface)

Thinking about the normal direction: a surface drawn on the current CPlane is not different from any other surface somewhere in 3D space, and the normal direction has to be defined by some rule, so it makes sense to me to define it by the way the surface is constructed, and not by where it is in space.
But as this case demonstrates, it would be helpful if a selection could be organised pointing the same way, say all at the smallest/biggest angle relative to one of the X/Y/Z axes.

Thank you @pascal for that last bit of info. Running the Dir Command on the geometry makes all the difference. I do a quick check the normals and run my macro and it works like charm. It has has been working for me all morning without incident. Thank you for all the help.

I don’t think about normals much when I am doing line work. It makes sense that doing boolean operations on surface makes all the difference onto which direction the normals are pointing.

In some strange way, I think Pascal is impressed with our unorthodox boolean operations. :stuck_out_tongue_winking_eye:

I do however, wish there was a easy way of doing this without making surfaces in the first place. It would be nice to have it function like the video at the top of the thread or auto Boolean operations based on closed planer curves.:wink:

I’ll always be a student of the community and always learning. Thanks everyone.

Hi Jason - that is what CurveBoolean is for - have you messed with that?


Yeah, the files I receive are detailed scrollwork and patterns that have a lot of holes in them. Using the CurveBoolean, I would have to click on every hole (negative space) that I want to knock out to provide for the Letter monogram.
It proves to be tedious work with a lot of room for error.

Maybe there is a better way of using CurveBoolean to fit my needs.

The files that I get are custom monogram names, House numbers…ect. The inner monogram changes with each file. Doing CurveBoolean is just not feasible for this type of work. I need to place my custom item within the scrollwork, bridge it the frame and move to the next file.

You can see from my first post how fast it can be. It is kind of “live” boolean tool that is uses. Its the only reason I use that software, otherwise the rest of my work is done in rhino. That piece of software works really nicely, but sadly no longer being updated.

Example of a file i receive.
46 PM

Two observations:

  • Once you have combined all surfaces with BooleanUnion, you can skip MergeFaces and go direct to Silhouette. It will not make much difference since you are using a macro, but I always like to keep those as simple as possible.
  • A quick way to detect reversed direction surfaces could be to use the Shaded display mode, and set the backface color to something contrasting (Preferences > Display mode > Shading settings > Backface settings > single color for all backfaces > select color)

actually i wanted to know if this is intended that surfaces on which drawing the points in one direction or the other will effect the normal direction, the consequences are obvious :smiley:

but i would definitely not expect that 2 surfaces would create a void at all, depending on the direction of the normals.

if you do that the boarder of both surfaces get outlined.

good idea, but if one knows that drawing surfaces depending on the chronologic direction will change the normal direction one could just watch out not drawing it CCW when the other surface was made CW

otherwise surfaces created with PlanarSrf usually always have the normals showing up. except the following:

i found that you are right in that, the normals of those first letters you have pointed out have their normals pointing down while the others are showing up, what a mess… usual curves with holes work as expected.

Here is script I found from @Helvetosaur automatically fixes the normals bases on the camera (viewport). This gets the normals all going the same way. I think this will work nicely within my Macro. I think I can do the whole operation in one click no matter how it is drawn.

Updated Micro:
! -RunPythonScript
_BooleanUnion _Enter
_MergeAllFaces _Enter
_Silhouette _Enter
_SelPrev _Delete _SelLast

nice, i was thinking that i might have seen something like that from mitch. i guess you have a usable solution now. :beers:

1 Like

Yeah, All the pieces are in place and its doing what I need.
I’m just messing with the workflow to see what makes the process more efficient.

I was able to put it all together the mirror the live bridge process i was wanting, but with surfaces in rhino.Live Bridge

Just got to deicide if I want to do the all booleans at the end or as I go.

Either way, I silhouette at the end and I end up with curves that I can use to write my G-code… Mission accomplished!:metal:


Sorry Richard, in my eagerness to try it out I did not read your post thoroughly.

@jason: Looks like you made a nifty macro out of all this. How did you program the placement of the bridge, the square fixed-width surface oriented by just two points on the centreline, complete with preview? I could not find a single command to do this…