State Sets problems - Max2014 sp3


I wonder if anyone else is having problems with State sets. I haven’t used them before, and am having a reoccurring problem. I am using them mostly to just hide and unhide layers and objects, then rendering out about 20+ variations from my scene. I have them all setup, then I will be working on moving objects or making modifications with state sets closed, and when I open them up again the states are now unhiding/hiding entirely different layers than what I had originally set. This has happened a few times, so I’ve been very careful after the first time to make sure I wasn’t recording anything or modifying the state in anyway…but it has still happened multiple times.

Any ideas? Is this feature really this unstable?



It’s gotten a lot better in 2014, but I still get the sense that there are some little gremlins under the hood that pop out from time to time. I’ve been using it a lot on a few recent projects, and about 95 percent of the time it’s good. The only time it “breaks” in my opinion is when you open and close containers. It puts you back in the default “state” but shows that a different state is active, at least in my scene.

Couple things to keep in mind. First, when you change states, not every menu “refreshes.” In particular, the layer menu doesn’t. So this might cause confusion because you aren’t actually seeing the current layers when you jump into a state. Try going in a state, then close and open the layer window, and it should look right.

Also, inside a state in the State Sets window, you can see which objects are being hidden and which layers are visible. So you can edit directly in that window, and make sure everything is set how you would expect it.


At first i thought they got finally fixed in 2014, and i used them for simple things like automatic camera switching, changing output paths, etc… but as soon as i got serious with it, and wanted to do actual render passes, it broke again.

Sometimes changes would not register, other time registered changes would simply disappear from states once i did some changes to them. After i got everything setup, some parts of the states somehow merged with the main (out-of-state) state, and once i tried to save the scene by fixing all things that it messed up i ended up with having my file corrupted again.

Then i thought i just use them wrong, but few days after, my colleague gave them a shot and ended up with exact same experience. So my suggestion is to stay away from the state sets if you don’t want to get your scene damaged.

Also, even in those very simple scenarios where state sets actually worked, it was still a horrifying experience, as every time i work with states i am under constant tension that one wrong click can ruin absolutely everything.


Guys thanks for the response, I kept wondering if I was doing something wrong or odd.

Decency - I’m not using containers and am really only hiding and unhiding. I think two states have a single material change. Really simple stuff…yet it breaks. I’ve noticed the refresh bug in the layers menu, which is a real pain since that is all I am trying to use it for. I have noticed if you toggle the visibility of a layer it ‘usually’ refreshes the whole menu. I have been checking the state set window each time I notice something and its really trashing what I have setup. Here is a screenshot. The left side is correct, I open the file later or reopen the state sets and I get what is on the right.

Layers changed, rearranged, layers that I haven’t even touched while working…

Rawalanche - I am feeling the exact same way about the tension you mention. I don’t know when or how they will break and I’ll have to fix it all again. Right now I have a saved file that all the states are correct. I delete everything out of it, and then import/merge all objects from the latest file. Then the states are correct again, IF I haven’t changed any object names…since I am mostly doing layer visibility, I can probably make it work…but…you have experienced corrupted files? Damaged so you can’t open them? Or?

Do either of you know of any good maxscript alternatives that have similar capabilities you might know of? I guess I’ll be searching and if I find something I’ll post here.

Thanks again,


Howdy Nate. Sorry your having difficulties working with State Sets. I would like to help in any way I can and if there is a bug fix it ASAP :slight_smile:

The Layers dialog or others in max not updating is for sure a major PITA. I am sorry that is how it is. It is confusing for users and in many cases causes the “Errors” you’re describing (all though it seems that’s not the case for you).

We have not had any bug reports on the beta or elsewhere with the issue you’re describing here so I would like to check it out to be sure we get it fixed. I do know more than a few people on beta that uses State Sets with layers have pretty good success sometimes with 50+ States.

If you could send me a scene that shows the issue you’re having I would like to help. Maybe you can provide some steps to reproduce the issue? If so I am confident we can get the issue fixed ASAP. Please shoot me an email at

I also want to extend that to anyone here. If you have an issue and can send me simple steps to reproduce it with a basic scene, I am sure we can fix the issue quickly. If its not a code based issue I would be happy to recommend some ways of working that might help you out. Either way please shoot me an email if you do have an issue.

Thanks a bunch



I appreciate your interest in this issue. I spent some time trying to recreate it, and I think I have what is creating the problem.

When you create a new layer and move an object from a layer that has a state already set for it (in my case ‘hidden’) into the newly created layer…the state changes the layer you had set. You do not see this until you SAVE the file and then reload it the next time.

Here are some screenshots to show it in a simple scene:

First shot is the scene with two states set. (BoxesSphere_00.max)
Second shot is making a new layer and moving Box001 to this layer. SAVE file (BoxesSphere_01.max)
Third shot is reopening the above file. State has changed.

Hopefully this makes sense, let me know if it needs more explanation. I will send this and the scenes to your email.



Howdy Nate. Thanks for digging down to try and reproduce your issue. I ask people to do this all the time and I know it takes time and effort to do. I appreciate it.

I got your email and will follow up with you there. I can assure you that if this is a bug we can reproduce we will fix it posthaste.

Thanks again!


I have spent some time thinking about how to describe how State Sets should work properly in the most clear and comprehensive way possible. And i have came up with the way of designing and testing state sets that should be as production-proof as possible. Here it goes:

1, You have a reasonably complex finished scene setup. Then you create a new state, and enter that state. Once you enter that state, you can do any sorts of crazy things without being careful at all. You can do anything and everything you need in order to set up the pass you want, without need to be careful about absolutely anything except doing physical changes to the scene. That means deleting objects, moving, animating them or changing meshes at their base (non-modifier) level.

2, Then once you exit the state, everything is exactly 100% same, as it was before, and if you render again, you get to the pixel same result. In case new objects were created in the process of setting up the render pass, then these objects should be hidden from the base pass and other passes for both viewport and render, so that what you have is 100% identical to what you had before you started to work with different state.

3, You can again do absolutely any changes in your base state, except deleting objects, moving, animating them or changing meshes at their base (non-modifier) level, and if you return to your render pass, that you had set up before, everything will again be 100% the same as before… and if you render again, you get to the pixel same result again.

4, At the creation of states, there would be two options - Clean state, and Reference state:

Clean state would mean there are no connections to the base state, so for example changing render settings resolution or environment map in base state would not be propagated to this state.

Reference state would mean that any options, be it render settings, object viewport/render visibility, materials, environment and so on would be always referenced from the base state unless you change them, once you change one, it would become unique to this state.

5, Most important rule. Any non physical changes (deleting objects, moving, animating them or changing meshes at their base) made in any state except the base state can NEVER EVER, under ANY circumstance affect base, or any other state.

6, Then of course, there would be sub-state system, which would be a reference state, that would not reference settings from the base state, but it’s parent state instead. That would make a single exception in point #5, where non-physical chances in non-base state are propagated to all of the sub-states, except for those changes, that were made unique in in sub-states by being changed.

So basically i would think of it as many scenes contained within one scene file, that together share objects, their position, animation and base level geometry of meshes.

In my opinion, if it worked this way, according to these simple rules, and was stable and bug free, it would be both pleasant and efficient to work with. Design that breaks any of these rules will be always very prone to problems.


Rawalanche - Yes, if it did all those things that would be great. Major thing is it must be ROCK SOLID. If the only way to work with scene states is a 100% finished scene that nothing changes, that really isn’t an option for me. I can’t waste as much time as I have been, being careful and everything still falls apart.

Unfortunately for me, even when I am extremely careful and not doing anything that I believe causes the bug I have seen, the states still get all jumbled up and unusable. And all I am doing is hiding and unhiding different combinations of layers to render to specific files.

I haven’t found a script/plugin to do this yet, so I guess I’ll be trying to write my own script. If you guys have seen something that would hide/unhide specific layers, then render a specific filename, let me know I’d appreciate the link.



So far I’m ok with the way State Sets are designed.


It’s too late now, but I think the name is prone to cause a lot of confusion between Scene States and State Sets.

Feels a bit like a plugin. Submitting all states to network rendering is really clunky.
Also resetting the paths every time states are added.
(Again there is probably a reason for it, but in most cases this is something that could be done automatically and doesn’t need to show up in the states themselves at all unless there are dedicated paths for certain states.)

There are probably good reasons for it, like identifying layers uniquely, but I feel a lot of things would be easier if State Sets would identify the layers by their actual name (and update it if it was changed. )
However that might be an assumption of mine, because State Sets tells me it can’t find the layer with ID 41, after some layers have been deleted. (More info below.)

This is probably very error prone, but it would be useful to be able to merge states between files. (Other than keeping the file and merging everything into it. )
Probably connected to the naming problem.
Basically if I have one scene set up completely, I’d like to be able to simply copy my states over to another file with identically named layers.
(And especially if the files are completely identical except for the fact State Sets have been destroyed in one of them. )

State Sets doesn’t seem to like when layers which have states are deleted, but will not warn the user when deleting the layer or saving the file. Only the next time the file is opened it will throw some errors. At least that’s what happens here in one case. Didn’t test further.
I deleted several layers, one of them was changed in several states and now all my states are gone but one. Maybe even the deletion of a layer without states causes problems? Didn’t look deeper into it. The ideal behavior would be if State Sets just deleted the part of the states that had to do with the layer in question and kept the rest of the recorded states. I used a script to delete empty layers, in case it matters.

I think it’s great that I can change the states of the layers directly in the Scene States list, but I don’t understand why there are once more different icons. These icons should be the same as the ones in the layer manager.

Also there could be a checkbox somewhere that hides properties that haven’t been changed.
The list can get quite busy right now.


I wanted to chime in quickly on one of the most annoying things about state sets:

When you record changes to a LAYER (Visibility on/off) the LAYER window will NOT update.
This is obviously a 3ds max problem.

The way I have been avoiding this issue is to use a 3rd party plugin:

Tim hawkers ‘Nested Layer manager’.

Check it out. It’s free for 30 days and after that it’s only 12 Euros.
you can have nested layers (using layer folders), plus many extra features but most importantly, when you use NLM with state sets, the layer visibility switches always update instantly!


Thanks for the tip! :slight_smile:


Thanks for the suggestions Noren. Let me see if I can address some of them below

Yep I think that ship has sailed. I dont like that its mixed up with Scene States either.

We are working to improve the network rendering with State Sets. We have done some work with the Thinkbox crew on Deadline and it has its own State Sets tab now. We are addressing the issue with having to reset the path every time you add a new State.

There is a good reason and its related the code and speed. With that said you should not get any errors when deleting a layer. If you can reproduce this issue please send it to me and we will get it fixed straight away.

Yes this is a tricky workflow. We are looking into it. One way to work like this is with State Templates. You can save out a Template and use it in another scene.

I also wanted to thank Michael for his tip on the layer manager not updating. It can be tricky when the max UI does not update. I just wanted to say we are currently addressing the layer update issue.

Lastly I wanted to follow up with the original topic of this thread. Nate had an issue with layers that he clearly outlined and then followed up with me on email. That issue is now being addressed and Nate is testing it out to be sure. Thanks Nate!

Thanks again


Thanks for answering, Michael! :slight_smile:

If I have some time I’ll try to reproduce the layer deletion problem or send you a stripped down version of the original file. Might take a couple of days, though.

I’ll have another look at the templates, too.


Hi Michael,

I sent you a PM with a link to the stripped down file in question.
If I delete any layer (as far as I tried ) and save the file, the next time I load it I get an error and all states but one have been deleted.
The layers are a bit messy, but then I couldn’t delete any of them. :wink:

I used Outliner in this file which might or might not play a part in this.
(As far as I understand the way Outliner saves its information it shouldn’t. I did a quick test with de-nested layers with the same outcome, but that’s not necessarily saying much. I did not do basic tests of Outliner vs no Outliner.)

As for the templates, they kinda work, but expectedly not for layers.
(Neither layers with just the same name or merged ones.) That would be a huge bonus for me.

Generally, because of the relative nature of the states, it would probably be necessary to be able to translate the base state of a scene to some degree. E.G. Render settings (We could do it manually by simply setting the renderers up in a state completely, or start with a copy of the original scene, but that’s a bit cumbersome.)

It seems like the render settings aren’t transferred completely, though.
Take for example one of the AO sub-states in my file, which changes the renderer from Scanline to MR.
If I make a template out of the parent state and apply it to a new scene, I’d expect all kinds of stuff to be lost, simply because it’s not present in the new scene. I wouldn’t handle it like that normally, of course.
But somehow the State fails to switch renderers completely. (And the base is Scanline in both cases. )

It would be good if the templates would keep their name when added to the scene.
E.G. “Template name”_01

The list of templates is convenient, but could get crowded fast. Perhaps we can save and open specific collections of templates later on?

Thx for your time!


Hi Noren,

Thanks so much for following up on this. I will have a look at your scene ASAP.

For Templates we are looking into way to track layers. That would be very helpful. Also keeping the template name would be a good idea so we will look into that.

EDIT: Oh ya… and Outliner does produce some strange results with State Sets and other things ;/. Cool tool but can get wonky.

Thanks again


No Problem, and thanks for being here.
That’s a LOT better than sending out bug reports with usually no feedback at all.


What would also be very convenient:

When a sub-state automatically could add the name of the parent-state to the name of the rendered files.
Maybe as an option.
(Or is that possible, already? )

That way, if you have a template, you just need to name the parent states and don’t have to name all the sub-states as well.


Good Idea. We plan to work on Templates more in the not so distant future so I will keep this in mind.

BTW Nates issue that started this thread is fixed in SP4 :slight_smile: I want to thank Nate for reporting and following up on it.

We have also identified the issue you submitted but it was to tight a turnaround for this SP. It will be addressed though. Thank you for reporting and following up with me. Thats how issues get resolved! :slight_smile:

Thanks again


My pleasure. :slight_smile:

As for the naming thing mentioned above, it probably would be enough if we could set something like {ParenstateName} in the output path.

Btw: Changing the renderer and a lot of the render related settings indeed don’t make it through the templates, as far as I can tell.