State Sets are not production ready

Become a member of the CGSociety

Connect, Share, and Learn with our Large Growing CG Art Community. It's Free!

THREAD CLOSED
 
Thread Tools Search this Thread Display Modes
  09 September 2012
State Sets are not production ready

Hi, Folks

Recently installed Max 2013 for the first time, greatly anticipating getting to use the new render pass system for the first time. For years I've seen the lack of such a tool as a huge design flaw in Max, and with all the talk about XBR these last few years and "restoring our faith in Max", I was hoping some real inovation would be coming our way.

Now that I've had a chance to try the State Sets system, I am deeply disapointed in its design (as used for render passes), and frankly I see no reason for optimism about the future of Max when this kind of poor design is still being shoveled into the program.

My appologies to the good folks behind this tool, I mean no offense. Please accept this as constructive criticism, and if I'm wrong on any of these points let me know:


  1. States inherit their object visibility from the master state of the scene. Instead, each state should have an explicit list of objects, Max layers, or selection sets that will be visible for that state, NOT a list of what models were hidden/unhidden relative to the master state. A) What happens when I add a new model to the scene? I have to go into each state and make sure that model is being handled properly. B) The master state should be a worry-free workspace where you can build your scene and not worry about what's hidden or unhidden. I should be able to send my passes off to the renderer without having to nervously double-check my master state to make sure just the right models are showing.
  2. Adding properties to each state is very awkward and time consuming. If I want to specify what camera a state will use, but the master state already uses that camera, I have to first cange the view of the master state to something other than the camera, then record the camera I want for the pass. This is true for all other properties as well, such as start/end times.
  3. Start/end times are not embedded into keyframes. A) What happens when I have 20 different time ranges represented in my list of states, and my customer has me change the animation timing at the beginning of the scene. All 20 time ranges become invalidated and have to be updated by hand, which is time consuming and error-prone. B)The correct solution is to have the start/end times stored as keys in the scene, so that the keys can be moved along with the rest of the animation, keeping everything in sync and worry-free.
  4. It's very difficult to compare information from one state to another. A) What if I wanted to see the start/end times of all the passes to compare when they start and stop relative to each other? Currently I have to sort through a cluttererd, messy tree of information FOR EACH PASS. B) There should be a table view availabe listing each pass in a single row and customizable columns of specific properties for comparison.
  5. Object oriented support is lacking. Having nestable states is a start in the right direction, but not nearly enough. A) State properties should themselves be objects that can be copied and pasted as copies or instances into other states. The benefits of this are obvious and don't need further explanation. B) Model visibility lists (as discussed in item 1) should be instancable objects as well, that can be shared by multiple states.

There may be other problems as well, but this was enough to convince me that State Sets are not production ready yet, and I will have to continue to use my own tools to handle render passes.
__________________
Jon Huhn
Medical Animation
www.JonHuhn.com
www.JonHuhnMedical.com

Last edited by Jon Huhn : 09 September 2012 at 02:23 PM.
 
  09 September 2012
I agree that the tool is definitely not production ready. The concept is great, but when I tried it out it just bugged out and crashed randomly when I loaded the scene. Fearing it would end up corrupting my scenes I quickly dropped the tool and haven't used it any more. I cannot point out any specific workflow flaws, but perhaps most of these bugs are now squashed.

But I do feel that there are more and more buggy and not-so-production-ready features being put into Max for ever new release and subscription pack. I'm beginning to feel like switching to Maya for every day this continues I'm afraid.

Last edited by Swahn : 09 September 2012 at 06:01 PM.
 
  09 September 2012
Howdy Jon,
Thanks for the feedback. You have a lot of good suggestions and ideas around render passes. Let me see if I can address some of your issues.
Originally Posted by Jon Huhn: Hi, Folks[*]States inherit their object visibility from the master state of the scene. Instead, each state should have an explicit list of objects, Max layers, or selection sets that will be visible for that state, NOT a list of what models were hidden/unhidden relative to the master state. A) What happens when I add a new model to the scene? I have to go into each state and make sure that model is being handled properly. B) The master state should be a worry-free workspace where you can build your scene and not worry about what's hidden or unhidden. I should be able to send my passes off to the renderer without having to nervously double-check my master state to make sure just the right models are showing.

State Sets act like adjustment layers in Photoshop. You have your man image or scene that you are working on and you make adjustments to that through a State. In this sense it does depend on the base max scene (called the Base State) for its changes. This can be a flexible way to work and actually allow you to achieve what you are describing while other solutions may not. It is a new way of working for sure and takes some time to get use to. A huge list of all objects, layers, and properties in the scene for each State would be a good deal of visual and computational overhead so that is not a direction we took.

What you’re stating above is not necessarily the case. If you hide a bunch of objects in a State they do not depend on your Base State. They will always be hidden in that State. So that should be working the way you want If you work with layers you can add objects to the scene and assign them to a layer in which they should behave correctly (ie a windows layer). This way all your States that would hide, show, or set a property for that layer will propagate to any new models and allow you to expand and adapt your scene.
Originally Posted by Jon Huhn: [*]Adding properties to each state is very awkward and time consuming. If I want to specify what camera a state will use, but the master state already uses that camera, I have to first cange the view of the master state to something other than the camera, then record the camera I want for the pass. This is true for all other properties as well, such as start/end times.

This is currently the case as you need to start from somewhere and tell max that there is a change. We are looking into a way to “set” a property if you don’t want to change it from the Base State.
Originally Posted by Jon Huhn: [*]Start/end times are not embedded into keyframes. A) What happens when I have 20 different time ranges represented in my list of states, and my customer has me change the animation timing at the beginning of the scene. All 20 time ranges become invalidated and have to be updated by hand, which is time consuming and error-prone. B)The correct solution is to have the start/end times stored as keys in the scene, so that the keys can be moved along with the rest of the animation, keeping everything in sync and worry-free.

I think this is something a Camera Sequencer tool would be good for. In the end if you have 20 cameras set up to render specific ranges and you need to shift them you will need to change them all somehow. With State Sets I recommend setting up separate camera States that are then instanced into each pass you want them in. This way you can quickly go into every camera State and adjust its timing. It will then propagate to all passes. I would like to explore different ways to do this so please let me know what you think would be the best way to approach it?
Originally Posted by Jon Huhn: [*]It's very difficult to compare information from one state to another. A) What if I wanted to see the start/end times of all the passes to compare when they start and stop relative to each other? Currently I have to sort through a cluttererd, messy tree of information FOR EACH PASS. B) There should be a table view availabe listing each pass in a single row and customizable columns of specific properties for comparison.

The ability to query the tree in a table is a good idea. State Sets is open to Maxscript so this is potentially something you could do there. As far as ability to see info, I think State Sets is quite a bit ahead of previous solutions like Batch and Scene States that did not give you any of this info. I don't think Maya's render layers even allow a tree view to see their changes ether but I could be mistaken. That said, again I think a table query is a good idea to expand further.
Originally Posted by Jon Huhn: [*]Object oriented support is lacking. Having nestable states is a start in the right direction, but not nearly enough. A) State properties should themselves be objects that can be copied and pasted as copies or instances into other states. The benefits of this are obvious and don't need further explanation. B) Model visibility lists (as discussed in item 1) should be instancable objects as well, that can be shared by multiple states.

Properties can be set in a State for objects or layers and that State can be copied, pasted, and instanced. Copy and paste single properties is a good suggestion for sure.

If you haven’t had an opportunity please check out the Siggraph 2012 Master class on State Sets for 3ds max 2013 here:

http://area.autodesk.com/masterclas...chael_mc_carthy

Thanks again for your feedback and I hope some of my comments may help you out.
Michael McCarthy
__________________
www.mmccarthy.com
Autodesk Master

Last edited by Michael-McCarthy : 09 September 2012 at 02:31 AM.
 
  09 September 2012
Hi, Michael

Thanks for your gracious reply. I will make time to go through that Master Class video as you suggested, if I had known about it earlier I certainly would have viewed it already. Render pass magagement is a huge deal to me, as it greatly influences the quality and speed at which 3D work can be produced.

Quote: State Sets act like adjustment layers in Photoshop. You have your man image or
scene that you are working on and you make adjustments to that through a State.
In this sense it does depend on the base max scene (called the Base State) for
its changes. This can be a flexible way to work and actually allow you to
achieve what you are describing while other solutions may not. It is a new way
of working for sure and takes some time to get use to. A huge list of all
objects, layers, and properties in the scene for each State would be a good deal
of visual and computational overhead so that is not a direction we took.


I think we must have different philosophical approaches to the use of a Base State. I know there's programming and UI issues with having to store lists of what models will be visiable in a given state (or what lights will be enabled), but I can't emphasize the following point enough: It's not good design to use the Base State as both our work space AND as the base comparison for what models and lights will be shown in all render passes. We need a workspace in which we can hide and unhide models or turn on/off lights at will in the course of our workflow, and not worry about how it will impact the render passes.

As artists we are under incredible stress to make customer changes quickly, and then re-render at the last minute to try to meet hard deadlines. As long as the Base State influences what models are visible in the passes, you're creating the opportunity for human error to creep in and cause incorrect renders, and at times when there isn't enough time to rerender.

One solution to this problem is to add the ability to add a property to a state that hides all models and turns off all lights in the scene before the other properties are executed. This way only models that are explicitely unhid or lights that are explicitely turned on by the pass will show in that pass.

Quote: With State Sets I recommend setting up separate camera States that are then
instanced into each pass you want them in. This way you can quickly go into
every camera State and adjust its timing. It will then propagate to all passes.
I would like to explore different ways to do this so please let me know what you
think would be the best way to approach it?


With this technique, I still have to manually update the times for all 20 of those camera state sets, which is time consuming, and again, prone to human error. And the mistake might only be discovered after a night's worth of rendering and be too late to fix before an important deadline.

What I'm suggesting is that you use the Link Constraint as an example for how to handle start/end times (the Link Constraint dynamically changes the effective parent of a model at specified times). Years ago, the Link Constraint was a pain to use if you knew the timing of the scene was going to change, because the time was set only with a spinner. If the timing of the scene ever changed, you had to remember to update the time set in that constraint. But recently Autodesk changed that behavior so the time is ALSO stored in a keyframe, so that keyframe can be updated along with all other keyframes in the animation, keeping things in sync.

I implemented this in my own render pass manager that I wrote years ago and have been using ever since. Start/end times are set by spinners, but the user has the option to check a checkbox and have them stored in keys as well. Now when a customer has me alter the animation timing, I don't worry about the start/end times of my passes AT ALL. They're always correct without any effort on my part.

Quote: That said, again I think a table query is a good idea to expand further.


Here's how I handled it in my tool:

Only the subpasses of the selected pass are listed in the table, which allows the scope of the table to be limited easily for nested, tree-based pass systems such as State Sets.

Quote: This is currently the case as you need to start from somewhere and tell max that
there is a change. We are looking into a way to “set” a property if you don’t
want to change it from the Base State.


You might consider adding an "operator" based system to work alongside your current recording system. I use operators in my pass system, so each pass is essentially just a container for a list of operators (commands) that are executed on the scene right before a render:


At render time, all models are hidden, all lights are turned off, and all atmospherics are disabled. Then each operator is executed in order, unhiding certain models, turning on certain lights, applying properties or materials to certain models, etc.

Quote: Properties can be set in a State for objects or layers and that State can be copied, pasted, and instanced


I see that states can be cloned, but I don't see that they can be copied and pasted (or instanced). I'll look into that further.

Thanks for listening patiently and taking the time to consider these things. It's obvious much hard work and thought has gone into your system, I just feel that these critical design issues are keeping the tool from being useful under harsh and demanding circumstances. I'd love to hear other artists on this formum weigh in on the issue, but most probably won't take the time to read through our lengthy point-by-point discussion.

Thanks!
__________________
Jon Huhn
Medical Animation
www.JonHuhn.com
www.JonHuhnMedical.com
 
  09 September 2012
I use State Sets everyday. I think it's great when you get used to it.
Something that bothers me a lot is that it doesn't record every checkbox.

For example the "Enable Particle Emission" button for PF is not recorded. I don't understand why.
Luckily you can fix this by just hiding and unhiding. Too bad some of those small limitation makes StateSets feel unfinished yet.
__________________
Tweet me
My blog
 
  09 September 2012
Originally Posted by akisey: I use State Sets everyday. I think it's great when you get used to it.
Something that bothers me a lot is that it doesn't record every checkbox.

For example the "Enable Particle Emission" button for PF is not recorded. I don't understand why.
Luckily you can fix this by just hiding and unhiding. Too bad some of those small limitation makes StateSets feel unfinished yet.


You can always use a scripted-state for things like this, just set/unset any parameter you wish.
__________________
The GPU revolution will not be rasterized! - http://www.jdbgraphics.nl
 
  09 September 2012
Thread automatically closed

This thread has been automatically closed as it remained inactive for 12 months. If you wish to continue the discussion, please create a new thread in the appropriate forum.
__________________
CGTalk Policy/Legalities
Note that as CGTalk Members, you agree to the terms and conditions of using this website.
 
Thread Closed share thread



Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off
CGSociety
Society of Digital Artists
www.cgsociety.org

Powered by vBulletin
Copyright ©2000 - 2006,
Jelsoft Enterprises Ltd.
Minimize Ads
Forum Jump
Miscellaneous

All times are GMT. The time now is 02:54 PM.


Powered by vBulletin
Copyright ©2000 - 2017, Jelsoft Enterprises Ltd.