I’ve searched the first few pages of the forum and didn’t see a post mentioning this issue, so forgive me if it’s a repeat.
We are running v.5.2 on Max 2021 across multiple workstations, and after the update to 5.2, I am unable to drag and drop a bitmap file to a map slot in a Vray Material.
Before the update, you could drag and drop any valid bitmap file to any of the material’s map slots (either the little box next to the parameter, or the wide rectangular box down below), and the material would automatically create a basic map to reference the JPG / PNG / whatever.
Right now the workaround is to first create a VRayBitmap, then browse to the file from within Max, etc etc… It’s not a fast workaround, so it would be really nice to have the old way back!
Can anyone else confirm that this is indeed an issue? Thanks!
Wow, that is kind of shocking to hear, to be honest! I’ve used that feature since before time. Thanks for logging it - hopefully it comes back with the next update.
It turns out this is caused by the QT updates to some V-Ray shaders, described in the update thread here. These UI updates were implemented (and this feature has been probably missed) for some Autodesk shaders back in 3ds Max 2020 as well (i.e. Physical Material does not work with the drag and drop logic also). In other words, it’s an Autodesk issue.
Ok, good to know. Thanks! Does this mean the drag & drop feature can’t/won’t be added back by Chaos? We’ve been toying around with updating to 2022 anyway (usually we skip a year before updating).
You should still be able to drag and drop a map unto a vraybitmap *path*, for it to get filled with the bitmap’s.
It doesn’t need to be empty, either: you can do so many times over, and it will be overwritten each time.
Yeah it doesn’t need to be empty but you still actually need the Vray bitmap entry there first, so for new materials that is the easy method I use, rather than searching through folders.
Of course it would be lovely if it worked as scanline does, just straight drag/drop to any slot, but that’s unlikely to happen, though why I’m unsure.
That’s what it looks like, yes.
Although i wouldn’t be too harsh with them: i know for a fact that they *are* doing a *lot* of unseen work to modernise Max, and touching very very old code is bound to throw up odd surprises.
Let’s hope they are easy fixes.
True; I like 22…they made some good progress. It’s just an ingrained reaction to criticise the software we’ve all been glued to for decades
Sorry AD, we love you really;)
So the advantage of the QT update is that the RMB behavior is the same as in Max? For me it would be a much bigger advantage to be able to drag & drop maps into their slots. I use it dozens of times per day.
Couldn’t you consider waiting with the QT update until AD has fixed the issue (perhaps in version 2025)?
The update to QT speeds up UI redrawing tenfold.
We had to move away from the old controls ASAP.
We can’t unfortunately revert the changes (we’d be lynched by a few of our users, i’d wager.), and will have to work with AD to solve the standing issues.
You can stay in 5.1 should you need the feature more than the UI speed, though (well, you’d also miss out on other things, ofc.).
