Is there a way to Join or trim surfaces without merging the edges?

If I join two surfaces together, all (G1 or greater) edges become merged (even edges that remain naked.) Is there a way to prevent that from happening? It’s a huge time-killer. This is also a problem whenever I trim a surface with a joined polyline with G1 or greater continuity. It’s a pain (and not always possible) to trim using unjoined curves, but I need those edges unmerged.

I believe I may have had this issue before, and got around it by exploding the source curves first, then extruding, then joining.

Definitely not ideal though.

Yeah, I deal with this many times a day, and in some cases that’s a work-around but it’s way too slow.

“is there a way to join / trim w/ out merging edges” – this really doesn’t make sense to me, do you have images of this or something?

And if two edges become merged how can they be naked? That doesn’t make sense either unless your describing an outer boundary or something. An illustration would help convey the meaning.

Polyline to me sounds like degree 1 linear line segments, but that’s just Rhino’s GUI. Polycurve makes more sense to me if the poly-mer isn’t linear line segments.

If “unjoined” crvs are failing to trim, then they’re probably containing ‘gaps’ throughout their ‘discontinuous’ “connection”.

If you join the crvs, and they’re within the file tolerance, then the “join” will be successful, and the crvs will transform from ‘discontinuous’ into ‘continuous’.

If your crvs have good continuity and you don’t want to join them, but you don’t want the resulting srfs to contain “edges unmerged”, then simply ‘mergeedge’ of those srfs after trim. :tipping_hand_man:

Hi Peter - I don’t know of a way around this - I’ll ask.

@phcreates @DuncanW - for now, maybe, here’s a really quick and dirty edge splitter - guaranteed slightly tested.

TestEdgeSplitter.py (1.1 KB)

To use the Python script use RunPythonScript, or a macro:

_-RunPythonScript "Full path to py file inside double-quotes"

RH-80220 Trim and Edge merging

-Pascal

2 Likes

See attached example, if you join those two surfaces, you’ll notice that the edges on the rounded rectangle now become 1, whereas before the join the arcs are separate / split from the straight edges.
edges.3dm (98.6 KB)

3 Likes

hhmmm, that’s weird and interesting :thinking:

I guess I’m not sure which I’d prefer. Seems like throughout history I do alot of merging of edges from time to time, so I probably don’t see an issue here in this case :slightly_smiling_face:

Is there an ‘unmergeedge’ command? :sweat_smile:

That’s weird, the ‘rebuildedges’ command didn’t correct the original splits either :thinking:

It’s like the edges are permanently joined forever :sweat_smile:

_splitedge
At least as workaround?

The merging behavior is also documented in the help


Joining surfaces to each other may merge split edges, or introduce new splits along the joined edges.

What s your next step, why do you need those split edges ?
Dupboarder before joining might at least allow point snap s.

Did you try joinedge instead of join to bring together 2 surfaces? Does it behave different?

Although I do agree that this is just one of many unnecessary nasty inconveniences that Rhino just carries from one version to the next.
All the little unnecessary nasty inconveniences involved in surface modeling put together are for me a huge time-killer but this one alone is just something I stumble over once in a while.
So I have to ask:
What are you doing that this is repeatedly slowing your workflow?

Wow, in my very limited testing so far, that seems pretty good. I’ll keep testing it & let you know how it goes. Thanks!

Thanks Tom - I’m well aware of SplitEdge (in fact, Joining two surfaces also deletes splits that I’ve made manually using SplitEdge) but that’s only helpful if I know where I need to split it. In which case, I could just snap to that point and wouldn’t need to split the edge in the first place.

My ‘next step’ is simply snapping to a point on a surface edge. I’ll attach what I think might be a useful example that’s similar to what I encountered in real life many times over the last few days (though in most of those cases, the issue happened because of joining surface together, not from splitting with joined curves.)

trim problem.3dm (149.4 KB)

My guess: this merging behaviour is implemented somewhere very deep in the core - and will not change.
Therefor I spread more ideas for workarounds:

(1)
just draw the points in question and pull them to the surface before you trim it.
As far as I know, trim will also pull the curve.

(2)
_dupBoarder (or _dupEdge)
_showEnds (This will show the points in question !!!)
_PointsOn
… snap to point & knot (both should show as hint)

(3)
it also should be possible to find those positions / points by script:

looks like
Continuity.C2_locus_continuous
does the job - but I am always a bit lost to fully understand the different continuities documented here.
If this does not work you may need to address one of the bigger brains at mcneel.

kind regards -tom

I already use those work-arounds, but they slow me way down. I’d rather that Rhino keep the splits the way I’ve set them up in the first place. Pascal’s script, above, seems like it works as a faster work-around for now, and I’ll take a look at Mitch’s solution. I don’t see why you’d think this might be deep in the core, but…I wouldn’t have a clue.

Mitch s script only extracts points of a curve. (so maybe it s not exactly what will give you best result)

Pascals EdgeSplitter - I did not look at the script before posting above - will split Edges at Parameters. (more or less what you asked, more or less automating the splitEdge command)

and mitch s script uses
Continuity.C2_locus_continuous

and @pascal uses
Continuity.G2_continuous

so maybe @pascal can explain the difference between those 2 continuities.

kind regads - tom