In this first post from Chaos' Innovation Lab, we're taken through the laborious path that leads to the Qt-fication of V-Ray's UIs under Autodesk 3ds Max.
Libraries, Libraries…
3D Studio Max is an old giant of the industry, nearing 30 years of age.
We’ve enjoyed a strong relationship with it for the best part of that period, and most importantly shared cherished memories of each time the appearance of new technology needed to make its way into users’ hands.
One such improvement has been the adoption of the Qt libraries for the Max UIs, with hidden work inside of Max starting about version 2017, the first Qt UIs appearing for version 2018, and some work still ongoing.
Qt’s introduction aims to supplant the aging Win32 library with a modern set of functionality, higher speeds throughout, and cross-platform capabilities.
The testing
To prove the points made throughout the post, I will refer to my findings on tests I performed a few years ago, and remain valid in what they show, and some that have been retested on very current hardware and software.
I’ve benchmarked the time it took to redraw the complete UIs of three key materials: V-Ray Material, ALSurface and FastSSS2, as they are central to many workflows, and contain many UI controls.
The material editor was stretched to the maximum height so as to ensure all possible controls would be drawn, and the rendering of the previews was deactivated.
The times were taken 100 times, and averaged.
The results will be mentioned where pertinent in the post.
A gilded past… that never was
What was felt as adequate, or even quick, a decade ago was perceived as such because the whole experience, from the speed of the hardware, to our expectations, allowed it.
We were, in other words, proportionally less sensitive to the issue than we are today.
To put this theory to the test, I endeavored to benchmark with the last version of V-Ray 3.x (3.7), on Max 2015, as this version is wholly Qt-free.
The speed measured therefore is that of the native Win32 Controls, more or less in their best shape ever.
The VRayMtl class took 1.6159 seconds to redraw
VRayALSurfaceMtl took 1.2955 seconds, and VRayFastSSS2 took about the same time with 1.2655 seconds.
Dragging the Material Editor or the Render Settings window around in Max is painfully laggy with the mouse cursor well elsewhere while the windows hopelessly try to catch up with it (and taking nearly a full second to do so, on powerful current hardware.)
This is a testament to the foresight of Autodesk’s developers, noticing the performance was becoming inadequate, and introducing Qt early.
Kudos.
Growing pains
While the Qt-fication of Max was ongoing, about Max version 2018, we started getting reports of UI slowdowns, some of which were big enough to not be attributed simply to a user’s tired workstation.
It’s around this time that I took on to benchmarking the various Win32 UI components’ performance, to find that they could show erratic redraw speeds.
Likewise, windows became exceptionally long to open, sometimes taking handfuls of seconds, and got even more laggy when moved around over the rest of Max’s UI.
The issues were due to Max’s automatic translation of Win32 controls to Qt versions, a process that on many-core machines with lower per-core clock boost, would turn into a workflow-impairing issue, from mere nuisance it was on lower-cores, higher-clock CPUs.
It was far from ideal, but it wasn’t optional: compatibility needed to be maintained while the transition to Qt happened.
However, this impacted every UI control, resulting in severe lag, intermittent slowdowns, and a general sluggishness: after all we had very, very many of those controls in use throughout all our UIs.
To quantify the drop, here are the results of testing the same V-Ray version (3.7) with Max 2018:
VRayMtl: 2.5436 s.
VRayALSurfaceMtl: 2.0685 s.
VRayFastSSS2: 1.9779 s.
It can be noticed that the slowdown is proportional and affects all equally, by about 63%.
All the while, the first native Qt dialogs appeared, for example in the Autodesk Physical Material, and they were exceptionally quick where Win32 lagged: up to ten times quicker redrawing specific control types, like spinners or drop-down menus.
The attentive reader will have noticed each run became slower and slower.
It was another issue with that specific Max version: one that compounded our misery in particular circumstances (for example during long lookdev sessions), while it did nothing to slow down Qt perceptibly.
It was apparent that we needed to turn to native Qt as well, because the benefits were simply too big to ignore, and in any event our old house was already on fire.
Paradigm Shift
Writing UI in Qt’s native approach wasn’t straightforward: there is hardly a match between the approaches, methods and controls with the old Win32, so UI code has to be rebuilt from scratch.
This means retyping every label, re-ranging every spinner, re-setting the defaults for every item, tuning behaviors for the various controls, and so on and so forth. Ideally, of course, without impairing user experience and efficiency.
The Fiddling
It’s fair to say we didn’t get it all right the first time around: some unexpected, and often unwarranted, behavior cropped up as the devs started working on the UIs, and for a while there was also no fix possible.
The various Qt components would not be the same size as the old Win32 ones, so alignment was thrown off pretty much everywhere.
Further, the default approach for new controls was relative positioning, not absolute; the default policy for controls was auto-scaling; the various behaviors markedly different from what was expected from them as direct continuation of the Win32 library (for example in material and map buttons.), and so on and so forth.
The litany of mishaps we faced made it clear the integration had to go hand in hand with that of Max itself, and its maturation of the integrated Qt libraries.
Not having the luxury of time, we resorted to huge amounts of painstaking, manual, menial labor so that UIs would look coherent, and behave functionally. Luckily, many UI layouts in V-Ray were automatically generated (for example, the UI of most render elements, or the VRayALSurface material, or the VRayDirt texture) and shared common code and this made things a bit easier.
Still, by the time we were finished with the first proof-of-concept UIs, it was apparent the amount of work needed to complete the transition to Qt in a timely fashion was enormous.
All hands on deck!
The needed effort was met head on to ensure we could ship a first interim conversion step in time for the release of Update 1, with the whole of the vMax team (the developers working on V-Ray for 3D Studio Max) enrolled to work on Qt-fication.
The sheer number of UI controls across every V-Ray dialog meant that the work still required many days of dedication from the whole team, and this in turn put a strain on them, as the other tasks couldn’t be left waiting.
It’s fair to say it has been an intense period for the vMax devs, but the quality of the results made it all worth it.
State of Play
As of V-Ray 6.0 Update 1 (or 6.1), the transition to Qt libraries is essentially completed.
Materials, Maps, the various Nodes, Modifiers and every ancillary window that could be turned to Qt has been converted.
A few minor parts are still left to be translated as they do not lend themselves to it (f.e. The aging light lister.), and we reserve some more time to collect user feedback and opinions on the new controls’ layouts and behaviors, so as to better complete the translation, and maximize the user’s quality of life.
There remains some behavioral limitation that will need to be taken care of, partly by ourselves, and partly as a byproduct of the maturation of the integration of Qt libraries into Max itself.
The transition is not yet fully complete, so kindly expect some more adaptation time.
Was it worth it?
Yet, we feel vindicated in putting the effort into this endeavor, and quite refreshed by the numbers we gleamed:
The VRayMtl under Max 2023 and V-Ray 6.1 now draws in 0.4664 seconds (even if it gained a few more controls to redraw since v. 3.7!), the VRayALSurfaceMtl takes 0.3621 seconds and the VRayFastSSS2 only 0.2857 seconds.
In all cases, the redraw of controls happens so fast that the eye can’t see it.
Likewise, the window dragging is instantaneous, the window glued to the mouse cursor.
This means current Qt UIs are three to four times quicker than native Win32 ever was, and up to seven times quicker than translated Win32.
The last word, however, has to come from you, our users: please take the time to try out the latest V-Ray 6 update, and let us know how you found the new look, speed, and usability of the Qt UIs.
More about V-Ray 6.1
V-Ray 6.1 includes many other improvements as well. For more details read here. You can check out the full changelog is available in this doc.
