Between Max9 and Max2008 it seems that Autodesk decided to change the behavior of the Map Channel spinner in the UVW Unwrap modifier. For 9 versions of Max that spinner would change which set of UV data was being worked on. For Max versions 10+ that spinner now copies the UV data from channel 1 to whichever channel you select. There is no change to the labelling in the UI to alert the user to this new behavior. The new “improved” workflow to change which channel you are working on is to set the spinner to an existing channel, click the Reset button, and then answer Yes or No to a warning dialog.
(scratches head)
As we here at Volition migrate from Max9 to Max2009 this is causing some consternation amongst the artists. It’s just too easy for them to accidentally blow away a meticulously crafted UV channel.
I had the idea to write a scripted modifier that extends Unwrap UVW so that we could recreate the historical workflow of “spinning the spinner selects a UV channel without overwriting it”. I very quickly had a working prototype with an additional map channel spinner that did a .mapChannelSet() and .reset(). The first thing I discovered was that the warning dialog spawned by .reset() is not suppressable. Setting QuietMode to true does nothing. I’m glad I’m not having to write a batching tool that would need to interact with the Unwrap UVW modifier UI.
Other than that little hiccup the extra spinner worked as expected. But, it still represented a change in workflow for the artists. Since the destructive Map Channel spinner was still on the UI, and they were naturally inclined to spin that one, the chance of an inadvertant map channel overwrite still existed. Looking through the MaxScript help docs I noticed that there were now (probably since Max 2008) a lot of new methods exposed for the Unwrap UVW modifier. Enough methods, it seemed, that I would be able to easily recreate the default modifier UI and just replace it. If I were to do that, with the new Map Channel spinner working as expected, then all the artists would have to do would be to remember to use vUnwrap UVW instead of Unwrap UVW.
Yeah, no…
A bug now exists in the Unwrap UVW modifier. As far as I can determine it exists in 2009 and 2008, but not Max 9. If you create a scripted modifier that extends Unwrap UVW and has replaceUI: set to ‘true’ then Max will crash when you place that scripted modifier on a node. It crashes hard, too. An instantaneous “An error has occured, blah blah blah” dialog and then an exit to the desktop, regardless of whether you click OK or Cancel on the error dialog.
Of course, the replaceUI:true bug doesn’t exist in Max 9. But, that doesn’t really matter since a)Max 9 has a good implementation of the Map Channel spinner and b)Max 9 doesn’t have the exposed Unwrap UVW methods that would allow you to create a replacement UI.
Don’t you just love it when 3dsMax ‘improves’ its workflow. Meaning screwing up the workflow of so many.
i remember a similar thing happening with the Skin modifier when they added SkinWrap.
Suddenly ‘skin-wrap -> convert to skin’ would set the max. number of bones to 3, meaning you would loose all skinning data for bones #4 and higher.
Why didn’t they just make a copy/paste for UV channels (which really already exists anyway via the channel tool) instead of messing with that spinner.
Like you said, it seems very open to user error.
The Unwrap modifier used to be exposed to the SDK, so my recommendation would be to check if it still is and if so, comment out the ‘UV copy’ portion inside the spinner code, recompile and distribute that version to your artists.
This is where i just keep my opinions to myself, cuz ‘nothing’ good will come of it.
I have a question though…
I have been thinking of extending the unwrap options in Max2008 for my studio’s workflow. nothing serious just some automation and maybe a lil’ layout utility for lightmaps, the usual flavor: no overlapping, consistent texil ratios yadda yadda…
Will I run into this headache? I’m not a max expert atm, and I’m afraid of traveling down this road and finding a huge roadblock like Jeff did. I’d rather just avoid it if I can.
[QUOTE=kees;2161]
The Unwrap modifier used to be exposed to the SDK, so my recommendation would be to check if it still is and if so, comment out the ‘UV copy’ portion inside the spinner code, recompile and distribute that version to your artists.
[/QUOTE]
That’s what I did yesterday afternoon, Kees. As far as I can tell it’s a ~14 line change that isn’t predicated by any of the other additions made to the UnwrapUVW modifier. I diff’d the Max2009 file against the Max9 version and set the spinner code back to what it used to be.
[QUOTE=PaK;2162]This is where i just keep my opinions to myself, cuz ‘nothing’ good will come of it.
I have a question though…
I have been thinking of extending the unwrap options in Max2008 for my studio’s workflow. nothing serious just some automation and maybe a lil’ layout utility for lightmaps, the usual flavor: no overlapping, consistent texil ratios yadda yadda…
Will I run into this headache? I’m not a max expert atm, and I’m afraid of traveling down this road and finding a huge roadblock like Jeff did. I’d rather just avoid it if I can.
-R[/QUOTE]
If you want to extend the modifier it looks like you are free to add to the existing UI without problems. If you try to replace the UI on your extended modifier you will be in for a world of hurt. I’ve bugged the issue to Autodesk, but they’re out until 1/5 so nothing will happen on that issue any time soon.
If you want to add to the UnwrapUVW Edit window…well that’s a whole different can of worms. That window is driven by one large macroscript file. You can’t do a scripted extension to it, like you can to a modifier. The only way to extend it is to get into the macroscript file that drives it and muck about in the code directly.
if there’s a dialog you cannot surpress there is a -ahem- workaround using a callback which I have used to automatically click ‘ok’ on the load envelope weights dialog as I couldn’t find another way to do this at the time. would this work for you?
lookup UIAccessor.PressButtonByName fuction and see if it can help.
[QUOTE=wallasaurus;2169]if there’s a dialog you cannot surpress there is a -ahem- workaround using a callback which I have used to automatically click ‘ok’ on the load envelope weights dialog as I couldn’t find another way to do this at the time. would this work for you?
lookup UIAccessor.PressButtonByName fuction and see if it can help.[/QUOTE]
Cool tip, Chris, thanks! Since I ended up going the route of editing the actuall modifier code, instead of extending it via MaxScript, I removed the warning dialog calls at the source.
Hmm, it’s a good thing we’re still on Max9. Some of the recent things like this just drive me bonkers (Scene Explorer… Let’s not go into that discussion…)
[QUOTE=Jeff Hanna;2170]Cool tip, Chris, thanks! Since I ended up going the route of editing the actuall modifier code, instead of extending it via MaxScript, I removed the warning dialog calls at the source.[/QUOTE]
Then Jeff: Can we get the modified code from you?
That would make you into our hero!