3dsmax 2021 material editor rollout S L O W

[Oleg_Budeanu]

Hi everyone
I am going nuts with 3dsmax 2021 material editor menu. Every time I switch material in material editor (compact) it redraws every dialogue box, button and etc. And that is VERY VERY VERY annoying. It slows down the work incredibly.... Is there a solution for this thing?
Thanks!

[fixeighted]

Did you switch back to native Max swatches?
No idea what kind of ubersupercomputer we need for the Vray version but that is usually the issue

[Oleg_Budeanu]

Did you switch back to native Max swatches?
No idea what kind of ubersupercomputer we need for the Vray version but that is usually the issue

Nope, that's not the refresh of the material preview - that the refresh of the dialogue itself. And all the 3dsmax dialogues!
I am using threadripper 1950x 32gb ram and GTX 1050

[fixeighted]

Very odd and annoying yes.
I haven't seen this behaviour here.
I guess you tried it on a clean scene and it is the same, so I'd guess it is something local, needing a reset of some sort.
Or possibly a plugin conflict? I know Substance can cause annoying slowdowns.

[rusteberg]

[fixeighted]

Hehe, very appropriate for many situations...

[Oleg_Budeanu]

Ok, after digging I've found this:
https://knowledge.autodesk.com/suppo...core-CPUs.html
The environment variable helped. I used the "d3d" option. It is still annoyingly refreshing, but about twice faster now.

[fixeighted]

Interesting - thanks for the link.
Currently I don't experience any of these issues, with a 3950x/2080ti, so I guess I chose accidentally luckily.
I hope one of the fixes helps you

[^Lele^]

TL;DR:
I have ran tests yesterday, and the results seem fairly conclusive in pointing out that - at least for max 2021 and an GTX 1080 under windows 10 - the Angle - D3D9 option is by far the best choice.
The other two angle modes, along with the full OpenGL implementation of QT, all suffer from *terrible* performance, with hiccups in drawing times and haphazard cores usage.
So, the two system vars and their values would be:
QT_OPENGL = Angle
QT_ANGLE_PLATFORM = d3d9

Longer form:
Here's a link at the google sheet with the results.
The test consisted in maxscript creating and destroying 100 times a dialog with, alternatively, 100 different type of UI elements: 100 buttons, 100 spinners, 100 mapbuttons, labels and so on.
Max was full-screen, no other application was open, and there was absolutely no third party draw on cpu or gpu (my windows 10 is severely tamed in terms of what happens in the background.).
If you see jumps in times, those were repeatable, and only with dx11 or warp.
In other words, buttons truly get slower to create and redraw after a few have been drawn overall (some cache filling? who knows.) in dx11.
None of this had anything to do with V-Ray specifically, either, as it all ran "headless" (i.e. with absolutely no link to any engine's feature. just the d3d part of max.)
Warp (the software emulation) and d3d11 will also use two logical cores from the pool to their maximum, moving one of the two logical cores around.
This may well clash with, f.e., an IPR or a material render, thereby slowing down UI redraw even more.

Lastly, and very importantly, when all is said and done, UI redraw is down to how many controls one has.
The physical material, f.e., lacks a number of mapping entries, and doesn't have *any* map influence spinner.
The spinners alone, on average, take 5 ms each in the default d3d11.
Make 20 of those, created even if the rollout is folded up, and that's a tenth of a second right there, if one is lucky and doesn't get into QT hiccupping.
Just the dropdown with the material presets costs 18ms, and so on and so forth.
Things add up and line up with the worse of QT's habit, the slowing down after enough controls have been drawn.
You'll need to restart Max often (i can't believe i'm writing this) to not get into these kind of troubles.

So you know, the move to QT in nuke, over a decade ago, was not well received at all by the compers i knew and worked with, for exactly the same reasons: the UI became a *lot* more sluggish and laggy and they'll tell you that to this day it's still nowhere near the original ui's speed.
But QT's a lot cheaper to create with, than it would be starting everything from scratch.
Make what you wish of this.

EDIT: to be fair, in our case the issue is not Qt, but the translation *to* Qt of the max standard controls.

[fixeighted]

Cool...valuable info there.
Does any of this suggest that we may gain improvement by switching options even if we currently can't
directly perceive a slowdown?
If so, then what method can I employ to test the various options...is there some script I can run with each to assess?

[^Lele^]

I can surely share my script, but it requires some work from the user's part (i.e. i hardcoded paths for the sake of speed, and for what worked for me.).
I would say that if you are fine with what you have, the difference in performance is going to be negligible, the risk outweighting the potential benefits (even if it's easy to revert QT to defaults by removing the two system variables).
If however one is ripping their hair out because of the UI drawing speeds, then perhaps they should try the d3d9 option and see if things go (marginally) better.

[fixeighted]

Ah ok, thanks; I will save potential stress and leave it as it is then

[Oleg_Budeanu]

Lele, thanks a lot for taking the time to do these tests!
I wonder if that gets better with better GPU? Mine is quite old - GeForce 1050 Ti.
It's just unbelievable that in 3dsmax 2021 we should deal with UI issues !!! Just unbelievable!

[^Lele^]

It's all unfortunately down to the CPU.
I know the options speak of direct3d, but in the end it's two CPU cores being tortured, and the GPU sitting idle.

[Oleg_Budeanu]

It's all unfortunately down to the CPU.
I know the options speak of direct3d, but in the end it's two CPU cores being tortured, and the GPU sitting idle.

I wonder if someone could compare Intel vs AMD in this case. Intel should be better, right, assuming it has better single-core performance?