Better curve surface support



I am a total stranger to the blender community, devs and the codebase, just tried to read a lot last few days. I seem to see blender giving in to the urge of embracing CAD software eventually.

I like mechanical engineering, tried few months ago to 3D print from those guys Projet Hévéa, or just fiddle with the Nash-Kuyper sphere in Blender and it sucked :confused: .


How are the efforts coordinated between those different projects :


The post from Goudey mentions :

Curve support in geometry nodes has also provided an opportunity to significantly improve the internals of the curve code. A large portion of the existing curve code in Blender dated back to the it’s initial open source commit, 19 years ago!

@ChengduLittleA is the code for NURBs that you mention concurrent?

I would love to find an educated read to wrap my head around :

  • the current scope for curve & surface modelling in Blender,
  • things that are absolutely not desirable / out-of-scope for Blender (some complex Riemann surfaces possibly, the mentioned overly CAD-ish constraint approach?),
  • lists of features/QoL that could fall in scope - type of surfaces / operations (Coons patches / holes, more refined control over the NURBS knot vectors…). Saw such nice comprehensive list of user stories for the asset browser
  • the math support from the currently available libs in Blender

This is really cool to see people motivated to bring progress to curvatures !


I really appreciate your work in this area. A refreshed and extended workflow for nurbs with a proper I/o is needed in Blender so thank you for tackling this project.
Maybe even this project could be integrated in some way: STEP import - Released Scripts and Themes - Blender Artists Community

1 Like

For me the first thing to do is the import and export of nurbs models and not in STEP but in IGES. IGES is the preferred format to exchanges file between Alias CATIA and NX and ICEM Surf and is widely adopted still today.


Hi there!

How are the efforts coordinated between those different projects

This project is mainly aimed to improve curve support for trims and holes and also file io that allows blender to open and edit curve brep files like step/iges/3dm easily. This could include a better curve core data structure, I haven’t really looked into the difference between the node implementation that @HooglyBoogly is working on and the legacy curve code though.

That UI think is mostly for editing interaction.

is the code for NURBs that you mention concurrent?

I think we complement each other. The node is supposed to be a parametric approach to the free hand editing that blender already has.

the current scope for curve & surface modelling in Blender,

If to put it simple… You can make a surface of some shape, that’s it. You can’t punch holes, or bevel easily, or trim them with another shape, etc…

things that are absolutely not desirable / out-of-scope for Blender (some complex Riemann surfaces possibly, the mentioned overly CAD-ish constraint approach?)

the math support from the currently available libs in Blender

It’s very likely that I’ll use OpenCascade as the core for the curve triangulation backend, So whatever it’s supported in there, it can be implemented into blender as well. I’m not entirely sure what specific functions that will or will not fall into the scope, but like NURBS knot vectors, that should be easy to implement, we just need to figure out an appropriate way to manipulate them on the ui.

@JanErik with a proper I/o is needed …

This is also gonna be handled by OpenCascade (and maybe rhino’s 3dm lib as well).


Thank´s ChengduLittleA!
It´s great News that you are targeting the Nurbs implementation in Blender-
I took it for granted, that nobody would care about the VERY basic implementation at all-
but the impressive Blender development in the past years, a lot of industrial designers and also automotive designer and modelers came to try out Blender- and saw the potential!
I can only hope that blender developers realize the growing community in the design field as well-
and start adressing US intheir roadmaps as well :slight_smile:
Generally from an designers/modelers perspective there a 3 main Topics on how Blender can be of value in our workflows.

  • the first and fundamental step is of course getting the Surface Data into Blender-
    here two things are important, to keep the Nurbs Data “alive” but also to be able to tesselate the Surface data in a clean and controlled way-(from all i hear, moi 3D does a the best job at the moment- even quads!) keeping as much File structure as possible would be of great importance as well
    (Material assignment, groups, layers etc)

  • Rendering and Animation, this is of course already possible to an extend.
    important again to keep file structures- using FBX format or even better using
    GitHub - jesterKing/import_3dm: Blender importer script for Rhinoceros 3D files
    when coming from Rhino or
    Export Blender | Alias | Autodesk App Store
    when coming from Alias.

  • and then of course there is the topic of modeling
    implementing precise nurbs aligning/matching and trimm tools inside blender is for sure the most difficult task- its really a deep rabbithole from what i understand.
    But even if we only achieve basic nurbs modeling functionallity,
    global and (control)vertex level manipulation with the already existing Poly modeling tools, it would already be such great step in the right direction!

I cannot be more excited about this project :slight_smile:
can you share maybe a roadmap of yours what do you want to archieve, also in which order or to which extend?
Just as JLBohm mentioned earlier, I would as well be happy to help with some insights from the automotive modeling perspective!

Thanks again, James


Hi Jimmy!

Yes, the surface data should be able to preserve inside blender and tessellated with the curve backend. This would require a lot of improvements on the curve to be able to represent them.

Currently, STEP/IGES/3dm all have open source i/o code available, it should be relatively easy to implement into blender.

Modelling wise, Hans was more keen on using geometry nodes first. Of course regular modelling is a must have.


Hi ChengduLittleA, but what does “and maybe Rhino” mean? What does this entail a complete abandonment of the work done previously?

Blender Nurbs already have a very good visualization only thing missing in the code is the support of the trimmed surfaces, wouldn’t it be useful to start solving this problem in the existing Blender code?

Is possible to integrate Blender Nurbs instead of using external libraries, and use these only to communicate with other programs such as for import and export?

OpenNurbs and Open Cascade Technology has the same license GNU GPL V. 2,

About trimmed surface tessellation on GPU, I found just now this PDF maybe can be useful.

However, I really hope this is the right time, because we have been talking about this for over 15 years, I still remember Nurbana Wiki Blender**, oher info on Archi-wiki

Nurbana code donated to Blender year 2003

Users campaign for Nurbs integration in blender

“and maybe Rhino” mean?

it has a 3dm lib, which is included inside that 2014 nurbs branch, it’s not working very well with compiling on linux, I had to change a lot of stuff.

only thing missing in the code is the support of the trimmed surfaces

That problem alone would need a very different way of tessellation, otherwise those hole/trims can’t be connected correctly. Beside this, the old code is very hard to maintain.

Is possible to integrate Blender Nurbs instead of using external libraries, and use these only to communicate with other programs such as for import and export?

If we want to display those surfaces, we have to have at least the visualization part of those external libraries included.

Open Cascade doesn’t do GPU tessellation AFAIK, so that may be a slight turn down.

Anyway. I’m squeezing out time to do this. I shall write something workable in blender after I figured out how the existing stuff is intertwined there.


Short update: Got a bit time today and I was able to modify my test code to compile against a fully statically linked open cascade. This configuration would make it easier to include the library into blender, no need for DLLs and stuff.



Managed to read raw (?) geometry data from step using open cascade today, such as Nurbs pole/knot info and the face topology. Now I get a better understanding of how those geometries are represented, I’ll need to study more files and geometry combination to know how to design the new representation data structure inside Blender.


Do you need some test

1 Like

Please. But I need simple ones, best if it’s just one curve surface with trimmed edges/holes, because I’ll be manually inspect the geometry representation there. No need for an entire model.

I’ll not be doing anything today. I’ll check those later.


We had the same idea, anyway here some files… available for free

Novotechnik IGES STEP model

Kniel IGES model


Tried very simple examples with various edge cases, if you need something more complex or specific or different formats just poke me.

google drive

Also a question: Did you consider “Curve on surface” concept for this implementation? Meaning curves that are internaly projected onto a surface for trimming.
In Rhinoceros, when you untrim a surface the information about former trimming curves is lost (at least to my knowledge).
Much more useful is to keep those projected trimming curves around in UI and using them to trim surface again or as inputs for various tools. These curves are permanently bound to a specific surface
…name “Curves on surface” is taken by major nurbs modeling software, so “Projected curves” could be the name for instance…

thank you


Did you consider “Curve on surface” concept for this implementation?

I’ll likely go for project cut/boolean kind of approach, because according to OpenCascade document and some user reports, it only runs correctly when you guarantee the “cut curve” is exactly on the surface of the one being cut. And if it’s on a flat surface it’s gonna be okay. I have not yet tested how bad/good the support is, but the document seem to guarantee it will work if you do a extrude then boolean kind of approach. Hard to know, maybe the tolerance is bigger than I though it might be. I’ve checked the hole selection is based on winding direction, so whatever method we use, we can still achieve hole-in-ring kind of topology without an issue.

So based on your description, I think it’s possible, so basically there’s a trimming curve, and internally it’s extruded and boolean-ed with the surface being cut, then that curve can be reused as well. In principle it can work this way, but I’m not exactly sure if it will create extra geometries during the boolean procedure, and it seems that editing a opencascade topology is quite tricky. I spent a lot of time just wrapping my head around the APIs


This is a whole other topic, which is basically inverse engineering… It’s possible if your model is completely a subsurf model, then nurbs should be able to represent that pretty well.


I was using @PaoloFurani 's test model, it doesn’t really show up correctly in FreeCAD. I’m not yet sure if it’s FreeCAD failed to handle the hole or if it’s due to lack of support in OpenCascade. I think to ensure good representation of those brep geometries, Imay need to implement more geometry types inside blender curve (like line/circle… stuff), Or I need to internally convert all surfaces to Nurbs.

(I removed the screenshot because it’s from another software and I don’t think it’s appropriate to do it here.)

I was then able to boolean this geometry to get a hole in freecad. So in theory it should work if I implement the data exchange layer of blender <-> opencascade as well.

Later update:

The file is incorrect. I got a new file and the trimming shows up correctly.

I update my progress on my blog (in Chinese) as well in case anyone being interested in any more detailed coding refs…


Initial thoughts on how to design the trimming data structure representation in Blender:

The root problem now as far as I can see is that Blender’s internal surface (Nurb) doesn’t do surface+curve combination. Which means, it’s either a surface, or it’s a boundary (which is represented as a 1xN surface instead of a MxN surface, so naturally it becomes a line). To represent trimming (both holes and boundary trimming), we need to have the ability to include curve, or at least “sub curves” into surface data structure. So this is the basic idea.

I think I may be able to reuse some of the stuff in Blender’s curve as well, but because the projection cut result is always represented in nurbs curve format, it may not be ideal to store that with a quite heavy structure. Here is the best use for that “1xN” nurbs. So maybe what’s lacking is just this simple thing.

The data inside Nurb itself is quite cleanly laid out. I should be able to work on top of it instead of rewrite the whole thing. After all the bare bone nurbs doesn’t really need much changes.

Some initial thoughts on the UI/editing:

Although Nurbs patch is strictly “square” in its nature, I think we can (and need to) still extrude branches and “f” regions. This should be handled internally with a connected tangent (may or may not be continuous in D2+), so the face is visually connected, and can be edited just like a mesh, but the “connectivity edge” can optionally provide natural hard edge, which is very beneficial to hard surface modelling (much like weighted subdiv on mesh).

I don’t yet have a good solution to hole punching. The best if holes can be represented dynamically/non-destructively, but this is not quite possible with imported shapes, because those files doesn’t have the cut projection info preserved. I haven’t thought of a good way to edit those “pre-cut” holes other than to put it in a uv-image editor (because those are uv-space curves essentially).


Since I kinda get the OpenCascade part figure out, I shall next make it work with Blender, initially in two parts:

  • Discretizer back-end repacement for existing nurbs surface object.
  • igs/stp file i/o operators. (But without holes and trimming).

At the mean time I’ll work on the implementation on the Nurb struct, and see if I can get a proof-of-concept trimming system to work.


I kind of like the idea to have an UV image editor displaying/showing the 3d Trimmcurves/regions in a 2D representation! Nurbs modeling Software does this(i guess) as well, but I never saw a real 2D Editor view of the Trim Curve relative to the UV parameter space… could be very interesting/informativ!
That is prettymuch what Josefs “Curve on Surface” question was all about… Its how Alias handles it.
In Alias, the trim-curve is kept as a 2D(*) curve in the UV parameterspace of the Surface, and can be reused, combined(with other intersection/projection trim Curves) or simply deleted. for a workflow, Its very fast and flexible compared to triming in Rhino or Icem, where you don´t have access to those curves


Hi Jimmy! Thanks for the info! I’ll look into it. However I don’t think generic step/iges files are able to preserve those. Internally it can be done of course.

(Also you may want to remove the screenshot of other software especially commercial software… It’s typically not allowed here due to copyright and similar reasons)