Here’s what I took out from the extensive discussion in this thread and the many others that were linked from it. It is a request for a curvature analysis display mode that focuses on visually finding the areas that form concave dips, convex bumps, or are planar for some tolerance, in a surface.
Actually fulfilling that request will need trial and error, and there will be ample time to adjust it depending on your feedback, either now or later when there are actually images to show.
RH-75092 CurvatureAnalysis: Make a mode for analyzing bumps above/below tangent plane
Plus two other requests for things that were discussed here and are more straightforward:
RH-75093 CurvatureAnalysis: Make a signed mean curvature display mode
RH-75094 Zebra: Make a mode that displays dots instead of vertical or horizontal stripes
They were invented for this thread and do not need to be used again. I just felt like it was the easiest way to make sure we all had the same non-standard definition of these concave areas that should show up in the new display mode. And to highlight the fact that with these definitions, concave + convex + planar areas will leave two other types of local regions uncolored.
@gustojunk I still do not understand why or how you would use Zebras (or dots) to find areas with single curvature. Gaussian curvature is the usual tool for this.
I think those terms are really on point, specific, useful. Imho.
Looking at some “threshold” to distinguish flat from non-flat, having negative, zero, positive curvature for 2 directions (min and max curvature), we have 5 “levels”:
-2 double convex
-1 single convex (conic, cylinder, developable)
0 flat
+1 single concave
+2 double concave
A gradient with 5 colors would be best.
Making a guess:
Zebra stripes width should be constant at any view angle, while looking flat surfaces. (probably isn’t currently) Each stripe should be equal to a tot amount of normal angle change.
Concave/convex curvature should translate in decreasing/increasing in stripe width.
If dots/leopard instead of stripes/zebras, we should have circles while looking at planes and bigger/smaller circles while looking at concave/convex spherical surfaces (where min/max curvature are equal).
(note this implies with parallel projection view we shouldn’t view circles with flat surfaces, camera lens length take a role in the size of circles, maybe).
Back to your question: developable/conic/single curvature surfaces should have elliptical dots with smaller diameter equal to circle diameters on flat surfaces.
Derivative and stuff…
Just mumbling. I might be wrong on multiple levels.
Hi @pierrec, sorry for being prescriptive of how to implement what I need. It does not have to be dots or zebras. I simply want a clear way to know looking at a model where in the topology the form is (as described by Riccardo):
Enabling curvature graph on ALL edges of a SubD is not ok.
With big SubDs, it kills performance and clogs the viewport with countless graphs/hairs.
Using History=on, extracting some edge, and doing curvature graph on those edges only, is faster (performance-wise) and way more useful (and analyzing only what the user want, not everything)
Please consider making it possible to select SubD edges for curvature analysis.
PS Even curvature analysis would be super if applied only on some SubD faces, faster computation, hopefully.
This follows the same logic of ‘all or nothing’ also used for SubD cage/smooth mode. It’s a simple and elegant way for programming, UX and user understanding.
It is also however, extremely simplistic and limiting for those working on complex projects/variants//models where having hundreds of parts and millions of polygons is the norm, and this current design/programming limitation renders Rhino unfit to do our work.
I LOVE the new feature about having curvature graph directly on SubDs , with graphs projected to normal direction! (and whoever did it):
That’s a killer feature that could lead me to buy an upgrade alone.
Sadly it was very bad implemented.
As already said:
but also, the new type of curvature graph on SubD have the “hairs” always normal to surface! That is what we need!
The workaround of extracting edges with history is faster but give a different result. (not projected to normals)
You guys have a pearl there, a gold nugget, a fantastic tool… utterly and completely bad implemented.
On my machine, on Rh7, I can work with a SubD of about 5k faces and curvature graph on some edge extracted with history on. 60fps.
On Rh8, same SubD, curvature graph on the whole SubD kill the performance, to like less than a frame each 3/4 seconds… and the visual is completely clogged by hairs.
Indeed! I need 5-30 edges most of the time! … not 10’000!! The cpu/gpu are working for nothing!
Curvature graph scale is the same value for everything, on some part of the subd (with quads) the U direction would need 105 scale, the V direction would need 130 scale.
Doing every edge together is a bad idea. Absolutely.
Like: “We know how to do it! You can see it! … but we won’t properly implement it…”
…?? WHY?
It’s a killer feature right there!
I paid for 8. Where do I have to pay more to have this working properly?
(Can I access to the method for normal hairs via rhinocommon? c++?)
Please!
…
PS
Having a negative scale, so putting the hairs in the opposite direction, would be extremely useful too. Letting one works from the inside of a SubD.
… and this could/should be a not-too-complex edit in the code … maybe? … hopefully…