New unwrap UVW modifier "set material ID" feature breaks the modifier stack

[hardrock_ram]

So in 3dsmax 2017 the unwrap UVW modifier has a new "handy" Material ID selection ...

The problem is that it overrides the material IDs I have set on a lower level in the stack. Yes, the unwrap modifier is supposed take matIDs from the stack when it is first added (doesnt work properly of course), but it won`t change again if something is changed lower down in the stack (naturally).

The problem is that 3dsmax have a modifier stack that I use extensively. This means I might have several unwraps in the stack, along with several symmetry modifiers (and others) to relieve myself from a lot of unwrapping. And finally I might set material ID s at different stages of the stack, although it usually happens on the bottom (mesh) level.
Now, this workflow is broken. The whole point of a modifier stack is that if I want to unwrap the model at a certain level, I add an unwrap modifier. If I want to change my material IDs, I do this with a seperate modifier.  By combining it, we only lose flexibility. I can no longer change material IDs down in the stack if there are unwrap UVW modifiers on top of it. And I can no longer use the symmetry modifier to propagate material ID changes if there are unwrap UVWs on top.

So now ALL my old scenes are broken, the modifier stack is handicapped, and my script to work on material IDs on many objects at once have to be redone and made more complicated to take the whole stack into account.

Please tell me I got this all wrong and that there is actually an easy fix!

[Alfred.DeFlaminis]

Hello @hardrock_ram,

Thank you for your description of this particular issue.  I've been testing and researching this for a day or two now.  Following your detailed description I was able to easily reproduce this behavior in 3ds Max 2017 and it was logged in our bug tracking system with a reference to this thread. 

I have spent some time in 2017 trying to find a workaround and I have found one may be of use to you.  Hopefully it can tide you over for the time being. 

Once you use the Unwrap UVW to set an ID, make sure there is an edit poly above it on the stack.  If you do this, future copies of the modifier will not overwrite ones that exist below it or prevent new ID's from being entered on the upper unwraps.  It's one more step to your workflow, but it does stop this from happening, at least in my tests. 

Thank you for detailing this problem, I appreciate it.  I hope my workaround helps you.  If it does not, please post a sample file with the problem and I'll look further into it so your workflow is not affected.

Please hit the "Accept as Solution" button if my post fully solves your issue or answers your question. This lets me know that I was effective in helping you, and thank you for doing so.

Best Regards,

[hardrock_ram]

Hi Alfred,
I am not sure you understand the problem, or if I misunderstand yor solution. I could not get around the problem in any way.

On a principal level the problem is this: The Unwrap_UVW-modifier now has the ability to set material ID`s. This means it interrupts an operation where it shouldn`t, and where it previously did not.
I use the Unwrap_UVW-modifier at certain stages in the modifier stack because I want to work on UVWs. If I want to modify the material ID`s, I`d use a seperate modifier for that. The whole point of a modifier stack is that I get the ability to choose which attributes I want to modify. I do not want some modifiers to meddle in functionality that belongs to others. But this is exactly what the Unwrap_UVW-modifier in 3dsmax2017 does.

Example: I make a model. I use symmetry modifiers quite extensively since its a mechanical model of some kind. I unwrap it at the baseobject level, but since I don`t want overlapping UVW`s, I add a new unwrap modifier at the top level above the symmetry modifiers and spread the UVW patches out here.
The model gets textures, and now I am ready to set material ID`s. This is where the problem arises: In 3dsmax 2016 I could set material ID`s at the baseobject level, below all the modifiers. Since its a mechanical model there is a lot of different material ID`s, but they are all symmetrical, meaning I can use the symmetry modifier to help. Remember, those symmetry modifiers are above baseobject level, but below the unwrap modifier I previously set on top of the stack.
 In 3dsmax2016, those material ID`s changes I now do on the baseobject would propagate all the way to the top, through the unwrap-modifier. The unwrap-modifier didn`t have any opinion about material ID`s, since its job was only to keep my UVW unwrap. In 3dsmax2017 on the other hand, it picked up material ID`s when it was first added on top of the stack, and it is going to keep those unless I change it in that particular modifier, with no regards to what I just did on the baseobject level.
This means I now have to set material ID`s above the unwrap_UVW modifier. Which means I cannot use the symmetry modifiers to ease the job of setting material ID`s like I could in 3dsmax 2016. It also means that the modifier stack is much more locked, since I now have to add an edit_poly modifier on the top. The edit_poly modifier is otherwise totally uneccessary, but it has to be there to keep the material ID`s.

Also: This is not something that is related to one particular scene. Yes, in my previous post I said it broke all my scenes, but the issue is in no way related to them specifically. The problem is easily illustraded with a simple box. I attached a screenshot to illustrate the problem. I also encourage you to check out 3dsmax 2016, 2015, 2014 etc. to confirm that this is new functionality.

[Alfred.DeFlaminis]

Hello @hardrock_ram,

Could you please attach a max file with the extended setup as you normally work (a box is fine) so that I may do some testing on it?  In the case that I did misunderstand you I'd like to double check to make sure.  Thank you!

Best Regards,

[hardrock_ram]

I think you are making this more complicated than it is :).

The unwrap UVW-modifier never had the ability to set material IDs until max 2017. This is a "feature" that you should remove again, since its screws scenes and workflows, and it makes the modifier stack a lot less flexible when it comes to setting material ID`s in conjuction with UVW unwrapping.

This might seem like a small deal, but we put whole drilling rigs into max, and this adds many work hours and an increased reliance on scripts. I am currently working on this from home, since we prefer not to use 3dsmax2017 before this fixed either from your end or with scripts

I have attached a scene where I:

1. Made a box

2. Unwrapped it and baked it in the base mesh

3. Added a symmetry modifier

4. Added an unwrap UVW-modifier on top of the symmetry. The reason I do this is a: I don`t have to unwrap the other side of the box, and b: I want to make it non-overlapping. 

The unwrap UVW-modifier now holds the whole box as material ID 1, which it was when I added it.

5. Changed the material ID on the base mesh to 13. In the real world this model would be very heavy with tons of material IDs. I therefore want to take advantage of the symmetry modifier to reduce the amount of work.

6. The unwrap UVW modifier on top of the stack now prevents my material ID changes on the base mesh to carry through. It did not prevent this in previous versions of max.

I see that coming up with tons of examples for how this screws different workflows, might make it more difficult to grasp the simplicity of the problem. But you can bet that it screws up far more than the examples I have given in my posts. It even makes handling UDIM textures in render engines that lack the proper tools, much more cumbersome.

[lightcube]

Seems that the best fix is to add a new Boolean parameter to the unwrap modifier that defaults to off to use the incoming material IDs... turn on to set inside the modifier.

[hardrock_ram]

It`s A fix ... However, I don`t see the point of having it there at all. The whole point of a modifier system is that you use the particular modifer that you need. I don`t want a subset of bend attributes in the taper-modifier, even if I have the choice of not using them. It bloats the program and makes it more confusing.

[lightcube]

I disagree, personally.

The modifier stack has many strategies for solving issues. Just because many common traditional methods are going up and down the stack, there are times that having options that mimic other modifiers inside an existing modifier simply makes sense because of the nature of some tasks at hand. In the case of the Unwrap modifier, there are times that the artist is slowed down why having to go up and down the modifier stack (depending on the task at hand) and there are often problems that arise if you go down the stack because the Unwrap modifier is a topology-dependent modifier. In this case, I think being able to change a material ID inside the Unwrap editor makes a lot of sense--just like you can change a material ID in an Edit Poly modifier (but by your logic maybe you shouldn't be able to because there is a Material modifier already?) That being said, not making it optional can throw a wrench in existing models that might rely on material IDs coming from lower in the stack... which is why I think the best situation is to simply make it optional.

Just my opinion.

[Alfred.DeFlaminis · Accepted solution]

Hello @hardrock_ram,

Thank you for posting the file and expanding on your explanation.  I am not sure if this is actually a bug or just a workflow inconvenience, but regardless I have logged it anyways in the tracking system and included your suggestions as well as one of my own.

However, given that passing Mat ID's up a stack of say Edit Poly mods would have this same effect, I wonder if devs will consider it 'working as intended'.   You may want to add this to 'request a feature' so that in the case that it is considered working as intended then you may still see a resolution to your problem in the future.  (Maybe a 'refresh ID's' or 'get stack ID's' button would be great for this, as as other posts have mentioned a way to simply turn it off.)

In the meanwhile, I would recommend trying to save your UV's out of the modifier and remove/reapply the unwrap and then loading those UV's back in as a potential workaround.  Or, I wonder if a script could be written that 'refreshes' the unwrap for the time being.  

In summary, I've logged your bug with a link to this thread and a description of the problem, linked to the feature request forum, and attempted to provide a temporary work around for you regarding this issue.  Is there anything else I can do for you for the time being?  Thank you for your descriptions and taking the time to make the sample file.  I appreciate it and the info has been passed along.

Please hit the "Accept as Solution" button if my post fully solves your issue or answers your question. This lets me know that I was effective in helping you, and thank you for doing so.

Best Regards,

[hardrock_ram]

Yes, the edit poly modifier shouldn`t have the ability to to change material ID`s either. However, I recognize that at some point you can`t keep splitting features into seperate modifiers. I just don`t think that keeping material ID`s separate as "too much" since its clearly a seperate thing. Material IDs also have implications for proper texture UDIM handling in certain render engines that don`t have good texture management abilities, which makes it even more imperative that this is kept as standalone as possible.

[hardrock_ram]

Yeah, I don`t think its going to change back to pre max2017.

I will fix it with a script I guess. I will probably make it so that all modifiers in question will fetch matIDs from the modifier below. Saving UVWs and reset is probably also a fine option, but this way I will take care of the same potential problem in other modifiers as well ...

Thanks for the help 🙂

[Alfred.DeFlaminis]

Sure thing @hardrock_ram,  

Thanks for being patient while I was understanding the issue and for posting the file.  I really appreciate it! 

Best Regards,

[hardrock_ram]

There is no way to get around the fact that material IDs have to be set in or above an UVW_unwrap.  It is not possible to save a UVW map, reset the modifier and then load the UVW map again. It will load the old material IDs as well. The only way to fix this is with a script, which I will. Its just very annoying.

It is one thing to add a feature, realize it was a mistake, and remove or modify it. Both Chaosgroup, The Foundry and others do this from time to time. It`s a whole different issue when you don`t realize how it breaks the workflow, even after it has been explained for you.

And don`t get me started on the fact that I have to communicate with you guys on a forum to reach anyone at all. It so happens that I am responsible for 3D animation software at one of your biggest CAD customers (Schlumberger). These days you guys are trying to sell us real time visualization software based on Stingray and\or Vred. You don`t seem to have any problem throwing all the in-house software gurus and technical experts you can at us to convince us to buy software. Apparently those same people are non-existent when I appear as a single customer with a problem. This is in stark constrast to your competitors, which put all their technical weight in when I contact their support.

[stop.waiting]

Well said.  I can't believe he called it a workflow inconvenience, to completely break your established workflow. -Greg

[aon.914858227]

---

@stop.waiting wrote:

Well said.  I can't believe he called it a workflow inconvenience, to completely break your established workflow. -Greg

---

Not sure why you are trying to blame a person that`s not responsible for design and implementation of this feature and just trying to help.

[hardrock_ram]

To be clear: My last post was NOT directed at Alfred (the support person) personally. He is helpful, and I am sure he does his best.

When I say "you" I mean Autodesk as a company. And the frustration is not just because of this incident alone. At work I need support from different companies from time to time. All the other software providers are very easy to get in touch with, and they put technical people on the line at once. This is not the case with Autodesk, to say the least ...

[Alfred.DeFlaminis]

Hello @hardrock_ram,

Please let me know what you'd like me to do and I will happily do so.  I don't want you to be unhappy, of course.  

As of right now this is logged in the bug tracker as promised.

Best Regards,

[hardrock_ram]

No problem Alfred 🙂
As I said, its not about you. This is actually the most helpful support I have ever gotten from Autodesk, and that is the problem.

[Alfred.DeFlaminis]

Hello @hardrock_ram,

You're concerns have not fallen of deaf ears.  I brought this up during this weeks team meeting and I've gone ahead and made sure that these issues are being seen and heard by my superiors.  Thank you for voicing your concerns and for keeping me in the loop with the issues you are having, and I also appreciate the kind words.  😉  I assure you that I and Autodesk do take your concerns seriously and I appreciate your candor.  

Best Regards,

[Alfred.DeFlaminis]

Hello @hardrock_ram,

I am writing to tell you that the developers have fixed this issue in 3ds Max 2018 according to the tracker.  I wanted to let you know asap.  Thanks for taking the time to help me understand it so I could properly log it.  

Best Regards,