# Boolean subtract geometry from curves?

## Recommended Posts

I'd like to cut out all portions of a polygon curve that are inside of a polygon mesh. This may result in the curve being cut into multiple pieces. It may also result in one or both of the original endpoints being removed. I'd like to preserve all details of the curve that are outside of the polygon mesh, too. For example, if the red shapes are the polygon volume, the blue line is the curve, and the green circles are the points where they intersect (which are not necessarily preexisting points on the curve), this is what I'd like to happen:

Basically, I want to boolean subtract a polygon mesh from a polygon curve, but for some some reason the boolean sop doesn't affect the curve, so I'm looking for other options.

EDIT: I can KINDA get it to work by:

1. Translating the curve along the normal.
2. Reversing the point order on the translated version.
3. Merging the translated curve and the original curve.
4. Using an add sop on all points from the merge in step 3 in order to make a polygon.
5. Boolean subtracting my polygon volume from the polygon from step 4.
6. Polywiring my original curve with a tiny radius.
7. Adding a sphere with a tiny radius to each endpoint of my original curve.
8. Boolean union-ing the polywire from step 6 with the spheres from step 7.
9. Grouping all points from the polygon I got from step 5 that are inside the wire-with-nubs from step 8.
10. Promoting the group from step 9 to all edges entirely contained by the points in the group.
11. Dissolving everything except the edges in the group from step 10, with "create curves when dissolving boundary" on and "remove inline points" off.

Obviously that's extremely hacky, but at least it does work.

Edited by Ellyfish

##### Share on other sites

Hey Elly,

Your best bet is to resample the curve, and group points based on bounding geo (your desired subtract geo).

Then promote this group to an edge group using the groupPromote SOP. Experiment with whether the "Include Only Elements..." checkbox works better for you. Use a dissolve SOP to delete the edges of your grouped points.

Then finally drop a facet SOP with "Remove Inline Points" turned on to bring the curve back (close) to its original sampling. If this isn't close enough, you could do a compare with the original curve to keep points that are in close proximity.

Hope that works for you

• 1

##### Share on other sites

here you are..(arrgggg...late by 1 minute....hey I had to do a screen print !!!)

Edited by Noobini
• 1

##### Share on other sites

Unfortunately, the existing points on the curve are placed in very specific spots, some of which are "inline" but still need to remain where they are. I don't want to remove any points on the curve that are not inside the volume, and I don't want to add any points other than the specific ones where the curve and volume intersect. Is my hacky solution really the only one?

##### Share on other sites

here's one that works without resampling (compromising your line)....with a proviso that your line goes in a general 'direction'...ie. in my example...the line goes in X direction, so that the points can be sorted...

If I can work out how to do it for any curve..that'll be the day..

Edited by Noobini
• 1

##### Share on other sites

Because there is always far more than one way to skin a cat in Houdini, I've attached my solution as well

Preserving original points (attrib transfer>blast away points outside threshold of original)

Also, when I see I have the exact same solution as Noobini, I know I'm doing something right!

Edited by coltonmil

##### Share on other sites

Oh, that's clever! I didn't think of adding in the points you get from intersection analysis to the curve; that simplifies the problem a lot. My lines can be sorted, so that works for me. It seems to be doing the right thing on my test geo that has all the weird edge cases I could think of, too. Thank you guys!

##### Share on other sites

righto, gone all out...deliberately made my curve looping back so I can't use sort anymore...

I adapted the carve from here:

it works 99.99% of the time....but....there's the odd occasion where the intersection analysis gets is point order mixed up for some weird reason...that I have no control over...

DissolveInside3.hipnc

##### Share on other sites

here's another shot. i'm using convertline first to turn each line segment into its own prim. then intersection analysis to get the intersection points, and the prim/primuv of the line at each intersection point. then i construct a string in VEX that's formatted like what the polySplit SOP likes to see. another convert line to register the new primitive line segments, group inside the boolean object, delete the segments inside the object, then polypath to convert the line back into a minimum number of segments.

i haven't tested it with a ton of different situations just yet, but it seems to handle more complex line-surface interactions reasonably well.

• 3

##### Share on other sites

ah...I can't code so I had to do a more nodal way...but yours seems to hold up well against weaving in and out of a torus...

Edited by Noobini

##### Share on other sites

dang...spoke too soon...I spot a bit here...the S shape, it's inside the torus...

(it's sorta same problem as I have, I think, sometimes the intersection analysis just gets the order mixed up...if you follow your curve, the points created by intersection analysis goes 0,1,2,3,5,4.....huh ?)

Edited by Noobini

##### Share on other sites

The order here shouldn't matter, since I'm not really doing anything directionally. I think this is more likely a weakness of the "group by bounding object" method of finding the primitives inside the object, and of the torus being fairly coarse. Subdividing the torus helps a little bit. Peaking the geo inwards a tiny amount (like -0.001) before going into the Group Sop for some bias also helps.

##### Share on other sites

finally !!! I will not be defeated.

As you can see there are 2 methods in my latest scene, if you go the right route, while much less convoluted, it can get tripped up by the odd behaviour by intersection analysis.

The left route corrects the 'out of order' result from intersection analysis...(sort by distance along the curve)

Phew...no more testing...done...finito..kaput...

DissolveInside4.hipnc

##### Share on other sites

ahh f*** I'm a dumbass....

I could have plugged the 'sort_by_distance_to_correct_intersection_analysis_fault' into the add1 on the right route and that would get the correct order for the right route !!!

Dumbass...

DissolveInside5.hipnc

Edited by Noobini

##### Share on other sites

The order here shouldn't matter, since I'm not really doing anything directionally. I think this is more likely a weakness of the "group by bounding object" method of finding the primitives inside the object, and of the torus being fairly coarse. Subdividing the torus helps a little bit. Peaking the geo inwards a tiny amount (like -0.001) before going into the Group Sop for some bias also helps.

i think there's a flaw in your logic...I'm not a coder so can't pinpoint where it is...but it happens when a geometry intersects your curve where there is not a single point inside..ie. it envelopes a little section but does not contain a point.

The intersection analysis does show the points (on the surface)..but somehow you're not processing them ? dunno.

(edit: ahh of course, if there's no point inside...you can't promote it to edge !!)

You can see I added a little box to illustrate this in your file.

I tested mine with this little test box as well and it works...

Edited by Noobini

##### Share on other sites

Intersection Analysis Sop can get good results when used with Intersection Stitch Sop.

DissolveInside_sy.hipnc

• 2

##### Share on other sites

Like I said, group by bounding attribute isn't terribly accurate. I just peaked the geo a little bit, this time outwards, and changed the group promote to only include fully-enclosed primitives.

curve_bool_x3.hipnc

##### Share on other sites

Like I said, group by bounding attribute isn't terribly accurate. I just peaked the geo a little bit, this time outwards, and changed the group promote to only include fully-enclosed primitives.

it's alright man, who am i to try and convince you. To me, it IS accurate, it's not inside because the point is ON the surface. Sure you can use a little cheat with the peak...but I didn't have to, and Satoru's solution above also didn't have to.

(I think to myself....if it isn't terribly accurate, I should have to peak say 0.5 or 1.0 or something like that to fudge the result to make it 'inside'.......but NO.....just a peak 0.00001 is enough to make it inside....it implies it IS very accurate.....shit..I like to converse with ppl to learn from them but when ppl try bamboozle me, knowing I'm a noob, with flippant technical details...it riles me)

Edited by Noobini

##### Share on other sites

Wow, you guys really went all out. My curves are all sortable by Y, so I already implemented the first solution by Noobini (and Coltonmil, very shortly after!) in my graph. I'm assuming that version is more efficient than the general curve solutions?

##### Share on other sites

Hard to say without benchmarking on a huge number of points... Satoru's method seems like the most robust and simplest to me, and that's definitely worth something. I never quite got how to use the Intersection Stitch before, thanks for the example!

## Create an account

Register a new account