Render dialog and light lister QT

[TubeSmokeGuy]

Hi!

Is the main VRay render dialog in the current Beta 6.00.00 already in QT? Just asking because it doesn't get wider on horizontal pull, like the Arnold dialog does. Is this intended?



I also noticed, that the action that switches ALL rollouts from default to advanced and back, takes still really long. Shouldn't that be better with QT?



And finally, the VRay Light Lister seems not QT-fied yet, is it, will it?




Thank you and greetings!

[^Lele^]

To know if a dialog is in Qt, all you need to do is to drag it around.
If you wish you never did, then it's not Qt.

Ours isn't, at the moment (being worked on still.), but i hope it doesn't do what the Arnold one does, personally.
Keeping mouse (and eye) travel low is a priority in good UI design, and travelling half the screen to get to the next spinner isn't quite that.
Tabbing works only so long as the controls are all declared in the right order, and it's never been a good way to navigate the Max UI because of this (in the Arnold UI as well. Keep tabbing, you'll see.), so i don't expect it to work unless the dialog is rewritten from scratch (and even then, it may fail in places.).
Alas, not my choice to make.

Everything that has to do with controls creation and redraw will be quicker, so we expect those to be so as well.

The light lister isn't going to get changed to Qt, that i know of, as it's dynamically built Maxscript.
It'd need coding in C to work, but i don't see that planned right now.

[TubeSmokeGuy]

Okay thanks!

Just wondered because of the release notes.

Modified feature

V-Ray

• V-Ray Implement Qt based UI for V-Ray/GPU render settings dialogs;

On Arnold dialog, the user has the choice to widen or narrow as he wants. When you make it narrow you have the low mouse travel that you mentioned, when you make it wider, the mouse travel is bigger but it also looks not so squeezed and someone may like the better overview. It depends on personal preference and taste. Having a choice is good - I think.


For the light lister, you can make QT UI for maxscripts using python. No C needed.

[^Lele^]

For the light lister, you can make QT UI for maxscripts using python. No C needed.

Are you familiar with how the lightlister code is?
Adding python and trying to create dynamic controls doesn't look trivial, considering how old the whole codebase is.

Of course, if you have better ideas (particularly if in the form of script snippets), we're all ears.

On Arnold dialog, the user has the choice to widen or narrow as he wants.

That's a way to put it.
The other, is that someone's been lazy, and forgot to add the parameter to fix sizes, so now as the dialog is made wider, the UI elements stretch, and the layout goes in the bin (see where the checkbox for the preview is gone now.).
My vote remains no.

[^Lele^]

Also, correction, *it is* in Qt, but just for CPU, you're right.
The speed for the move to advanced is about 2 seconds in all, for me, while it's instant for individual rollouts.

EDIT: re-correction as both CPU and GPU have been ported to Qt.

[TubeSmokeGuy]

Okay, so no Light Lister in QT. For me thats one of the most frequently used dialogs with VRay, so I personally think a QT conversion will be worth the effort.

The widen / narrow of main render dialog is secondary to me, even if I thik it could be "nice to have" and would feel "more modern".

What I thik is critical, is the lag of the "all rollouts default to advanced switcher". You're making a new product and I think this should be solved. For me it doesn't feels good in this state. It's simply too slow and the "close and re-open behaviour" feels ugly. Just my feedback.

[^Lele^]

Okay, so no Light Lister in QT. For me thats one of the most frequently used dialogs with VRay, so I personally think a QT conversion will be worth the effort.

No Qt with Maxscript + python.
A rewrite in CPP isn't on the cards right now, but the VRay camera lister is already in cpp, and Qt.
If it was requested enough (limited resources...), it's not a stretch to think it could be built the same way: It'd have definite benefits.

What I thik is critical, is the lag of the "all rollouts default to advanced switcher". You're making a new product and I think this should be solved. For me it doesn't feels good in this state. It's simply too slow and the "close and re-open behaviour" feels ugly. Just my feedback.

It is ugly, and this is why i was mentioning Qt and dynamic UIs for the light lister.

There may be margin for improvement, but the Qt support in Max hasn't been exactly stellar so far, forcing the coders to take sometimes circuitous paths to get to a given result (particularly if you have to support various versions of the DCC and so various stages of implementation of Qt.).

Not to worry though, the proper dev is reading you.

[vlado]

Is the main VRay render dialog in the current Beta 6.00.00 already in QT?

Only some rollouts are in Qt currently. We are working on them one by one (there are lots of them ).

Best regards,
Vlado

[^Lele^]

Only some rollouts are in Qt currently. We are working on them one by one (there are lots of them ).

Oh, this explains why.
Parts seemed Qt, others not quite. And depending on which panel was open, performance (dragging it around) would change.
Was going loopy.

[TubeSmokeGuy]

Alright, thanks for clarification.

Another one - whats with "Render Elements" tab? Is this an Autodesk task or can you QT-fy it? I think Autodesk won't touch it anytime soon, since Arnold uses AOVs and the other native renderers that use render elements are more or less legacy features.

[matanov]

Another one - whats with "Render Elements" tab? Is this an Autodesk task or can you QT-fy it?

Autodesk's.

[TubeSmokeGuy]

Alright! I created a feature request, feel free to vote . The more the better. https://forums.autodesk.com/t5/3ds-m...idi-p/11235862