The sketch shows the initial geometry on the left. In the middle you can see the ids and tags of the entities. All quads are 1x1 units. The origin is at vertex 8. On the right side you can see the geometry after the first subdivision step.
I want to compute the subdivision point e of edge 10 (smooth). The edge connects vertex 8 (COrner) with vertex 2 (SMooth). The subdivision point is defined by:
T … location of vertex 8 = (0; 0; 0)
S … location of vertex 2 = (0; 1; 0)
A … subdivision point of face 3 = (-0.5; 0.5; 0)
B … subdivision point of face 6 = (0.5; 0.5; 0)
and θ = α / k.
α … smaller angle of the sector = 90°
k … number of faces within the sector = 3
As a result, I get e = (0; 0.283494; 0) while Rhinos _subdivide computes e = (0; 0.258519; 0). This result would correspond to θ = α / (2n).
Thank you for reporting this, we found that there was a bug in our computations of corner sectors coefficients. Just like you found out, we computed θₖ=α/(2k) instead of θₖ=α/k. This impacts only smooth edges connected to a corner vertex at one of their ends.
Your results are correct and OpenNURBS isn’t.
I hope to have this fixed for the next release of Rhino and OpenNURBS (7.17), and will clearly control the impact of that change so that files can be corrected safely when opened in Rhino 7.17. Here is the work item: RH-67377 SubD Core: Edge sector coefficient evaluation is wrong for corner vertices.
Out of curiosity, how did you come across this error? Where you comparing Rhino against other software, or against published SubD rules? I’ve had a lot of difficulty finding other software where I could clearly apply this particular subdivision rule.
tl;dr
I came across the bug when reprogramming the Rhino algorithm in C# and comparing the result with the paper. Unfortunately, I have also not found any other program to compare results in a reliable way.
Full story:
I am implementing physical computations with freeforms (meshes, NURBS, SubDs,…) in an interactive CAD-integrated framework for Grasshopper. To increase performance and flexibility I use Algorithmic Differentiation. This technique has to be applied directly to the SubD algorithm. Therefore I rebuilt the relevant parts of the code in C# based on the OpenNurbs repository and the Rhino documentation. Afterwards I read the corresponding papers more in detail (yes… wrong order…) and came across this mismatch.
Some first prototypes:
Interactive computation of minimal surfaces using Updated Reference Strategy and SubDs in Grasshopper:
Elastic beam:
A larger form finding example where the simulation takes longer. However, it is much faster than our old C++ code:
Hi Thomas, thanks for the reply and very neat videos! Super interesting project and I’ll be looking forward to the next updates.
As you saw OpenNURBS is far from being AD-friendly, its focus is elsewhere. However I’m curious, are there things you thought we could do to help integrate Rhino with design tools using AD or more generally efficient and flexible scientific computing projects?
For example, would specialized NURBS and SubD evaluation functions in ON be interesting, if they were faster and with more control on the low-level memory layout of the input variables than what we currently offer? We could also provide derivatives of these wrt variables like control points, could that be used from your C# AD framework for example?
Also with the object creation and modification functions, any particular pain points in your use case? Do they get in the way of making interactive modifications possible or are they fast enough compared to the rest of your computations?
I am very interested in the .NET 6 integration which seems to be already in progress.
Beyond that, there are actually some geometry features that could be implemented in OpenNURBS and Rhino. I also suspect that some are already implemented but not yet exposed.
Feel free to contact me via mail for further discussion.
