It looks like the update to Rhino 8.9 introduced some changes in behavior in the Curve extension methods, more specifically DivideByCount seems to be behaving differently. [Source]
In our particular case, the array that is returned seems to have the order of points reversed and shifted. In the image attached, I am calling something to the effect of:
Point3d[] pointsOnRect;
myMesh.GetNakedEdges()[0].ToNurbsCurve().DivideByCount(divisions, true, out pointsOnRect)
(I am showing Rhino 7 behavior on the left as I cannot run Rhino 8.8 and 8.9 side-by-side but I can confirm that everything worked fine until R8.8)
At first glance this looks like a trivial fix but it is not, as in our case of Eddy3D. It is possible that there are more breaking changes that I have yet to identify. Are these changes documented somewhere? I’d like to get this fixed as soon as possible.
hi @patrick.kastner do you have a sample file and code that we can run? That way I could test it on my end and see if the current Rhino SR matches what you are expecting.
Please find the examples below. I actually just tested these on my Macbook and they behave identical on Rhino for Mac. They do not behave the same on my Windows machine. Please let me know your thoughts.
thanks for the samples. After digging a bit deeper it turns out that the source of the issue is at the creation of the nurbscurve from naked edges.
I’ve logged: RH-84227 Curve from naked mesh edges behavior
GetNakedEdges calls RhinoMergeCurves, so this may well be related to RH-81815. Setting UseLegacyCurveJoiner to “Yes” should make Rhino use the old version of RhinoMergeCurves, and that may fix the output in this case.
From my understanding of the issue some under the hood changes in Mesh.GetNakedEdges caused this change for you. I don’t believe it’s a regression as you might be relying on behavior that you shouldn’t have.
Can you elaborate a bit? I’m trying to understand how you expect the naked edge curve to be structured based on the input mesh.
Based on this simple plane example it seems like you want the curve seam at the final vertex and oriented counter clockwise in the plane. Is that generally the case?
Mesh.GetNakedEdges is pretty naive. It just scoops up all the naked edge lines and joins them. Changes in output ordering of joined curves caused this issue. When we change the curve ordering in the output for someone we break someone else’s plugin relying on a specific order. Even still I could change curve joining to make this specific example work but I have no idea if that resolves every problematic example you have. I’d prefer we not play whack-a-mole with changing the ordering and instead try to make your plugin more robust.
Based on Chucks comment here we also don’t promise the ordering to be a certain way. One big reason is that would limit our ability to update and improve the functionality. We provide the key for which inputs became which output and then expect the caller figure out what processing needs done. One option is create a Mesh.GetNakedEdges overload key to let you know which edge became which segment of the resulting curve. I’m also happy to hop on Zoom or whatever and we can figure out. Just let me know.
@eddy3d, since the 8.9 update has affected the ordering of joined curves, it has caused issues for plugins like yours. Just giving you a heads up on this topic.
McNeel seems open to feedback from the community to better understand how plugins like Eddy3D expect the curve ordering to behave. What do you think would ensure compatibility moving forward so we can continue using your plugin smoothly?
@Joshua_Kennedy, I understand that fixing this might not be trivial, as you rightly pointed out. And possibly there could be more breaking changes. Given given that Eddy3D for now is the only case known (at least it seems) you use that as a default case to restore the point ordering for the time being??
@crz_06 Answering on behalf of @eddy3d. It’s totally fine that the behavior changes, but I would expect this to happen only for major version upgrade, say from Rhino 8 to Rhino 9, not necessarily from 8.8 to 8.9. I say this since users frequently update minor versions without thinking about it. They usually forget about the update and then get upset at me, asking why the plugin “stopped working”.
@Joshua_Kennedy Thanks for posting here and sorry for bothering you!
Can you elaborate a bit? I’m trying to understand how you expect the naked edge curve to be structured based on the input mesh.
It’s not that I want anything in particular, we just set everything up according to how things behaved and now they behave differently. If I know that changes are coming (say for Rhino 9) it would be easier to react and prepare.
Based on this simple plane example it seems like you want the curve seam at the final vertex and oriented counter clockwise in the plane. Is that generally the case?
It would make sense to me that vertex 0 would start in the corner (see below), but I am not really in a position to say anything since I am not privy to your other dependencies and constraints. Is there a particular reason why this was changed? Offsetting it by 1 seems arbitrary.
Even still I could change curve joining to make this specific example work but I have no idea if that resolves every problematic example you have. I’d prefer we not play whack-a-mole with changing the ordering and instead try to make your plugin more robust.
This is the only broken situation, yes. You are correct, the plugin could have been coded more robustly. I wasn’t aware of the overload you mentioned and will take a look.
One option is create a Mesh.GetNakedEdges overload key to let you know which edge became which segment of the resulting curve. I’m also happy to hop on Zoom or whatever and we can figure out. Just let me know.
I’d appreciate it if you had a couple of minutes via Zoom, would you mind reaching out to me via email?
The actual change was to try to order joined curves same way they came in if the ends don’t match. This was too fix someone else’s grasshopper definition which assumed results would be in a certain order.
I spoke with Joshua and will have to implement fixes on my end of to make the code compatible with future versions of Rhino. This should not impact you in the meantime—if you upgraded to Rhino 8.9 or beyond already, here is a link to downgrade to Rhino 8.8.
Hi Patrick,
can you shed some light on the release of your code to make it work with future version of rhino? Are we talking R9 or something more short term (weeks/months) with a new beta release from Eddy?
I am asking as I am working 2 projects in parallel, one depending on eddy so that is now 8.8. But everytime I need to do the other project I need to install the latest build as i is depended on a bug fixed in 8.12. So basically, i am installing rhino like several times a week … as I have not found a way to get an alternative method around the bug as to get both working on 8.8
