xNURBS Grasshopper

@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.

I’ll ask Xnurbs for the API dll . Thanks!


Hi @Gijs, I have the .dll from Xnurbs. Please send me the definition when you have a chance. Thx!


@gustojunk I will send you soon, this one is just using some input curves, extruding them as reference surfaces for G1 boundaries, then filling them with XNurbs surfaces.:

The handle is this patch which is then mirrored over y and z:


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.

Looking forward to try this workflow!


yes this is possible, I sent you the component to test by pm

hi @Gijs does this Componet and Api finish and can we Test it?

@Rh-3d-p I’ve sent you the component by pm. Note that you will need a license of XNurbs and ask them for the right DLL for it to work.

1 Like