在这个 Chaos 创新实验室的首篇文章中，我们将透露 Chaos 团队在 Autodesk 3ds Max 中，V-Ray 用户接口的 Qt 化的艰辛研发历程。
函式库啊，函式库...
3ds Max 是古老的行业巨人，已有 30 年的历史。
一直以来，Chaos 与 3ds Max 保持着密切关系，最重要的是在每次新技术的出现，要交给用户时，彼此都能共享这些珍贵回忆。
其中一项改进是 Max UI 采用了 Qt 函式库，Max 内部在幕后的改版大约从 2017 年版本开始，第一批具有 Qt 的接口在2018年版本发行，当今任务仍在进行。
引进 Qt 的宗旨在于用一套现代化的功能取代陈旧的 Win32 函式库，整个速度更快，新的接口还支持跨平台。
效能评测
为了验证 Qt 接口更有效率的观点，将参考我几年前进行的测试结果，这些结果仍然有意义，还有些是在当前的硬件与软件上重新测试的。
我对重新绘制三种关键材质的完整用户接口所花费的时间进行基准检验。V-Ray 材质、ALSurface 和 FastSSS2，因为以上材质是许多工作流程的核心，并包含许多 UI 控件。
我把材质编辑器拉伸到最大高度，以确保所有控件都绘制出来，并停用了渲染预览。
我测量了 UI 加载时间 100 次，然后取平均值。
测试结果将在文章中说明。
看似美好的过去......其实并非如此
十年前的 UI 速度感觉是足够的，甚至觉得速度很快，因为整体经验，从硬件的速度，到用户的期望，都满足这点。
换句话说，以前我们对 UI 加载的敏感度比今天要低。
为了检验这一理论，我努力用 V-Ray 3.x 的最后版本（3.7）在 Max 2015 上进行基准检验，因为该版本上完全没有 Qt。
因此，这些测量速度的数据是基于原生 Win32 控件的，或多或少处于最佳状态。
VRayMtl 类别花了1.6159秒来重绘。
VRayALSurfaceMtl 花了1.2955秒，VRayFastSSS2 也花了差不多的时间，为1.2655秒。
在 Max 中拖动材质编辑器或渲染设置窗口时，鼠标在其他位置很痛苦地延迟，而窗口却无望地想要追上鼠标（以当前强大的硬件，几乎需要整整一秒钟才能做到这一点）。
这个测试证明了 Autodesk 的开发人员的远见卓识，他们注意到性能的不足，并提前引进了 Qt。
感谢 Autodesk 开发人员。
成长的痛苦
进行 Max 的 Qt 化时，大约在 Max 的 2018 版，我们开始收到关于 UI 速度减慢的报告，实在慢太多了，因此不能简单地归咎于用户过度使用的工作站。
就在这时候，我开始对各种 Win32 UI 组件的性能进行基准检验，结果出现了不稳定的重绘速度。
同样，窗口的开启时间变得特别长，有时需要几十秒，而且在 Max 的其他用户接口上移动时，会变得更加延迟。
问题是由于 Max 将 Win32 控件自动转换成 Qt 版本，整个过程在每核时钟较低的多核计算机上，会变成影响工作流程的问题，而在低核、高频率的 CPU 上，算是小小的问题。
这离理想状态很远，但这样的转换是无可避免的：由于在过渡到 Qt 的过程中，需要保持兼容性。
然而，这影响了每个 UI 控件，导致了严重的滞后、产生间歇性减速与普遍的迟钝：毕竟我们在所有的 UI 中都有大量的控件在使用。
为了量化降速，以下是用Max 2018测试相同V-Ray版本（3.7）的结果：
VRayMtl: 2.5436 秒
VRayALSurfaceMtl: 2.0685 秒
VRayFastSSS2: 1.9779 秒
您会发现，减速是成比例的，对所有 UI 的影响都一样，大约是63%。
与此同时，第一批原生 Qt 对话框出现了，例如在 Autodesk 物理材质中，它们在 Win32 滞后的地方特别快：重新绘制特定的控制类型，如微调器或下拉式选单，新的 Qt 接口比旧版速度快了 10 倍。
细心的读者会注意到每次运行界面都变得越来越慢。
这是那个特定的 Max 版本的另一个问题：在某些情况下（例如长时间的视觉开发），会加重UI滞后的痛苦，尽管没有显着减慢 Qt。
很明显，Chaos自己的软件也需要将UI转换成Qt，因为其好处太大了，而且无论如何，老屋子已经着火了。
典范转移
用 Qt 的原生方法编写 UI 并不简单：在做法、方法和控件之间几乎没有与旧的 Win32 相匹配之处，所以必须从头开始构建 UI 程序代码。
这意味着重新输入每个页签，重新排列每个微调器，重新设置每个对象的默认值，调整各种控件的行为，诸如此类。当然，理想的情况是不损害使用者原有的体验与效率。
调整的过程
这样说吧，我们第一次并没有把事情做对：当开发人员开始在用户接口上工作时，意想不到的，而且往往是不想要的行为出现了，经过一段时间也无法修复。
各种 Qt 组件的尺寸与旧的 Win32 组件不一样，所以几乎所有的地方都需要调整。
此外，新控件的默认方法是相对定位，并非绝对寻址；控件的默认策略是自动缩放；作为 Win32 库的直接延续，各种行为明显不同于人们对 UI 的预期（例如材质和贴图按钮），等等状况。
我们遇到的接连失误让我们清楚地意识到，Chaos 所导入的 Qt 接口必须与 3ds Max 本身的整合以及其 Qt 库的成熟度并驾齐驱。
由于赶时间，我们采取了大量艰苦的手工劳动策略，以便使 UI 看起来连贯一致，并能在功能上发挥作用。好在，V-Ray 中的许多用户接口布局是自动生成的（例如，大多数渲染元素的用户接口，或 VrayALSurface 材质，或 VRayDirt 纹理），并共享共同的程序代码，使改版变得更容易些。
然而，当我们完成了第一个概念验证的 UI 接口时，发现要及时完成 Qt 的转换，需要耗费庞大的工作量。
全体总动员!
为了确保我们能够在发布 V-Ray Update 1 之前及时完成第一个过渡的转换步骤，我们正面迎击这个任务，整个 vMax 团队（也就是V-Ray for 3ds Max的开发人员的简称）都参与了 Qt 化的工作。
每个 V-Ray 对话框的 UI 控件的数量之多，意味着这项工作仍然需要整个团队付出许多天的努力，而这反过来又给他们带来了压力，因为还必须处理其他任务。
可说，对于 vMax 的开发人员来说，时间紧迫，但高质量的结果使一切努力都值得。
实际运行状况
从 V-Ray 6.0 Update 1（或6.1）开始，向 Qt 函式库的过渡基本上已经完成。
材质、贴图、各种节点、修改器和每一个可转为 Qt 的辅助窗口都已经转换完毕。
仍有些小部分有待转换，因为这些并不适合 Qt（例如，古老的 light lister。），我们还保留了时间来收集用户对新控件的布局和行为反馈与意见，以便更能完成转换工作，并将用户体验提升至最大。
还有行为上的限制需要处理，一部分是由我们自己经手，另一部分是由于将 Qt 库整合到 Max 本身所产生的副作用。
这一过渡还没有完全完成，所以各位要有心理准备面对更长的适应期。
这一切值得吗？
没错，我们觉得为这项工作付出的努力是值得的，而且得到的实测数据也令人振奋：
V-Ray 6.1 for Max 2023的 VRayMtl 的绘制时间为0.4664秒（即使 V-Ray 从 3.7 版开始多了更多控件需要重绘！），VRayALSurfaceMtl 需要0.3621秒， VRayFastSSS2 只需要0.2857秒。
在所有的情况下，控件的重绘都发生得如此之快，以至于肉眼无法察觉。
同样，窗口的拖动也是瞬间完成的，好似窗口粘在鼠标上。
