I ve probably already asked, but would we be able to parent with a drag&drop between 2 same treeviews ? or even between different treeview modes now that i think of it.
I've added a few items to the features list. For example using bold text for instanced objects.
Right now I'm working on (re)implementing the drag-drop functionality. I think that was something that worked quite well in 2.0, so the new implementation will largely follow that. Do you guys have any thoughts on things that could be improved there?
I've run into a few minor bugs.
Bug #1
When merging 3dsmax files, it seems to un-nest all of the layers and not carry over any blank layers?
Left: Before merger. Right: After.
Everything on the right was nested in "Mason" which had no objects assigned to it but did contain layers that had other nested layers and objects.
The "Mason Layer" didn't carry over, not sure why, this could be a regular max bug I haven't tried merging blank layers without having outliner installed to see...
It also seems to crash max if I try to re-nest some of the layers right after merging. If I save, close and reopen then I can re-nest them.
Bug #2
I also ran into a renaming bug.
If I change the name of an object in max or outliner, and undo the name change, outliner fails to revert back to the previous name.
The work around is to relaunch outliner and it picks up the correct name.
And again thank you so much for this awesome tool I really can't use the regular layer manager in max without dying a little on the inside.
#1: Is not a bug (unfortunately). It is a result of the recent rewrite of the nested layers system. The old system crashed 3dsMax when trying to merge nested layers, due to a bug in 3dsMax itself. So I had a choice of waiting for autodesk to fix it (we all know what the chances of that happening are), or changing the implementation and making some concessions. The fact that nested layers aren't preserved when merging scenes is one of those concessions..
#2: I will have a quick look at this, thanks for reporting.
The recent discussion about the "icon click actions" has given me an idea that I would like to hear your opinions on:
Wouldn't it be nice if it was possible to not only switch between "tree modes" (hierarchy, layer, etc), but also between layouts? So you might have a nodebutton for toggling lights which you don't want to see all the time because that would clutter things up. But you might want to be able to quickly switch to a layout where it is visible. Does that make any sense?
Perhaps the switching could be a combination of the treemode, layout and filter config. So you could have a "lighting" mode, which would be:
-Flat objectlist mode
-Layout with toggle light-, light color-, look through object- node buttons.
-Filter preconfigured to only show lights and cameras.
What do you guys think, will this be useful, or would it make things convoluted and confusing?
Let me see if I understand this, I would be a bit like the display tab in the control panel but integrated into Outliner and configurable in a way that can be saved and loaded quickly?
That would be crazy helpful for me.
Right now I use scripts to configure max to work in different modes Modeling, Materials, Lighting, Animation. The layer configurations I use are set up to be "what works for all" instead of what works best for each mode. Being able to configure the layers to work best for each mode would be great.
... But I don't know how many other people wear that many hats, so while it would be helpful for me, I wouldn't count my vote and workflow as standard and you probably shouldn't assume that I speak for a lot of people =P
Hmm no it won't really be similar to the display tab I think. It will only change things in the Outliner itself, not in the viewport or anywhere else in 3dsMax.
Basically what I'm thinking about is making a "mode" consist of the listmode (hierarchy, layer, etc), the tree layout, and a filter configuration. Currently these are independent and static. E.g. if you change the layout, it applies to all listmodes. I wonder if it might be useful to be able to switch between different combinations, either pre- or user-defined.
Oh... ok. That would be helpful but I don't find myself changing the modes all that often. I have it set the way I like and it hardly changes. BUT I might switch modes more often if it was easier to switch back and forth.
User defined would be more helpful. Sort of a "save/load various defaults easily through filtering? Maybe a set number of slots that are pre-defined and can be overwritten? Or right click on a button that brings up a list to choose/load/save/restore defaults?
It sounds like it would be useful, I would probably use it but hopefully it won't take up too much UI space?
Interesting idea. It might be useful for some people and yet beeing transparent for the others.
But the access needs to be quick and clean to be useful.
Yes it shouldn't really change the interaction. I'm thinking it could be like switching modes as it is now. But rather than just switching the treeview listmode, it will also change the filter config and layout.
The development of the plugin version of the Outliner 3.0 is not going quite as fast as I had hoped. I've been quite busy with my MSc thesis, and the SDK wrapper isn't really helping much either. Because it's taking longer, I've decided to invest some time into porting the 'oid' version (2.1.4) to 3dsMax 2013 after all.
recently Gregor Weiss made two macroscripts that make the loading and saving of nested layer configurations possible. So it enables you to merge nested layers in new scenes, which is pretty cool!
To continue with the nested layers theme, I've got something I'd like to hear the opinion of you guys on. In particular those of you who share 3dsmax scenes with others.
I've been working on a new SDK implementation of the nested layers which seems to work nicely with merging. It relies on layer names to 'rebuild' the layer hierarchy after a layer has been merged into a new scene.
For example:
Layer001
|-> Layer002
|-> Object001
To 3dsmax (at the time of merging) the scene looks like this:
When merging Object001, only Layer002 would be merged into the scene. If you have the nested layers plugin, it will try to find a layer named "Layer001" and reparent Layer002. If there's no such layer, it will create one.
The thing is, what should happen if you merge this scene on a computer that doesn't have the plugin? The nested layers data will be preserved, untouched. A user might then rename layers; perhaps renaming an existing Layer001 to something else. If the scene is later opened with the Outliner installed, a new layer would be created...
This may be a bit of a corner-case, but it's not a completely unrealistic scenario I think. The question is: is this a big enough issue to not use this implementation at all? Is this potential issue worth having "automatic" nested layer merging?
A compromise could be that merging nested layers only works if you have the Outliner installed at the time of merging. If not, nesting will be lost, or would require a manual "restore". How does this alternative sound?
I guess the name is your only way to identify a layer ?
Across scenes, yes.
Where do you store the parent data ?
Someone not possessing the outliner who changes the layers name, may create the parenting data manually right ?
It's not accessible through the UI. In the new implementation it will be stored as a binary stream in an AppDataChunk, that's difficult to access without an interface to it.
I need some more input on the nested layers behavior. This time about layer properties. Currently the Outliner's layer hierarchy only affects the hidden, frozen and boxmode properties. They work like this: a layer is hidden if either it is hidden itself, or if its parent is hidden. I think that is logical.
With the new implementation I could add more properties (as long as they have a boolean type (false/off or true/on)). I wonder if the hidden/frozen/boxmode behavior will still be logical with these new properties though.
For example the renderable property. With the current implementation, a layer would be renderable if either it is renderable itself, or if its parent is renderable. Is that logical, or should it be an 'and' combination?
Ah yes, my head starts to hurt, but i think i was looking it the other way around : unhidden and unfrozen, because those are the default states, like is renderable on.
Yes it can be a bit confusing sometimes.
Are there other properties you'd like to see handled in a similar way? That is, the layer hierarchy affects the property values. And if so, how should they be combined?
I think wirecolor should not be a property that is affected by the hierarchy?
I've looked into photoshop to see how they manage the group colors.
When you change a parent layer wirecolor, all its children get their color modified. But you can still edit each sub layer.
Parenting a layer shouldn't change its color.
A layer created directly as child should inherit the color from its direct parent.
And, that's maybe the way to handle every other properties ?
For the color I think that makes sense, especially when creating new layers. I don't think that should go for all properties though. Like the visibility property in photoshop, some properties should be a combination of the layer value and its parent's value.
I've implemented a new feature for the Outliner 3: automatically setting the "By Layer" properties on objects. Normally you'd have to set this property manually on each object, also when creating new ones. This is tedious and unnecessary.
With the Outliner 3 you'll be able to say which layers should automatically set object properties "by layer". Any object created on the layer, or moved to the layer will be updated. This will work for display, motion, render, global illumination and color properties.
I've made a little preview video to show how this works: https://vimeo.com/45778147
Note that it's done using some maxscript code just for the purposes of this preview. The final version will of course have a proper UI (probably in the context menu) in the Outliner.
Aha I didn't know about that preference setting... Makes this feature a bit less awesome.
Still, as you say, with this you can set it per layer, and per property type (display, render, etc). Maybe I should make defaults for new layers too.
I've made a new preview video, which shows the new nested layers for the Outliner 3.0: https://vimeo.com/46955894
In the Outliner 3 nested layer setups will be merged along with objects automatically. Basic layer properties are preserved too. That is to say, properties which affect child layers (hidden, frozen, renderable, etc).
I'd be interested to hear some ideas on the expected behavior of dragging/dropping and using the add (+) button. When using it from one selection-set to another, should it move the node (remove from one, add to the other), or only add it to the target set?
Currently, it is coupled with the ctrl key.
drag & drop : adds to a set, removes from the other
ctrl+ drag & drop : adds to a set, lets a copy in the other.
It would be more logic to use shift key instead of control, because it's the one used to duplicate object in the view.
Same behavior with the add button ? I'm not sure. People might want to just select an object in the viewport, add it to a selection set, without removing it from anywhere.
Also, since you added visibility and frozen options for selection set here, i wonder how it acts with the layers ones ?
I bundled this new preview with a few older ones that I hadn't put on the blog yet.
edit: oops, just realised I forgot to set it to 'public'.
Currently, it is coupled with the ctrl key.
drag & drop : adds to a set, removes from the other
ctrl+ drag & drop : adds to a set, lets a copy in the other.
It would be more logic to use shift key instead of control, because it's the one used to duplicate object in the view.
Same behavior with the add button ? I'm not sure. People might want to just select an object in the viewport, add it to a selection set, without removing it from anywhere.
That sounds pretty logical.
Also, since you added visibility and frozen options for selection set here, i wonder how it acts with the layers ones ?
Yeah that's a bit tricky, since the selection-set doesn't have it's own state, all it does is look if all objects in the set are hidden or not. So if half of them are hidden by their layer, it will show the selection-set as unhidden. Setting the properties on the selection set will actually set them directly on the objects in it. The layer properties will still override the node properties in the set.
By the way, these node-buttons will all be customizable, so you can use as many or few as you want: hide, freeze, boxmode, see-through, renderable, wirecolor and perhaps more later.
I've got a question about aesthetics and usability for you guys. I've been struggling with the horizontal layout of the TreeView for some time now. The main problem of the horizontal scrolling is that the part you'd want to scroll is everything up to and including the node text. Any buttons after the text should remain in view, even if some nodes' text is wider than the outliner. That makes it tricky to implement.
So I thought of a different, more simple approach: abbreviate the text when it becomes too wide. It should remain possible to identify the nodes, so an abbreviation will look like "GeoSp...003". A tooltip will pop up to see the full node name.
Do you guys think this will work, or would horizontal scrolling be required after all?
Ah yeah, the horizontal scrolling is annoying. I always end up scaling the window.
The abbreviation is a more classy solution, and to let the end of the node name is clever.
So I approve.
ColorTags is a new feature in the Outliner 3.0 that can be used to tag nodes and layers. The tree can be sorted and filtered by the tags.
Adding tags to the scene does *not * make the scene dependent on the Outliner.
There's also a "Use WireColor" tag, but I'm not sure if I'll keep that one. Perhaps instead setting the colortag should change the wirecolor of the node.
Well I actually left it out for the moment, until I know a way to make the selection clearly visible in combination with the background colors. So if you have any ideas...
First I can say that the color are important while they're not selected !!! If they're selected the color could change to be yellow or whiter as usuall. Because colors make the lecture easier for the selection. We don't really care about the colour when they're selected.
Than if you want a solution :
I think you can change the typo to "bold" or "italic" when object are selected, than change the typo color as a "DarkSaturatedRed"
or
You can as enginer make a limit of given colors that will help you to find the best selection color at the middle of all the limitated given colors. Sometime limitation is the clue.
Replies
Right now I'm working on (re)implementing the drag-drop functionality. I think that was something that worked quite well in 2.0, so the new implementation will largely follow that. Do you guys have any thoughts on things that could be improved there?
Bug #1
When merging 3dsmax files, it seems to un-nest all of the layers and not carry over any blank layers?
Left: Before merger. Right: After.
Everything on the right was nested in "Mason" which had no objects assigned to it but did contain layers that had other nested layers and objects.
The "Mason Layer" didn't carry over, not sure why, this could be a regular max bug I haven't tried merging blank layers without having outliner installed to see...
It also seems to crash max if I try to re-nest some of the layers right after merging. If I save, close and reopen then I can re-nest them.
Bug #2
I also ran into a renaming bug.
If I change the name of an object in max or outliner, and undo the name change, outliner fails to revert back to the previous name.
The work around is to relaunch outliner and it picks up the correct name.
And again thank you so much for this awesome tool I really can't use the regular layer manager in max without dying a little on the inside.
#2: I will have a quick look at this, thanks for reporting.
Wouldn't it be nice if it was possible to not only switch between "tree modes" (hierarchy, layer, etc), but also between layouts? So you might have a nodebutton for toggling lights which you don't want to see all the time because that would clutter things up. But you might want to be able to quickly switch to a layout where it is visible. Does that make any sense?
Perhaps the switching could be a combination of the treemode, layout and filter config. So you could have a "lighting" mode, which would be:
-Flat objectlist mode
-Layout with toggle light-, light color-, look through object- node buttons.
-Filter preconfigured to only show lights and cameras.
What do you guys think, will this be useful, or would it make things convoluted and confusing?
That would be crazy helpful for me.
Right now I use scripts to configure max to work in different modes Modeling, Materials, Lighting, Animation. The layer configurations I use are set up to be "what works for all" instead of what works best for each mode. Being able to configure the layers to work best for each mode would be great.
... But I don't know how many other people wear that many hats, so while it would be helpful for me, I wouldn't count my vote and workflow as standard and you probably shouldn't assume that I speak for a lot of people =P
Basically what I'm thinking about is making a "mode" consist of the listmode (hierarchy, layer, etc), the tree layout, and a filter configuration. Currently these are independent and static. E.g. if you change the layout, it applies to all listmodes. I wonder if it might be useful to be able to switch between different combinations, either pre- or user-defined.
User defined would be more helpful. Sort of a "save/load various defaults easily through filtering? Maybe a set number of slots that are pre-defined and can be overwritten? Or right click on a button that brings up a list to choose/load/save/restore defaults?
It sounds like it would be useful, I would probably use it but hopefully it won't take up too much UI space?
But the access needs to be quick and clean to be useful.
Download Outliner 2.1.5 for 3dsMax 2013 here.
The sourcecode is available as a separate branch on github.
Life happens, we'll wait
recently Gregor Weiss made two macroscripts that make the loading and saving of nested layer configurations possible. So it enables you to merge nested layers in new scenes, which is pretty cool!
http://script.threesixty.nl/outliner/index.php/blog/2012/06/merge-nested-layers-script-by-gregor-weiss
The plan is to include it in the Outliner build, but before that we'd like to see some people test it and see if everything works as it should.
I've been working on a new SDK implementation of the nested layers which seems to work nicely with merging. It relies on layer names to 'rebuild' the layer hierarchy after a layer has been merged into a new scene.
For example:
Layer001 |-> Layer002 |-> Object001To 3dsmax (at the time of merging) the scene looks like this: When merging Object001, only Layer002 would be merged into the scene. If you have the nested layers plugin, it will try to find a layer named "Layer001" and reparent Layer002. If there's no such layer, it will create one.The thing is, what should happen if you merge this scene on a computer that doesn't have the plugin? The nested layers data will be preserved, untouched. A user might then rename layers; perhaps renaming an existing Layer001 to something else. If the scene is later opened with the Outliner installed, a new layer would be created...
This may be a bit of a corner-case, but it's not a completely unrealistic scenario I think. The question is: is this a big enough issue to not use this implementation at all? Is this potential issue worth having "automatic" nested layer merging?
A compromise could be that merging nested layers only works if you have the Outliner installed at the time of merging. If not, nesting will be lost, or would require a manual "restore". How does this alternative sound?
It's pretty clear to me that if someone deals with nested layers, his co-workers should atleast have the outliner installed.
Anyway, I don't think it's a terrible issue. Auto merging would be great.
Where do you store the parent data ?
Someone not possessing the outliner who changes the layers name, may create the parenting data manually right ?
It's not accessible through the UI. In the new implementation it will be stored as a binary stream in an AppDataChunk, that's difficult to access without an interface to it.
I need some more input on the nested layers behavior. This time about layer properties. Currently the Outliner's layer hierarchy only affects the hidden, frozen and boxmode properties. They work like this: a layer is hidden if either it is hidden itself, or if its parent is hidden. I think that is logical.
With the new implementation I could add more properties (as long as they have a boolean type (false/off or true/on)). I wonder if the hidden/frozen/boxmode behavior will still be logical with these new properties though.
For example the renderable property. With the current implementation, a layer would be renderable if either it is renderable itself, or if its parent is renderable. Is that logical, or should it be an 'and' combination?
IMO :
A layer should be renderable if it is renderable itself and its parent is renderable aswell.
A layer should not be renderable if it is renderable itself and its parent is not renderable.
It seems to me it's the less confusing way, but i don't see where it's a different behavior from hidden or freeze
For the "renderable" property, the resulting property is determined with a logical AND:
For the "hidden" property, the resulting property is determined with a logical OR:
Are there other properties you'd like to see handled in a similar way? That is, the layer hierarchy affects the property values. And if so, how should they be combined?
I think wirecolor should not be a property that is affected by the hierarchy?
When you change a parent layer wirecolor, all its children get their color modified. But you can still edit each sub layer.
Parenting a layer shouldn't change its color.
A layer created directly as child should inherit the color from its direct parent.
And, that's maybe the way to handle every other properties ?
With the Outliner 3 you'll be able to say which layers should automatically set object properties "by layer". Any object created on the layer, or moved to the layer will be updated. This will work for display, motion, render, global illumination and color properties.
I've made a little preview video to show how this works:
https://vimeo.com/45778147
Note that it's done using some maxscript code just for the purposes of this preview. The final version will of course have a proper UI (probably in the context menu) in the Outliner.
Surely, to make it more accessible through the outliner is a good thing tho as i'm pretty sure few max users know it's there.
edit: ah, i've just realised you made this by layer while max option is global. Well, a good point for you !
Still, as you say, with this you can set it per layer, and per property type (display, render, etc). Maybe I should make defaults for new layers too.
https://vimeo.com/46955894
In the Outliner 3 nested layer setups will be merged along with objects automatically. Basic layer properties are preserved too. That is to say, properties which affect child layers (hidden, frozen, renderable, etc).
http://script.threesixty.nl/outliner/index.php/blog/2012/08/previews-previews-previews
https://vimeo.com/47234864
I'd be interested to hear some ideas on the expected behavior of dragging/dropping and using the add (+) button. When using it from one selection-set to another, should it move the node (remove from one, add to the other), or only add it to the target set?
Currently, it is coupled with the ctrl key.
drag & drop : adds to a set, removes from the other
ctrl+ drag & drop : adds to a set, lets a copy in the other.
It would be more logic to use shift key instead of control, because it's the one used to duplicate object in the view.
Same behavior with the add button ? I'm not sure. People might want to just select an object in the viewport, add it to a selection set, without removing it from anywhere.
Also, since you added visibility and frozen options for selection set here, i wonder how it acts with the layers ones ?
edit: oops, just realised I forgot to set it to 'public'.
That sounds pretty logical.
Yeah that's a bit tricky, since the selection-set doesn't have it's own state, all it does is look if all objects in the set are hidden or not. So if half of them are hidden by their layer, it will show the selection-set as unhidden. Setting the properties on the selection set will actually set them directly on the objects in it. The layer properties will still override the node properties in the set.
By the way, these node-buttons will all be customizable, so you can use as many or few as you want: hide, freeze, boxmode, see-through, renderable, wirecolor and perhaps more later.
So I thought of a different, more simple approach: abbreviate the text when it becomes too wide. It should remain possible to identify the nodes, so an abbreviation will look like "GeoSp...003". A tooltip will pop up to see the full node name.
Do you guys think this will work, or would horizontal scrolling be required after all?
The abbreviation is a more classy solution, and to let the end of the node name is clever.
So I approve.
ColorTags is a new feature in the Outliner 3.0 that can be used to tag nodes and layers. The tree can be sorted and filtered by the tags.
Adding tags to the scene does *not * make the scene dependent on the Outliner.
There's also a "Use WireColor" tag, but I'm not sure if I'll keep that one. Perhaps instead setting the colortag should change the wirecolor of the node.
What do you think about that ?
Than if you want a solution :
I think you can change the typo to "bold" or "italic" when object are selected, than change the typo color as a "DarkSaturatedRed"
or
You can as enginer make a limit of given colors that will help you to find the best selection color at the middle of all the limitated given colors. Sometime limitation is the clue.
Please install Product Update 10. It should fix the problems with the Outliner introduced by PU9.
http://usa.autodesk.com/adsk/servlet/ps/dl/item?siteID=123112&id=20398787&linkID=9241178
http://script.threesixty.nl/outliner/index.php/blog/2012/08/3ds-max-2012-pu9-issues
With some luck there will be a solution soon!
[Requirements]
minimal_maxVersion = 2013