How to do CurvatureGraph on a split/trimmed edge?

I’d like to do a curvature analysis on a split edge to check for G1 or G2.

Is there a way to accomplish that without using DupEdge first?

I do not see a way currently, no.
Are you thinking allowing SubObject edge curve segment selection as input for the CurvatureGraph command or something different?

That sounds neat!

I must admit, I haven’t looked into sub object selection in Rhino yet, so I should go and read up on it (I’ve only noticed that some commands, I think, automatically goes into such a mode, like ExtractSrf for example, and that it works despite what your current object filter settings are, which is good).

In the V7 WIP, DupEdge knows about History - that is probably the cleanest way to get this graph in a useful way.

-Pascal

1 Like

Hi @pascal, are there any plans of curvature combs for surfaces (U and V direction)?

Hi Norbert - I am not sure I understand the question - CurvatureGraph works on surface U and V and always has as far as I can remember - the graphs are drawn on surface isocurves only, is the problem for this particular topic…

-Pascal

A post was split to a new topic: Wish: Option to invert curvature graph?

So, the trend for me lately on this forum seems to be to point out inconsistencies in the Rhino tools…

I just noticed that BlendCrv can take surface edges (even in curve mode) to blend with, which basically treats the edges as curves for the purpose of the tool… yet CurvatureGraph, which also accepts both curves and surfaces, as mentioned cannot do this (EDIT: Match can also match a curve to an edge, without the need for DupEdge).

The threshold to learn Rhino at first appears very low due to how similar each tool behaves, yet after a while, with these small differences in behavior that you need to memorize, it’s paper-cut upon paper-cut upon paper-cut… easy to learn, but very tedious to use in the long run… other professional tools are usually difficult to learn, but then become incredibly efficient after a while… boy I wish McNeel would spend a year unifying all tool behavior and options instead of adding new features (or at least making sure that new features feel consistent, unified and flexible)…