简介这是一套面向C开发者的NURBS开源库源码包版本为3.0.11并针对VS2010编译环境进行了适配。NURBS非均匀有理B样条是CAD、计算机图形学中表达复杂曲线曲面的核心数学工具该库提供了包含控制点、权重、阶数和knot向量在内的基础数据结构和算法实现适合需要在自己项目中集成NURBS建模功能的中高级程序员。压缩包内共253个文件以130个cpp源文件和43个h头文件为主体同时包含dsp、vcxproj、sln等工程文件配合TestWin和Test示例程序。其中TestWin是一个基于单文档界面的交互式应用展示了在GUI环境下进行曲线曲面显示、编辑和交互操作的方法。整个包约828KB小巧完整便于快速下载与查阅。目前已有1049人学习下载。通过研读核心代码与测试用例可以掌握NURBS对象的创建、插值计算以及求交、裁剪等常用操作并理解如何将库集成到VS2010的Windows程序中。1. Nurbs3.0.11 是什么一个能直接算曲线曲面的底层几何库Nurbs3.0.11 是一套用 C 写的 NURBS非均匀有理 B 样条开源库源码工程时代就是对着 vs2010 来组织的。做过 CAD 格式解析、逆向建模或加工路径生成的人应该都有同感真正卡人的不是界面而是拿到一堆控制点之后怎么求曲线上的点、怎么算曲面法向、怎么把结果稳定显示出来。3.0.11 就是干这个的——它把 NURBS 曲线曲面的求值、求导、节点向量管理和基础几何计算封装成可读可改的源代码你编译出库按它的接口把数组传进去就能拿到计算结果。适合两类人一类是要在 MFC 或 OpenGL 老工程里嵌入曲线曲面计算模块的开发者另一类是拿这份源码当对照想真正读懂 NURBS 数学实现的学生。它解决的不是“有没有曲线”而是“曲线怎么算得对、显示得稳”。2. 用 VS2010 编译 Nurbs3.0.11 源码工程入口、三个必改项与接入方式2.1 先看工程结构拿到的源码包里通常有什么一个 VS2010 时代传下来的 NURBS 开源库目录里通常会同时出现 .sln、.vcproj、.cpp/.h 和 examples 子目录。.vcproj 是 VS2010 的原生工程文件格式从 VS2012 起才换成 .vcxproj如果你手头装的是 VS2015/2017也能直接升级打开但升级过程会顺手改掉平台工具集很多老工程就是在这里开始翻车的。我的习惯是按顺序做三件事。第一打开 .sln 后先看解决方案配置管理器确认要编译的是静态库.lib还是动态库.dll。这类库的发布包常见做法是两种配置都预留了但 Debug/Release 默认可能都指向静态库自己心里要有数。第二检查“配置属性 → 常规 → 项目默认值”里的字符集。VS2010 安装默认勾选 Unicode而 2010 年之前的 C 库大量使用 char* 字符串不改字符集编译到一半就会刷 C2664。第三找到 examples 或 test 目录下的入口文件先把这个 demo 编译通过再动自己的代码。把 demo 编通的意义在于它替你把库的依赖顺序、宏定义、链接方式全部验证了一遍。如果这个库带 OpenGL 示例你还能顺带确认 vs2010 opengl 环境下库和渲染代码的配合方式。demo 跑不起来就改自己的调用排查范围会大很多这个学费没必要交。一个常见工程结构的参照表如下具体目录名按你解压出的包为准但一般逃不出这几类目录/文件作用我一般怎么处理src/ 或 geo/库本体源码核心算法只读不轻易改examples/ 或 test/示例工程含入口函数先编译作为链接顺序参考include/对外头文件加入调用工程的附加包含目录*.sln / *.vcproj工程入口按需升级尽量保留原配置编译选项可以先不动用默认配置编一次把错误列表当作信息源而不是事故现场。第一次编译只要不是海量语法错误后面都好办。2.2 三个必改编译选项字符集、运行库、平台工具集下面这张表是我把这类 NURBS 老库接入工程时必查的项按优先级排序。注意每个工程配置Debug/Release、Win32/x64都要单独看一遍因为 VS2010 默认不会把选项同步给所有配置。项目属性默认值常见我一般改成理由字符集使用 Unicode 字符集使用多字节字符集老库内部存储常是 char*Unicode 下字符串解析函数直接匹配不上运行库多线程 DLL/MD与主工程保持一致主工程用 /MT 就用 /MT混用会在跨模块释放内存时崩溃平台工具集v100保持 v100或单独建升级配置升级后编译器对模板和 STL 的诊断变严老代码容易冒新错先提醒一句如果你确认这个库的接口只暴露 double[] 和 int不暴露字符串那字符集反而不用动。但大多数 NURBS 库带文件读写功能处理 IGS、3DM 这类格式时内部必然碰字符串所以这个开关是避坑的重点。改完字符集后如果还有 C2664 报错往往是调用方的 _T 宏写法和库的 char* 风格不匹配不要先怀疑库本身。运行库这一项的表现很隐蔽可能 Debug 下跑得好好的切到 Release 就崩溃或者主程序退出时在 free() 上报堆损坏。原因十有八九是库用 /MTd 编译、主程序用 /MDd 编译两边各持一份 CRT谁分配的内存谁来释放跨了边界就炸。这条我交过学费排查时先统一运行库比对着指针调半天快得多。平台工具集这里多说一句如果你坚持用 VS2010保持 v100 最稳只是注意在 Win10/Win11 上 VS2010 的安装有兼容处理要做代码本身不会因为系统版本变化而失效。如果想升到 VS2015建议单独建一个升级配置去试不要原地升级这样老配置还能留着做对照。2.3 编译产物与最小调用工程把库接进你的代码编译通过后你会得到 nurbs.lib或 nurbs3.dll nurbs3.lib。我建的最小验证工程不写 UI就一个控制台目的就是确认头文件路径、库路径和调用约定三件事。// minimal_test.cpp // 最小验证编译产出的库能不能完成一次“建曲线-求点” #include cstdio #include nurbs/nurbs_curve.h // 头文件路径按你解压的目录调整 #pragma comment(lib, nurbs.lib) // 显式链接避免项目属性配漏 int main() { // 3 个控制点2 次曲线最朴素的组合 double ctrl[3][3] { {0.0, 0.0, 0.0}, {1.0, 2.0, 0.0}, {2.0, 0.0, 0.0} }; double knots[6] { 0.0, 0.0, 0.0, 1.0, 1.0, 1.0 }; // 两端各重复三次clamped 曲线 NurbsCurve curve; curve.SetDegree(2); curve.SetControlPoints(ctrl[0][0], 3, 3); // 点数 3stride3 curve.SetKnots(knots, 6); double pt[3] {0, 0, 0}; int ret curve.Evaluate(0.5, pt); // u0.5 处的点坐标 if (ret 0) { printf(Evaluate failed\n); return 1; } printf(C(0.5) (%.4f, %.4f, %.4f)\n, pt[0], pt[1], pt[2]); return 0; }这个例子里 SetControlPoints 的第三个参数是 stride因为控制点是连续 double 数组stride3 表示每个点占三个 double如果数据里带权重变成 xyzweight 四分量stride 就要填 4。很多老代码在这里把 stride 当成维数传入导致库按错误的步长去读内存曲线形状会莫名其妙地错。SetKnots 传入完整节点向量长度等于阶数 控制点数 1这里是 2136个数对不上时这类库通常不提示而是返回 failed 的求值结果。求值前先打印返回码是我的习惯能少查很多黑匣子。#pragma comment(lib, ...)省去了在属性页配库目录但前提是 nurbs.lib 在链接器的搜索路径里。编译跑通后把求出的 C(0.5) 用手工按 de Boor 算法算一遍三个控制点、二次曲线半小时能算完对上了再继续。这条验证路径能同时确认你的输入约定和库的实现都没问题后面接曲面时心里就有底了。3. 核心计算从控制点生成 NURBS 曲线与曲面权重、节点向量与采样3.1 从控制点到曲线权重和节点向量才是灵魂第 2 章的例子里没提权重。NURBS 和普通 B 样条的区别就在“N”和“R”节点向量可以不均匀Non-Uniform控制点可以带权重Rational。权重为 1 时退化为 B 样条权重不为 1 时曲线会被拉向权重大的控制点。最常见的教学用例是圆弧取三个控制点中间点权重设为 cos(半角)就能精确表示圆弧这是检验一个库是否按 NURBS 完整实现的经典测试。// arc_test.cpp用权重构造 1/4 圆弧验证库的求值精度 #include cmath #include nurbs/nurbs_curve.h int BuildQuarterArc(NurbsCurve arc) { const double r 1.0; const double w std::sqrt(2.0) / 2.0; // 45 度半角的 cos 值 // 控制点起点 (r,0)中间点 (w, w)终点 (0, r) 的对称排列 double ctrl[3][3] { {r, 0, 0}, {w, w, 0}, {0, r, 0} }; double wt[3] { 1.0, w, 1.0 }; // 中间点权重 1对应圆弧 double knots[6] { 0, 0, 0, 1, 1, 1 }; arc.SetDegree(2); arc.SetControlPoints(ctrl[0][0], 3, 3); arc.SetWeights(wt, 3); arc.SetKnots(knots, 6); return 0; }这里有个容易理解反的细节权重不是“越大越靠近”。库内部会用齐次坐标 (xw, yw, z*w, w) 求值最后除以 w 得到欧氏坐标。所以权重为 0 的点虽然参与计算但对应控制点在结果里没有任何影响力权重为负会让曲线越过控制点跑到对面去这在某些造型里是刻意的但新手调试时看到曲线反向飞出去第一反应通常是查数据顺序而不是查权重。权重数组和控制点数组分开传是这类老库的常见接口风格传错维数不报错。我建议在任何调用前先把权重全部置 1 跑一次确认曲线是普通 B 样条形态再逐个改权重观察变化定位问题最快。节点向量是另一个被误解的输入。clamped 曲线要求两端节点重复“阶数1”次degree2 时两端各重复 3 次中间节点可以均匀也可以不均匀。如果中间节点不均匀曲线在对应位置的形状会被局部“拉”这也是 Non-Uniform 得名的原因。调形状时改控制点是第一直觉改权重是第二直觉改节点向量是第三层操作一般不轻易动因为它同时影响多个跨度的连续性。另外注意确认库的参数域很多库对外暴露的 u 范围是 [0,1]但内部节点向量可能是 [0,5]求值前先调 GetDomainStart/GetDomainEnd 看一眼别想当然。3.2 曲面求点与法向为 OpenGL 显示准备顶点数据曲线通之后曲面就是两条方向的张量积。NURBS 曲面在库里通常用 NurbsSurfaceu、v 两个方向的阶数分别设置。曲面求点本质是沿两个方向各做一次曲线求值但显示用到的关键数据不只是点还有法向——法向算得对不对直接决定渲染出来是平滑还是棱角分明。// surface_preview.cpp按网格密度采样曲面生成 OpenGL 用的顶点数组 #include vector #include cmath #include nurbs/nurbs_surface.h struct Vertex { float p[3]; float n[3]; }; void BuildSurfaceMesh(const NurbsSurface surf, int nu, int nv, std::vectorVertex out) { out.resize(size_t(nu) * nv); const double du 1.0 / (nu - 1); const double dv 1.0 / (nv - 1); for (int i 0; i nu; i) { for (int j 0; j nv; j) { double u i * du; double v j * dv; double pt[3], duv[3], dvv[3]; // 一次调用同时返回位置和两个方向的一阶偏导 surf.EvaluateWithDerivatives(u, v, pt, duv, dvv); Vertex vtx out[size_t(i) * nv j]; vtx.p[0] (float)pt[0]; vtx.p[1] (float)pt[1]; vtx.p[2] (float)pt[2]; // 法向 du × dv注意方向约定 float nx (float)(duv[1] * dvv[2] - duv[2] * dvv[1]); float ny (float)(duv[2] * dvv[0] - duv[0] * dvv[2]); float nz (float)(duv[0] * dvv[1] - duv[1] * dvv[0]); float len std::sqrt(nx * nx ny * ny nz * nz); if (len ! 0.0f) { nx / len; ny / len; nz / len; } vtx.n[0] nx; vtx.n[1] ny; vtx.n[2] nz; } } }nu、nv 是采样密度我一般从 32×32 起步大了会卡小了控制点多的曲面会指不准。看起来这只是网格分辨率问题实际上是显示质量和计算量的博弈。EvaluateWithDerivatives 一次调用同时返回位置和两个方向偏导比分别调用“求点”和“求导”快因为内部本来就要算基函数一次算完省一半开销。法向计算的坑在方向。du × dv 的叉积方向取决于 u、v 参数域的方向约定如果曲面绕序和 OpenGL 的正面方向相反渲染出来就是“外表面被剔除”看着像曲面消失了。遇到这种情况不要急着改代码先打印任意一点的 du 和 dv用右手定则比划一下再决定是把 v 方向取反还是把法向数组整体取负。库如果有现成的 EvaluateNormal 接口优先用符号约定多半已经处理过了。采样均匀性也值得说对 clamped 曲面边界处变化快均匀采样会让边界看起来比中间细碎这不是 bug是 NURBS 本身的数学性质。如果曲面在某个跨度内出现明显褶皱先把采样密度提上去排除问题再回去查控制点数据。老库的求值实现相对成熟褶皱绝大多数是数据问题不是库的问题。4. 避坑Nurbs3.0.11 在 VS2010 下编译与调用最常见的 5 个问题4.1 链接报错 LNK2019 / LNK2001Unresolved External Symbol现象编译通过链接时报一堆“无法解析的外部符号”符号名里带 NurbsCurve 之类的类名或者纯 C 函数名。Release 和 Debug 同时出现换平台也一样。原因分三类。一是库编译时的导出宏没在调用方定义库常用 NURBS_EXPORTS 之类的宏区分“编译库”还是“使用库”调用方没定义对应宏链接器就会去找错误的修饰名mangled name。二是调用方用了 C 命名空间而库是 extern C 导出名字修饰对不上。三是库本身没编出来或者 lib 路径没指对这是最低级但也最容易在配置切换时忘掉的。解决先确认 lib 文件确实生成了再看项目属性的链接器附加库目录和附加依赖项。都不缺就去翻库头文件里的导出宏定义把调用方的预处理定义补上。判断是不是宏问题有个快招对比报错符号和库头文件里的类名——报错如果是带 ?EvaluateNurbsCurve 这种修饰形式而头文件声明是普通类名基本就是宏或 extern C 没对上。4.2 运行库不一致导致的内存崩溃现象程序跑起来很正常退出时在 free() 或 operator delete 处崩溃或者 Debug 版没事Release 版必崩且崩溃位置每次不一样。原因库工程和调用工程的运行库不一致。VS2010 里 Debug 默认 /MTd 或 /MDd、Release 默认 /MT 或 /MD。如果库用 /MT 编、主程序用 /MD 编两边各持独立 CRT 堆。库内部 new 出来的内存交给主程序 delete或者反过来跨 CRT 释放直接踩堆。这种崩溃现象时有时无最容易被误判成野指针。解决打开两个工程的项目属性把“C/C → 代码生成 → 运行库”改成一致。团队项目里更稳的约定是统一动态链接/MD 或 /MDd所有模块共享同一份 CRT。排查顺序上先统一运行库再谈别的因为运行库不一致的报错往往出现在离现场很远的位置调指针是白费功夫。4.3 字符集与 C2664string 参数编译不过现象调用库的文件读写接口、或需要传文件名的地方报 C2664提示无法将参数 1 从“const char *”转换为“LPCWSTR”。代码里还可能出现一排常量字符串警告 C4566。原因工程默认被 VS2010 设为使用 Unicode 字符集而库接口是 ANSIchar*风格参数类型对不上。VS2010 创建 MFC 工程时默认勾选了 Unicode老库的代码却是按单字节写的两边在 _T 宏上撞车。解决项目属性 → 配置属性 → 常规 → 字符集改成“使用多字节字符集”或“未设置”重新编译。个别不想动全局字符集的可以对调用处做一层包把库的 char* 接口包成 std::string wrapper主工程继续用 Unicode。但注意包一层之后要处理编码中文字符串会变乱码。老库的历史包袱就在这全局改多字节是最省事的做法。4.4 中文系统上的 C4819 与源码乱码现象编译时刷大量 warning C4819该文件包含不能在当前代码页(936)中表示的字符。或者源码里的中文注释变成乱码个别字符串常量被截断行为诡异。原因老库源码多半是英文加本地代码页GBK注释而 VS2010 对 Unicode 源码文件UTF-8 带 BOM的识别不稳定编译器按系统 ANSI 代码页去解码于是把多字节注释拆错边界。解决不要逐文件改编码。VS2015 以后的编译器支持 /utf-8 开关VS2010 不认所以在 VS2010 下更稳的办法是把 C4819 当成警告先放行把“将警告视为错误”关掉。如果警告量太大影响看错用文本编辑器批量把源码转成 UTF-8 with BOM。我的习惯是保留库源码不动只在编译选项里规避因为批量转码可能引入无声的字符串内容变化相当于给黑匣子换锁。4.5 OpenGL 预览时曲面有缝或曲线锯齿现象用第 3 章的代码做预览曲线看起来是折线曲面片之间有缝旋转视角时缝的位置还会变。光照下明暗过渡呈阶梯状。原因曲线锯齿是采样密度不够。曲面片有缝通常是相邻片各自独立采样求点边界点坐标由两次独立浮点运算产生差出极小量在深度测试下露出来。明暗阶梯是法向没归一化或者用了面法向而不是顶点法向。解决曲线采样改为按跨度span等分而不是全程等分每个跨度内至少 16 段接缝点用同一个 u 值求点保证共享顶点。法向如果库给不出连续的就在采样后做一次法向平均把相邻面片的法向按权重平均。先做这些再谈数据正确性渲染层面的缝基本能消除。共享顶点也做了还是有缝那就回到第 2.3 节的 stride 参数检查是不是坐标读到错误位置——这类“渲染缝”有相当比例是数据源错了。排查这一类问题时我的通用顺序是先看编译期字符集、宏、再看链接期运行库、依赖、最后才看运行期数据 stride、采样。编译期问题好查运行期崩溃最玄学把顺序固定下来比每次都从头猜要快很多。5. 精度与性能把 Nurbs3.0.11 从“能跑”调到“能交付”5.1 公差与求值容差显示用和计算用要分开库内部一般有个全局公差tolerance参数默认 1e-9 甚至更严那是给几何计算用的。但显示用途不需要这个精度1e-4 在屏幕上已经看不出差别强行用 1e-9库会在曲率大的地方疯狂加密采样一个曲面轻轻松松几十万顶点低端机器直接卡死。我一般把显示用公差设在 1e-4 到 1e-3 之间计算用保持库默认。关键是要分清哪些调用走显示公差、哪些走计算公差。比如鼠标拾取曲线上的点放松到 1e-3 没问题但输出给 CAM 的刀路点必须用严格公差。混用之后刀路上会出现肉眼看不出来的波动加工出来就废了这是交付级事故。这个库如果支持 per-call 公差就按调用传参不支持就临时改全局值并在调用后恢复别怕麻烦。5.2 采样密度与跨度优先按跨度采样不要全局均匀采样第 3.2 节我用的是均匀采样那是演示写法。实际交付时均匀采样有两个问题平缓段顶点浪费急弯段顶点不够。NURBS 的节点向量决定了跨度边界库一般会暴露 GetSpanCount 或类似接口正确做法是每个跨度内单独采样再在曲率大的跨度里加密。// adaptive_sample.cpp按跨度自适应采样曲线 // 策略先按跨度铺均匀点再递归细分直到弦高误差达标 #include vector #include cmath #include nurbs/nurbs_curve.h static double PointLineDist(const double p[3], const double a[3], const double b[3]) { // 点到线段距离用于弦高误差判断 double ab[3] { b[0]-a[0], b[1]-a[1], b[2]-a[2] }; double ap[3] { p[0]-a[0], p[1]-a[1], p[2]-a[2] }; double len2 ab[0]*ab[0] ab[1]*ab[1] ab[2]*ab[2]; if (len2 0.0) return 0.0; double t (ap[0]*ab[0] ap[1]*ab[1] ap[2]*ab[2]) / len2; double q[3] { a[0]t*ab[0], a[1]t*ab[1], a[2]t*ab[2] }; return std::sqrt((p[0]-q[0])*(p[0]-q[0]) (p[1]-q[1])*(p[1]-q[1]) (p[2]-q[2])*(p[2]-q[2])); } int SampleCurveAdaptive(const NurbsCurve c, double max_chord_error, std::vectordouble out_u) { out_u.clear(); int span_count c.GetSpanCount(); for (int s 0; s span_count; s) { double a c.GetSpanStart(s); double b c.GetSpanEnd(s); double pa[3], pb[3]; c.Evaluate(a, pa); c.Evaluate(b, pb); out_u.push_back(a); for (int iter 0; iter 8; iter) { double mid 0.5 * (a b); double pm[3]; c.Evaluate(mid, pm); if (PointLineDist(pm, pa, pb) max_chord_error) { out_u.push_back(mid); b mid; // 向中点方向细分 pb[0] pm[0]; pb[1] pm[1]; pb[2] pm[2]; } else { break; } } } out_u.push_back(c.GetDomainEnd()); return (int)out_u.size(); }这段代码里迭代上限 8 次是我在多数模型上的经验值超过 8 次说明跨度本身巨大或公差过严建议先查数据。实现上有意用了循环而不是递归因为递归在密集跨度上可能超过默认栈大小Release 下栈溢出崩溃很难查。max_chord_error 的取值和屏幕分辨率相关1920 宽窗口上0.1 像素对应参数值大约在 1e-3 到 1e-4 之间可以从这个量级起步。5.3 性能缓存控制点没变就不要重复求值交互场景里最浪费的操作是每帧全量重算。NURBS 求值不便宜一个曲面几百个控制点每帧全量重采样即使公差放到 1e-3 也可能吃满一帧。常见的做法是分两级拖动控制点阶段只更新受影响的局部跨度鼠标松开后再全量重建。NURBS 有局部支撑性第 i 个控制点只影响它周围阶数1个跨度。库如果提供局部更新接口就调用没有的话用脏标记任何控制点改动都置脏求值前检查没脏就直接返回上次的缓冲。这样视图旋转操作完全不触发重算流畅度立马上来。具体到工程上我习惯用双缓冲一个只存采样点数组一个存渲染顶点。控制点拖动时只更新采样点里对应的行、列松开鼠标时才把采样点转成渲染顶点并同步 VBO。这个分层让拖拽流畅度和最终精度互不拖累。VS2010 时代 OpenGL 用得多的还是显示列表显示列表对静态模型友好拖动态模型时重建成本高我建议换成顶点数组或 VBO老接口 glVertex3f 逐个提交在几万顶点时指令开销很明显。性能的判断标准就一条拖动控制点跟不跟手。不跟手先看顶点数再看是否触发了全量重算。这两个指标解决了剩下的基本都是公差策略问题按 5.1 的规则去分配显示公差和计算公差就行。6. 用 Nurbs3.0.11 搭 OpenGL 实时预览验证方法与交互技巧6.1 最小预览框架把求点结果喂给 VBO有了库预览框架其实不需要复杂一个 OpenGL 窗口、一条曲线、一个 VBO。关键是把库的求值和渲染解耦——渲染只管顶点库只管算点。// preview.cpp曲线实时预览的最小骨架省略窗口创建细节 #include vector #include nurbs/nurbs_curve.h GLuint vbo 0; std::vectorfloat line_verts; void RebuildCurveVerts(const NurbsCurve c) { line_verts.clear(); std::vectordouble us; SampleCurveAdaptive(c, 1e-3, us); // 按第 5.2 节的规则取采样点 for (double u : us) { double pt[3]; c.Evaluate(u, pt); line_verts.push_back((float)pt[0]); line_verts.push_back((float)pt[1]); line_verts.push_back((float)pt[2]); } glBindBuffer(GL_ARRAY_BUFFER, vbo); glBufferData(GL_ARRAY_BUFFER, line_verts.size() * sizeof(float), line_verts.data(), GL_DYNAMIC_DRAW); }GL_DYNAMIC_DRAW 用于每帧都可能变的缓冲如果曲线只在拖拽时变用 GL_STREAM_DRAW 更贴近场景模型加载完就不动GL_STATIC_DRAW 性能最好。这三个枚举选错不影响正确性影响驱动层优化路径属于新手容易混淆的小细节。6.2 验证方法拿圆弧做测量用控制点做交互写完后先跑一个数学上已知的测试用第 3.1 节的 1/4 圆弧作输入在每个采样点上把库算出的坐标和理论圆方程比较打印最大误差。这个测试会第一时间暴露 stride、权重、节点向量三种参数的接法问题。几何对了再去调相机、光照都不会被底层错误干扰。交互方面我的做法是把控制点渲染成可拾取的小方块鼠标拖拽时只调用 RebuildCurveVerts 重算曲线不要动曲面。等曲线手感对了再按同样的套路上曲面预览。这个顺序能把“几何写错”和“交互写错”两个变量分开。调试 NURBS 库这些年最大的心得是先在数据层确认几何对再开显示层——显示层的问题一大半是几何层带进去的。这套流程走完Nurbs3.0.11 对你就不再是黑匣子而是一个能算、能看、能调的可用内核。希望帮到你。本文还有配套的精品资源点击获取