Hi Michael,

> The inline mode actually does have a kind of tab
> that easily collapses or expands it to keep it from
> interfering with the workspace, I'll show that again
> here (this is a repeat from the initial post of this thread):

Yeah, that's all fine now and for a large displays but as this grows it will start to collapse the other tools and the ping-pong effect will still be inevitable, unless I'm missing something, also as MoI grows and the real estate shrinks, what's going to happen when the communication tools come to MoI and all the other future tools for V3,4 & 5, where are you going to stick them ?

> You can't get any more mainstream than AutoCAD,
> and it cannot do what I described unless it has
> changed hugely over the last couple of years.

I did say '3d', plus AutoCRAP was good marketing not good software :)

Anyhow, I'm sure what ever you come up with will work and we will wait in anticipation for the next beta :)

Cheers

Hi Danny,

> Yeah, that's all fine now and for a large displays but
> as this grows it will start to collapse the other tools and
> the ping-pong effect will still be inevitable, unless I'm
> missing something

The inline mode is limited to only grow up to a max of 40% of the height of the side pane, after which point it gets a scroll bar inside of it.

You can adjust the max percentage height in moi.ini .

But if you want something of full height that you plan to just open and close all the time (like you seemed to be describing with the vertical tabs stuff), then the "adjacent" mode where it opens up along side is pretty effectively the same kind of thing, really.

I mean in the one that you showed you have to switch back to "modeling" mode to get back to all the modeling tools, I don't see how switching off the adjacent full pane is really much different than that. If you are going to switch it off after you use it why would it make any difference if it temporarily squishes your viewports in? When you close it the viewports will be unsquished with the same end result at that point as what you were showing.

> what's going to happen when the communication tools
> come to MoI and all the other future tools for V3,4 & 5,
> where are you going to stick them ?

They are going to be more palettes in the side pane, collapsed by default. If you go to expand one and there is not enough room for it, one of the other open palettes will collapse (this happens currently if you shrink your window down to a small size for example).

I don't expect for this to be a big problem because many of those tools like dimensions, rendering, etc... are not going to be things that you tend to do rapid ping-pong style use (in a sequence of just a few minutes or seconds I mean) with the other modeling tools.

I prototyped this all early on in the UI design of MoI... The initial designs that I worked on had a lot more tabs with more stuff in them to make sure this kind of expansion was going to be incorporated into the design.

It is possible that in the future if something needs a whole lot of space and is more of a dedicated task, that I could still want to do a kind of "full panel switching" mechanism. It is something that I have thought about before, but I ruled it out for the browser because I expect it to be used in more combination while doing general modeling rather than as an exclusive task by itself.


> Anyhow, I'm sure what ever you come up with will work
> and we will wait in anticipation for the next beta :)

I'm certain that it will not be perfect! But it should also definitely be better than what I have now for this kind of stuff which is basically nothing, right? :)

- Michael

Michael your last few post have put things into perceptive for me thank you for explaining in great detail. I can say now I have start to understand how intelligent well planned your UI design is. You are a man with a Vision and Mission statement.

I don't know if this has been said before but it would be nice if you could click+hold and then slide your mouse over multiple eye icons to turn them on/off ion a sweep motion.

Also, maybe a kind of 'live search' box would be great to filter objects, for instance typing 'an' would filter "fans", "animals", "bananas", etc

Marc

+1

It also could be interesting to be able to toggle all layers visible/invisible except the one that is ctrl+clicked.
And to use similar actions on an eventual layer lock/unlock icon.

- Michel

Hi Marc, those are definitely great ideas. But somewhat difficult to implement so probably something to happen down the road a bit more.

- Michael

Hi Michel,

> It also could be interesting to be able to toggle all layers
> visible/invisible except the one that is ctrl+clicked.

I've been thinking of using right-click for that purpose.

A similar thing is currently set up for the checkboxes in the Object Snap menu if you'd like to mess with it. That's the menu that pops out with the little arrow that shows when you move the mouse over the Object Snap button in the bottom toolbar.


> And to use similar actions on an eventual layer lock/unlock icon.

I'm hoping to not have a separate lock icon, instead I'd like to have the eye icon show as a lock instead when all those objects are locked. But I haven't quite worked out all the details yet.

- Michael

Hi Michael,

>>toggle all layers
>> visible/invisible except the one that is ctrl+clicked.

>I've been thinking of using right-click for that purpose.
>A similar thing is currently set up for the checkboxes in the Object Snap menu

Yes. I forgot that it was already implemented in the Snap menu. And it keeps the interface coherence.


>I'm hoping to not have a separate lock icon,
>instead I'd like to have the eye icon show as a lock instead when all those objects are locked.
>But I haven't quite worked out all the details yet.

Do you see it as a triple state button ?
While the interface would stay clean, the states alternance would add one more step to the user.
Another "modifier key + mouse" combination would be more direct.

Thanks,

- Michel

Hi Michel,

> Do you see it as a triple state button ?

Not in the sense of a triple toggle cycling by left-clicking - left clicking would always be for hide/show.

So whether you see an eye or a lock, if you left-click on it, it would blank out and be hidden.

If it was blank, then doing a left-click will show it and make an eye or a lock appear.


Then as far as setting the lock/unlock state, I was thinking of putting that on a button in a pop-out menu. But there could also be a key combo that would do it as well, like Ctrl+click like you mention.

I was also thinking that right-click on a lock could be unlock rather than doing the group visibility thing, but maybe that is not so good.


But the general idea is to enable having a lock state but without it adding such a high impact to the UI as a whole additional column would bring. Locking is not switched around as frequently so it would be good to have it but in some kind of subordinate way.

- Michael

Hi Michael,

>...left clicking would always be for hide/show.
>So whether you see an eye or a lock, if you left-click on it, it would blank out and be hidden.
>If it was blank, then doing a left-click will show it and make an eye or a lock appear.

This would be quite direct and clean.

About locking, it can be interesting to have two different types of locking, layers and objects.
Since the objects are automatically highlited when we move the mouse over them or their parts,
a script step could allow locking with a keypress on "mouse over".

Moving objects between layers
I just thought I'd mention something I quite like in Blender :
When the user wants to move an object to another layer,
he presses the "M" key,
a pop-up layer grid appears,
and the user clicks on the destination layer (if the destination layer is hidden, the object disappears).

Please feel free to mention if all this "outsider thinking" becomes annoying
(if it seems to bring you back in too basic things).

- Michel

>> But the general idea is to enable having a lock state but without it adding such a high impact to the UI
>>as a whole additional column would bring. Locking is not switched around as frequently so it would be good
>>to have it but in some kind of subordinate way.


Change the text to red (or greyed out) if the layer is locked? Keeps it separate from the hide/show side of things


But if you want to use the icon then for this control I think you you need more states of icon.

So you need:

Hidden but not locked - blank
Shown but not locked - eye
Hidden and locked - blank with small lock symbol in corner
Shown and locked - eye with small lock symbol in corner

I've used this technique before in a number of icons - works pretty well

Normal/right click can hide and show, CNTRL + normal/right click locks/unlocks. I would also suggest having have both hide and lock commands on the flyout too for those that just want to use mouse or tablet without resorting to the keyboard


Another tuppence worth from me for your consideration ;-)

Hi Michel,

> About locking, it can be interesting to have two different
> types of locking, layers and objects.

Yeah, I also want to have a "Lock" command on the Edit toolbar right next to where "Hide" is currently located.

That will give you a way to Lock the currently selected objects, or unlock them if there is no selection, same as how the Hide command currently works for hide/show.

It will be possible to set up a keyboard shortcut for that same as how it is possible to do one for hiding currently.


Then the basic idea is that the scene browser will allow you to apply that same kind of thing to some predefined set of objects rather than only to the current selection.


re: Moving objects between layers

That sounds like a pretty good method... The way I was figuring on doing it was pretty similar, with a pop-up panel on the object properties pane that lets you set the "Style" property of the currently selected objects, like this:





I think it will also be possible to trigger that UI to be shown with a keyboard shortcut as well, we'll see...

- Michael

Hi Tony,

> So you need:
>
> Hidden but not locked - blank
> Shown but not locked - eye
> Hidden and locked - blank with small lock symbol in corner
> Shown and locked - eye with small lock symbol in corner

That sounds like it would work well.

The only thing is that I'm not so sure yet if you really will care that much about knowing when something is "hidden but locked".

That's why I was thinking of making both "hidden and locked" as well as "hidden and unlocked" just be blank. That lets me have just a big lock icon for the "locked and visible" state which may stand out a bit more as compared to a lock in the corner type thing.

I think I'm going to give this "3 visual state" thing a try at first and just see how it works in practice. If that does not work out then I can switch to a 4 visual state type thing like you are describing.

- Michael

Ok, some concepts are starting to come together a lot more.

So the overall idea for the browser is to let you do some common actions like hide, show, select, ... on a set of objects.

This will include groups that you have specifically defined, but also some other kinds of "built in" sets so you can have one place to go (with a common UI) for doing things like:

Select all curves
Hide everything except solids
Hide objects that have style = Red
Etc...

The browser has a few different categories for some of these different kinds of sets:




Groups will be containers that you can define that can hold a list of objects or other sub-groups.

Objects shows named objects - if you assign a name to an object or multiple objects, that name will show up under this section to allow you to hide/show/select it.

Types allows you to target all objects of a specific type, like all curve objects, or all solid objects, again with all the same kind of controls like hide/show/select/whatever:




Styles allows you to target all objects that have been assigned a particular visual style. Like for example if you want to hide all objects that have been assigned the style "Red", you can do that in this section. Again with the exact same controls as the other sections for hide/show/etc...




So the idea overall is that this is a "one stop shopping" place for dealing with management operations on sets of objects, with various different kinds of sets.


There is flexibility so you can work in different ways if you want to, like if you want to primarily base your organization off of the object's visual color, you can work with the Styles section (this will then be fairly similar to traditional CAD layers). If you want to just be able to get back to one particular object easily later on, then give that object a name and use the Objects section. If you want to do some more complex hierarchies, then you can set up groups. You can use any of these strategies by themselves or mix them together.

Then additionally being able to target specific object types like "hide all curves" will also use the same UI for hiding other sets... I think you'll even be able to do things like "hide all the curves that are not currently selected" in a natural way with this.


So anyway, that's where I am at currently with the overall strategy. It seems to be coming together in a coherent way now.


- Michael

Seems pertinent...so...
Wait and see :)

Looking good so far Michael.

Hi Michael,

Do you have an idea how resolve things like:

Drawing a curve when 'hide curves' in active ? In max for example you don't see what you are drawing in that case, and well, it's a bit disturbing ^^

Lookin good Billy Ray!

Hi PaQ,

> Drawing a curve when 'hide curves' in active ? In
> max for example you don't see what you are drawing
> in that case, and well, it's a bit disturbing ^^

The way that I'm currently planning for these things to work is that they are actions that you perform, rather than a persistent mode.

So for instance if you go to hide curves, it will be the same as if you had selected all the curves in your model and then hit Hide (using the current Hide tool from MoI v1 I mean). It won't be a permanent "sticky" mode.

That would be the same behavior for all those kinds of things - groups, named objects, types, and styles.

Otherwise if these were persistent modes, there would be all sorts of conflicts that would arise (aside from having some strange effects like you mention), like what if you had set curves to be off, but then you have a named object that is a curve and then you turn it on using the "named object" UI? One thing would be saying "turn it off" and another thing would be saying "turn it on"... I would have to have some kind of hierarchy of one of those states "winning" out over the other.

By doing things as an immediate action instead it avoids these kinds of conflicts.

There will probably be some kinds of situations where a "sticky mode" could be useful, but it is just so much more complicated to have that. The "immediate action" method I think will work out to be more simple overall and it makes it easier to have many different categories to work with, that kind of flexibility should hopefully be useful. We'll have to see how it works out though.

- Michael

Seems to be a good solution indeed :)