@mikko has done some work on this recently to preserve edge indices where possible. This work is done in Rhino 8. That being said, it won’t be perfect. We recently discussed this topic and according to our devs tackling that requires a whole new way of dealing with edges. Most likely this means we need to step away from edge indices and give edges unique ids instead. So this won’t happen for v8 anyway.
The way I’ve always done it in gh is to insert a point close to the edge, and search the closest index to that point to find the right edge index. This is a more robust way where you can still use edge indices to feed into components that need it, like FilletEdge.
If you request the XNurbs api dll from xnurbs support, which you can get as a customer (ask for the v7 one) then I can share with you these prototypes to test them out.
Any improvement on preserving edge information is welcome.
When Rhino was develop there was no Grasshopper, no SubObject editing, no SubD topologies, etc. it made sense then that object IDs existed only for surfaces and no for any sub-object level entities.
Now, the fact that I cannot name, tag, reference, etc an edge and treat it as a proper entity it doesn’t make sense anymore. Also in Rhino history and GH we should be able to associate an edge to its creator. For example: ‘the edge of this surface that is the result from this input curve.’
Hopefully a future version of Rhino can address this for nurbs, meshes, and SubDs. Their subobjects should all have IDs.
Hi Gijs, That’s really nice. In the first screenshot it looks like you are using the output surfaces of the script as input for more surfaces, and doing that a couple of times?
This is the limitation that direct Xnurbs in Rhino cannot handle. It only has 1-generation history. It cannot use history based Xnurbs surfaces as input for more Xnurbs patches and maintain/update history if the initial curves are changed.