Global Edge Continuity - Release Candidate now on packagemanager

These indicate the maximum values found at the edge pair.

  • Absolute curvature deviation = (1/Radius1)-(1/Radius2)
  • Relative curvature deviation = (Radius1-Radius2)/(Radius1+Radius2)

If you run the tool on the attached sample (made by @fares.boulamaali) it might make more sense. The examples on the right show how equal radii can still mean a curvature discontinuity when the direction of the radii don’t match.
surface analysis.3dm (78.4 KB)

I’ve just uploaded a slightly modified version for Rhino 8: (0.9.9.61)
You can find this on _PackageManager

  • improved zoom: should now work on models of any size. Zoom point is the point of max. error
  • dark mode support
  • curve width to adjust the edge overlay thickness (4 seems to work well here)
  • now displays indicators along the curve at fixed intervals based on the amount of samples per edge, rather than min/max. (The min/max settings can be retrieved from the table still, and there is the graph to indicate this) I believe that this is more useful when point editing a surface.

Mac:

Any chance to get these new functions for the Rhino 7 version, too? :slight_smile:

let’s first see if the changes are an improvement. Dark mode support is Rhino 8 only. The Curve width is not needed in Rhino 7. What do you think about the multiple indicators along the curve?

I need exactly the multiple indicators along the edge. This is something I requested long time ago and it’s great that you were able to implement it now. :slight_smile:

Hi Gijs,
Are you planning on integrating g3 continuity values when the cyberstrak plugin will hopefully support g3 blending and matching (already as good as confirmed)?

Thank your work on this excellent plugin.

no, this is not something I have planned, but I’m willing to look into adding it, if someone tells me how to calculate it in the first place. As far as my understanding goes, it means I will have to look up the rate of change of curvature in the direction perpendicular to the two edges. This would mean I cannot derive that at the edge position itself, but need to ‘walk’ on the surfaces. Maybe @Peter_Salzman can shed some light on this.

Hello,

there will be some time before G3 is supported in Cyberstrak. Currently G2 is not yet good enough.

And yes, from an edge or surface curve some walk into the surface is needed to extract curvature and curvature change rate. At VSR we had good math guys (better than me) doing this. But there will be a solution during the next year.

Rate of change of curvature at the edge, needed for G3 continuity, depends on rhe edge control points and the three adjacent rows/columns of control points.

@Peter_Salzman thanks for your reply. For the curvature info I’m not walking on the surface, and to my best knowledge this is also not needed, since curvature is simply derived from the radii at the edges.

@davidcockey indeed the last three control points influence that, and in the ideal case these control points are aligned but there is no guarantee for it. But even if they are perfectly aligned, I think I still need to make a plane perpendicular to the edge, intersect that with the two surfaces and then extract data from it.
Also, I wonder how useful this data is in practice. @norbert_geelen maybe you can explain how you use this data and what it adds to doing a visual flow inspection. Do you need this data for modeling or would you use it only as a mathematical proof of your work?

Just as with G1 and G2 continuity, the data is only a part of the total picture. If there is technically G3 at the edge it still says nothing about how fast that changes on the two surfaces.

The rate of change of curvature along an untrimmed edge can be calculated directly using the four control point rows/columns and knot vectors. A function to do so may be needed.
Calculating rate of change of curvature at interior points such as along a trimmed edge involves more control points.

Hi @Gijs !

Occasionally I notice something weird while using the “Global edge continuity” plug-in. Sometimes visually good transition between adjacent surfaces is being reported with a huge angle deviation that does not reflect the actual angle between those surfaces.

I just noticed a similar behaviour with the attached model. It’s this particular edge here show on the screen-shot:

Test select adjacent surfaces.3dm (475.2 KB)

Yes, that can happen with surfaces that have long edges that are matched against multiple adjacent surfaces. There are two ways to solve this: Join all surfaces (and explode afterwards optionally) or split the edge one ore more locations. I will see if I can find a way around that, but it’s not an easy thing to solve.

Hi Gijs, sorry for the late reply (lost track of this thread during the holidays)

To Your question:
The answer is rather simple:
When I need to design surfaces with G3 continuity, I just want a tool as convenient as Global Edge Continuity to check for what surfaces pass G3 condition.
Currently in Rhino 5 I use VSR/Autodesk’s “Global Matching Analysis” for this.
Of course the necessity for G3 is relatively rare, but does occur when very subtle lead-in to curvature in very prominent surfaces is requested.
At the end of the day, this is why VSR, Alias, ICEM and in the future Cyberstrack do offer the possibility to create G3 continuities.

So the motivation/use case to check for G3 is in principle identical to G1 and G2 (that Global Edge Continuity already offers) albeit less frequent.

Hope that helps, Norbert

Is this the same issue?

@eobet hard to say from a picture, but you should sample with the same density to compare.

Are samples and density the same thing? If so, that didn’t seem to make a difference.

But my main point if you missed my scribbled highlights in the first screenshot is that the table in GEC correctly says 1.2 yet the GEC label in the viewport says something different.

@eobet ah, I thought you were comparing the two tools, so yeah missed that.
I’d be curious to have a look at that. That looks like a different bug.

Just noticed that the difference on the label only appears once you include a third surface (the red one in the below example)…

global-edge-difference.3dm (898.3 KB)

hi @eobet I see now what is happening, it’s not really a bug. When you load the tool, it selects edge 0 and displays the values of that edge. If you select the row in the table, it will display the values for that edge and correctly shows 1.197: