I haven't forgotten about it, but I have to be honest in saying that it isn't a top priority at the moment.
There might come some bigger changes first, and perhaps this feature could be bundled with it.
I've put up a little poll on the website regarding price ranges for a potential new version of the Outliner. It would be a complete rewrite of the script to become a plugin. This brings a lot of benefits, mainly in terms of performance. But of course it does take a lot of time and effort to do, so I'm considering asking a small price for a 3.0 version.
The vote generates a php error for me.
Tough question. The outliner is such a timesaver to me.
Zookeeper is like 250$ i think ?
As an employee buying it on my own founds, i'd say 25€ would be cool.
For a company it's peanuts ofc.
Can't you evaluate your needs based on how much people already have the outliner ? (which should be the same amount as max owners )
@Noors:
I will of course take a look at the current userbase (which is a nice amount, but certainly not huge). What I'd like to find out is how many of these users would be left if it was no longer free. Also I'll take a few different models into consideration, and have a think of how to deal with multiple deployments. But this poll is just to get a rough idea of how the users think about the Outliner's monetary value so to say.
ah damn, too late to vote then. i'd definitely shoot you 10 - 20 euros. outliner's so been completely integrated into my max environment by now, i wouldn't know how to live without it
I'd drop 20 euros on this, I introduced it into my office and we now have ~10 artists who have it in their workflow. XD
I didn't notice the bonus tools, I may have to make a donation to get my hands on it before you put up the paid version.
Also, it would be awesome if the old version was still free, but maybe super simple. It would suck to all of a sudden have to pay to keep using Outliner if somebody didn't know about this^^
Also, it would be awesome if the old version was still free, but maybe super simple. It would suck to all of a sudden have to pay to keep using Outliner if somebody didn't know about this^^
The old versions will continue to work even with the introduction of a new version. I might also keep hosting them for a while.
I can't say too much about it at this point, but there will probably be a fairly natural transition from the old version into the new one.
i'd suggest keeping the macroscript version around as well, yeah. just because i'm afraid that at some point you'd might not continue updating outliner, and since plugins need to be recompiled for every max version (from what i gather), we'd be left without it's glory somewhere down the road
This is one of the reasons for making the plugin's source code available when a certain threshold in payments has been reached. At this point I can't really say too much about the 'roadmap', ETA and all that, but I'll probably have more info in a few weeks.
When an hidden node is under an hidden layer, could unhidding the node also unhides the parent layer ?
Actually we have to unhide the node parent layers first which is a bit confusing.
Sorry i think my english grammar is pretty bad here but i guess you get the meaning
Now i also wonder if "unhidden" nodes under an hidden layer should have the hidden icon too.
I agree that it should be implemented with some care to avoid it becoming confusing to the user. I'm thinking of experimenting a bit with tooltips or something along those lines. The idea behind these "icon actions" is that I don't want to clutter up the UI any more than necessary. I really want to keep it as clean as possible. So that should mean keeping the amount of different buttons to a minimum.
I get you want to keep a simple and clean UI.
But don't "force" yourself to find an action per node.
I don't see anything useful an "icon action" (registred the trade mark ) could do on a geometry for instance
+ consider the user risks to click by mistake so it would be better to not couple an icon with a fancy action.
Yeah it's pretty snappy
I agree that the icon actions should not be arbitrary. I think the light and layer ones make sense. It's something specific to the node's type, yet not something so obscure that only a few people would ever use it.
I made a little screencapture to show some ideas for the node- and iconbuttons: https://vimeo.com/38792365
Note that this is still very much WIP, and is just to show what happens when you mouse-over the node buttons, and the actions when clicking the icon. The icons itself should still be improved, so that they are more readable and to give them an "on" and "off" state.
So fresh !
I'd like to see more ppl involved here, you really deserve it ! I always had interest in technical stuff, lookin for tools, but i'm not the finest artist.
I still think my material idea is okish.
Let's say i do some modeling with a specific material applied.
I check the material icon and newly created objects get automaticaly the material.
I don't have ideas for the other stuff atm, but i rarely use bones or particles
Yes the material idea could work.
A while ago someone (was it actually you Noors?) suggested a material override. Maybe that could be something too. Although perhaps now that we have state sets this may not be all that relevant anymore?
mmh no i don't think it was me but this is a behavior coming from the onion which i didn't really use.
Scene states are a bit of headache to manage especially when you create new objects so the override material might be a good option indeed.
+ it encapsulates my idea hehe
Oh, now i remember the onion has an override material by layer. This could be really useful too.
Looking at blender's outliner and max scene explorer, i wonder if your outliner wouldn't benefit of a subtle "striped" layout, for a better readability, especially when the icons are aligned on the right.
Here are two screenshots that I think will make you happy The first one I posted on cgtalk earlier this month, but forgot to post it here..
edit: I just had another look at your "layer color" screenshot and realised that I had actually missed the background color being the same (or a toned down version) of the layer color. So the above screenshot doesn't entirely match that. I'll have a think about that idea though!
So that's an alternating background and full-row select with a maya (2012) colorscheme and icons.
Ooooh
Yes i've seen this picture on cgtalk, that's where i took the color icons hehe. But i was indeed "talking" about the layer background.
Ah man, that's one sexy layout !
As for max 2013, don't lie, we all know you have shares there...
It's a bit harsh but i get the reasons.
Do you think that the layer-coloring should only happen in the layer mode, or in all modes? (Please don't say it should be optional per mode, hehe)
I've been playing around with it a bit tonight and got something working. But it will be a somewhat tricky thing to implement in a clean way..
Nice to you to look into it !
moar options ! :poly136:
To me it makes most sense in layer mode. It's the layer color and not necessarily the objects color. It would also be a way to identify in a glimpse the layer mode from the hierarchy mode, when in the middle of several nodes.
Yeah i was thinking on how it would have to propagate or not to children layers so i've looked in photoshop and how groups manage it.
I'd say if you parent by drag&drop a layer to another one, it shouldn't inherit its color.
If you create a layer directly under a parent node, it should inherit its direct parent color and the user could always change it manually.
In PS, if you change a group color afterwards, all its children get the new color and i thinks it's the less annoying behavior.
I've been messing around a bit more with it and arrived at a reasonably decent implementation. But I'm not sure if I like the look of it very much....
I'm basically drawing another rectangle on the background using the layer's wirecolor at about 30% opacity.
mmh yeah it looked better in my mind hehe.
The dark grey background and white front aren't very permissive.
I was thinking maybe make the text colored instead, but then it will be hard to get it right in light style.
Well, i'm not so sure now. I still think it might be handy, but not really aesthetical.
+ maybe in conflict with the selection overlay color ?
Worthy to be tested in a beta ?
I did a quick OSX-inspired concept:
This would not use the layer's wirecolor but a set number of predefined color labels. The selection and other UI colors will override the 'label color'.
What do you think? (I might not actually include the gradient)
I think it's better !
I guess you don't want to use the wireframe color because then some incoherency could happen between colors ?
Also, maybe the color of layer nodes could be slightly different so they could pop up better.
I think it's better !
I guess you don't want to use the wireframe color because then some incoherency could happen between colors ?
Yeah I'm thinking about how to handle the text and line colours, to maintain readability. That could be easier to control when there's a fixed set of colors. These colors could even be part of the colorscheme, so it would be customizable, just 'global'.
And I'm also thinking a colorlabel feature might be a bit cleaner to implement in the treeview. Although it would require some more work to store it in the 3dsMax scene...
Also, maybe the color of layer nodes could be slightly different so they could pop up better.
I like that, good idea! Also like the more subtle lines between the nodes and colors.
And if you control the label colors, you can still go back to the previous style with the white font and a dark color, which is maybe a bit less agressive to the eye with the dark theme.
I continued a bit more with using the layer's wireframe color. Now the line/textcolor adjusts automatically to get a good contrast. I've also incorporated the ideas from your (Noors) earlier concept. The objects use the same colors, but are drawn with lower opacity (180 vs 255).
Because it's wireframe color you can make it look so rough that it will burn your retina off, but it has the benefit of a fairly simple implementation. When used with some care it can look pretty decent:
A slight concern with this is the 'highlight' colors, like for selection, droptargets, and so on. They can become hard to distinguish from the wireframe colors...
Doesn't look that bad
I think the main advantage of using wireframe color is, if you set your nodes wireferame color to be "by layer", they will inherit their wireframe color from their parent layer.
So eveything is consistent. Objects in a "blue" layer will be displayed with a blue wireframe.
note that in the default layer manager, nodes with their wireframe "by layer" get a specific icon instead of a colored square.
Yeah it is not going very fast, but there's definitely progress. And so far I've been quite happy with the code too. I'm putting quite a lot of effort into making it robust and maintainable. That's something that was lacking in 2.0, especially on the .NET side.
If you have any more ideas for new features, do let me know!
Would it be possible to share some page/google doc with ideas, priorities, opinions ?
It's actually a bit hard to know what is/will/should be, considering you're getting feedbacks from several places. Maybe it would encourage more discussions ?
Replies
That should work better
thanks!
This would be so helpful
There might come some bigger changes first, and perhaps this feature could be bundled with it.
https://github.com/Pjanssen/Outliner/issues/49
To give me an idea of the kind of price that you would think reasonable, please answer the poll:
http://script.threesixty.nl/outliner/index.php/polls/pricing
Tough question. The outliner is such a timesaver to me.
Zookeeper is like 250$ i think ?
As an employee buying it on my own founds, i'd say 25€ would be cool.
For a company it's peanuts ofc.
Can't you evaluate your needs based on how much people already have the outliner ? (which should be the same amount as max owners
So please give it another try: http://script.threesixty.nl/outliner/index.php/polls/pricing
@Noors:
I will of course take a look at the current userbase (which is a nice amount, but certainly not huge). What I'd like to find out is how many of these users would be left if it was no longer free. Also I'll take a few different models into consideration, and have a think of how to deal with multiple deployments. But this poll is just to get a rough idea of how the users think about the Outliner's monetary value so to say.
I didn't notice the bonus tools, I may have to make a donation to get my hands on it before you put up the paid version.
Also, it would be awesome if the old version was still free, but maybe super simple. It would suck to all of a sudden have to pay to keep using Outliner if somebody didn't know about this^^
The old versions will continue to work even with the introduction of a new version. I might also keep hosting them for a while.
I can't say too much about it at this point, but there will probably be a fairly natural transition from the old version into the new one.
http://script.threesixty.nl/outliner/index.php/blog/2012/03/first-plugin-benchmarks
i'd suggest keeping the macroscript version around as well, yeah. just because i'm afraid that at some point you'd might not continue updating outliner, and since plugins need to be recompiled for every max version (from what i gather), we'd be left without it's glory somewhere down the road
When an hidden node is under an hidden layer, could unhidding the node also unhides the parent layer ?
Actually we have to unhide the node parent layers first which is a bit confusing.
Sorry i think my english grammar is pretty bad here but i guess you get the meaning
Now i also wonder if "unhidden" nodes under an hidden layer should have the hidden icon too.
Btw, I'm looking for some ideas for 'context sensitive actions' to add to node's icons. (see this post on cgtalk) If you guys have ideas, let me know!
material : assign this material to every new object ?
I don't think everything needs its own "icon action", it might be a bit confusing.
I agree that it should be implemented with some care to avoid it becoming confusing to the user. I'm thinking of experimenting a bit with tooltips or something along those lines. The idea behind these "icon actions" is that I don't want to clutter up the UI any more than necessary. I really want to keep it as clean as possible. So that should mean keeping the amount of different buttons to a minimum.
I get you want to keep a simple and clean UI.
But don't "force" yourself to find an action per node.
I don't see anything useful an "icon action" (registred the trade mark
+ consider the user risks to click by mistake so it would be better to not couple an icon with a fancy action.
I agree that the icon actions should not be arbitrary. I think the light and layer ones make sense. It's something specific to the node's type, yet not something so obscure that only a few people would ever use it.
I made a little screencapture to show some ideas for the node- and iconbuttons:
https://vimeo.com/38792365
Note that this is still very much WIP, and is just to show what happens when you mouse-over the node buttons, and the actions when clicking the icon. The icons itself should still be improved, so that they are more readable and to give them an "on" and "off" state.
I'd like to see more ppl involved here, you really deserve it ! I always had interest in technical stuff, lookin for tools, but i'm not the finest artist.
I still think my material idea is okish.
Let's say i do some modeling with a specific material applied.
I check the material icon and newly created objects get automaticaly the material.
I don't have ideas for the other stuff atm, but i rarely use bones or particles
A while ago someone (was it actually you Noors?) suggested a material override. Maybe that could be something too. Although perhaps now that we have state sets this may not be all that relevant anymore?
Scene states are a bit of headache to manage especially when you create new objects so the override material might be a good option indeed.
+ it encapsulates my idea hehe
Oh, now i remember the onion has an override material by layer. This could be really useful too.
edit: I just had another look at your "layer color" screenshot and realised that I had actually missed the background color being the same (or a toned down version) of the layer color. So the above screenshot doesn't entirely match that. I'll have a think about that idea though!
So that's an alternating background and full-row select with a maya (2012) colorscheme and icons.
Check it out on the website.
Yes i've seen this picture on cgtalk, that's where i took the color icons hehe. But i was indeed "talking" about the layer background.
Ah man, that's one sexy layout !
As for max 2013, don't lie, we all know you have shares there...
It's a bit harsh but i get the reasons.
and thanks for the hint
I've been playing around with it a bit tonight and got something working. But it will be a somewhat tricky thing to implement in a clean way..
moar options ! :poly136:
To me it makes most sense in layer mode. It's the layer color and not necessarily the objects color. It would also be a way to identify in a glimpse the layer mode from the hierarchy mode, when in the middle of several nodes.
Yeah i was thinking on how it would have to propagate or not to children layers so i've looked in photoshop and how groups manage it.
I'd say if you parent by drag&drop a layer to another one, it shouldn't inherit its color.
If you create a layer directly under a parent node, it should inherit its direct parent color and the user could always change it manually.
In PS, if you change a group color afterwards, all its children get the new color and i thinks it's the less annoying behavior.
I'm basically drawing another rectangle on the background using the layer's wirecolor at about 30% opacity.
The dark grey background and white front aren't very permissive.
I was thinking maybe make the text colored instead, but then it will be hard to get it right in light style.
Well, i'm not so sure now. I still think it might be handy, but not really aesthetical.
+ maybe in conflict with the selection overlay color ?
Worthy to be tested in a beta ?
This would not use the layer's wirecolor but a set number of predefined color labels. The selection and other UI colors will override the 'label color'.
What do you think? (I might not actually include the gradient)
I guess you don't want to use the wireframe color because then some incoherency could happen between colors ?
Also, maybe the color of layer nodes could be slightly different so they could pop up better.
And I'm also thinking a colorlabel feature might be a bit cleaner to implement in the treeview. Although it would require some more work to store it in the 3dsMax scene...
I like that, good idea! Also like the more subtle lines between the nodes and colors.
did that pretty quick, just to illustrate
Because it's wireframe color you can make it look so rough that it will burn your retina off, but it has the benefit of a fairly simple implementation. When used with some care it can look pretty decent:
A slight concern with this is the 'highlight' colors, like for selection, droptargets, and so on. They can become hard to distinguish from the wireframe colors...
I think the main advantage of using wireframe color is, if you set your nodes wireferame color to be "by layer", they will inherit their wireframe color from their parent layer.
So eveything is consistent. Objects in a "blue" layer will be displayed with a blue wireframe.
note that in the default layer manager, nodes with their wireframe "by layer" get a specific icon instead of a colored square.
There may not be that much news in there for people following this thread though..
If you have any more ideas for new features, do let me know!
It's actually a bit hard to know what is/will/should be, considering you're getting feedbacks from several places. Maybe it would encourage more discussions ?
I've drawn up a list here: http://script.threesixty.nl/outliner/index.php/3.0-features-list
I'm going to go over some suggestions from the past and add them too.