Hi Patrick, thanks very much for your feedback on styles!

Definitely some of the things you mention are going to be tuned up - especially the current method of editing and adding a new style is going to be handled better, I plan to have some UI for that within the browser so that you won't have to use the current workaround for that, that method of needing to select an object first and go in through the properties panel is only temporary.

I haven't quite figured out the exact UI for that yet (I'm pretty close to focusing on that though), but I've thought a bit about 2 different possibilities - one is to have an additional line under the "Styles" header that would contain "Add" and "Edit" buttons.

But I've also thought some about having an drop-down arrow on the Styles header itself which would pop up a menu with those items on it. I'm currently leaning more towards trying this way since it kind of keeps the main browser area a bit more tidy.

So definitely that area is intended to be improved.

But some of the other things that you are mentioning are kind of a consequence of how the browser system works, it is a little different than what you are used to.

In MoI's current system, the entries in the browser (like for example a Style or an item listed under Types) do not contain a value that belongs just to the style as an individual entity separate from the objects.

Instead, what you see there is a reflection of the state of all the objects that belong to that category.

When you turn "off" that category, the category does not all by itself have an "off" state, what happen is all the objects that belong to it get turned off, and then the status (hidden/visible/mixed) is updated to reflect the current state of all those objects.

In other words, the "Layer" in MoI does not have its own on/off, it is only objects that have an on/off and you use the browser to manipulate a batch of object properties at once.

This is fairly different than many layer systems where the "layer" by itself has an on-off property.

But one big advantage of MoI's system is that it allows for more than one kind of organization system, like for example "Types", and "Styles".

Otherwise it would be difficult to offer more than one system simultaneously if each of them had persisting values.

For example, if you went to Curves and set Curves to be "off", then you went to "Style = Red" and set it to "on", if those states were a kind of persistent state that belong to the browser item itself, then you would have a conflicting situation, like with a red curve.

A red curve in that situation would be ambiguous - should it be "off" because you set all curves to be "off" under Types? Or should it be "on" because you set all red things to be "on" under Styles?

MoI avoids this ambiguous situation by only storing the on/off properties on objects and not "persisting" those values for every browser item. Making them persistent is basically incompatible with having multiple categories at the same time (like Types and Styles). Having multiple categories is a pretty significant flexibility gain, so that's why I went with this method even though it may have some differences and possibly some detriments in other areas. Hopefully the benefits will outweigh the detriments.

This flexibility should grow somewhat larger yet with the addition of groups as well.


> If the style behaviour as it is now will be maintained, would
> it be possible to add a hidden layer that remains hidden when
> you throw geometry at it?

What about if you had a keyboard shortcut with a script on it that would handle that for you? I mean hit a key that would then do a combination of throwing things to a style named "hidden", as well as actually hiding them. I'm not sure at the moment if I have enough stuff exposed to make that work, but that would not be difficult to fit within the current system.


I have a couple of other things coming in the next beta, which may be of interest - one is a "Lock" capability so that you can lock an object so that it is displayed and can be snapped on to but is not selectable. This can be done either through a new Edit/Lock button (next to Edit/Hide), or by Ctrl+click on an eye.

Also there is a new "Isolate" function for the old-fashioned Edit/Hide button (the one that you previously had to use for hiding things before the browser was available). This will be available by right-click on the Edit/Hide button and it is a "state-remembering" isolate. By which I mean after you do one isolate, after you are done working on the isolated object, you can go right-click on the button again and the previous hide/show state of all objects at the time of the previous isolate is restored.


> Oh and one more minor thing: i don't get the name styles.

Well, the idea is that it is an organization method that controls the visual display of the object. They're kind of meant to be somewhat similar to layers that others may be used to, but also they're going to play a big role for material assignments when exporting to a poly format as well. Basically style is sort of meant to be short for "Visual style"...


> 3. a style state does not change when selecting the style.
> When you click it now, everything is selected, the hidden
> parts as well. And that can't be undone.

Just to clarify - here you're talking about the selection action, where you click on the name part to select the objects belonging to that browser item slot?

I've got a couple of tune-ups for that for the next beta already - undo will work to revert the selection in this case now, and also if you hold down shift and click, it will only select the currently visible items in that slot and not display them. I'm also going to be adding in an option so you can make the "not show" the default so that the shift+click has the reverse meaning if you want.


Anyway, I've still got a ways to go to finish up this area, and definitely several of the areas that you mention are targeted for tuning!

Some things that you mention though, kind of go along with the flexibility of having multiple kinds of organization methods, like Types in addition to Styles/Layers.

I think the flexibility of having a more unified UI to work with types in addition to "layer-like things" is pretty important though, it lets you have one single consistent UI presented for such things, and one consistent area to go to to work with "all curves" in the same manner as you work with "all red things"...

The feedback is much appreciated!

- Michael

Thanks for a very extensive reply.

It's great to hear that some parts of the styles will get a big upgrade, i thought that was going to happen, just not clear how.

My main concern now is that you can get a lot of things messed up by accident. Selecting geometry and then accidentally changing them to another layer. Or selecting all your hidden geometry in a layer and not being able to hide it again. I have to be really careful for the moment.
So an undo would be great. Although i can imagine that for some users the extra undo steps will be a disadvantage (like zoom and pan operations are included in autocad's undo...) Maybe ctrl-shift-z shortcut for undo with styles operation and ctrl-z for normal undo? Or the other way around?

>What about if you had a keyboard shortcut with a script on it that would handle that for you?
>I mean hit a key that would then do a combination of throwing things to a style named "hidden",
>as well as actually hiding them.
>I'm not sure at the moment if I have enough stuff exposed to make that work,
>but that would not be difficult to fit within the current system.

Would be great! I would use that rather than hiding inside the style itself. H as a shortcut to hide geometry to a construction layer that is turned of by default. And accessible when you need it.

>I've got a couple of tune-ups for that for the next beta already - undo will work to revert the selection in this case now, and also if you hold down shift and click, it will only select the currently visible items in that slot and not display them. I'm also going to be adding in an option so you can make the "not show" the default so that the shift+click has the reverse meaning if you want.

That sounds fabulous!

I think the styles system has got great potential and part of the problem is just that i have to get used to it. I just think it still lacks the straightforwardness of most other MoI features. Default behaviour should probably be a bit more dummy proof with a lot of advanced behaviour implemented with shift clicking - ctrl - alt clicking.

I'll post another remark in the next post, too much information at once otherwise..

The eye icons can also be a bit confusing - and maybe that's actually why i find the system confusing at times.

Say I want to see the faces of style magenta. What i actually see in the browser is half an eye at these tabs: 'surfaces', 'faces', 'all objects' and 'magenta'.

I can see the logic in that, but you really have to think to see what's going on. Also there is no way to see if all the faces of the magenta style are on or not (i think).

If magenta and faces would both have a full eye, there can be no doubt: all the magenta faces are on. Not all the magenta geometry is on for sure, but you know that since you can see that in the types tab. And on the screen as well.
If only part of the faces of the magenta style where visible, you would have a half eye - whereas in the current system there is no way to determine that.

I'm probably neglecting some consequences of this system that might be less favorable.
But on the positive side I think it would be more intuitive and it would contain more information.
The info of the styles and types would be complementary in that way rather than double up.

I would love to hear people's thoughts on this!

cheers,
patrick

Hi Patrick,

I sort of follow what you're saying, but apart from the few tidy up things that Michael has to do, I feel the browser system is quite simple and advanced at the same time, what I mean is, It's simple enough for a novice to use and powerful enough for the advanced user, especially once it's polished up and 'Groups' is up and running.

I know it's not as quick as typing your thoughts, But I think some visuals would help explain better in what you're trying to convey.
No doubt you'll get more feed back from this multicultural forum if you included visuals :)

Cheers

Ok you're right, here are some illustrations.

I have a drawing here with two cubes on two different styles. I only have one style visible.

Goal: showing the faces of the cube in the Red Style

1. Current system - all the faces of style Red visible


4 half eyes showing


2. Current system - some faces of style Red visible


4 half eyes showing - same info in the browser


3. Suggested system - all the faces of style Red visible


2 full eyes: faces and Red => Red Faces are all visible.
1 half eye for All Objects

(If left the solid eye, since as far as i know only solids have faces - uncapped shapes have surfaces instead)


4. Suggested system - some faces of style Red visible


3 half eyes showing - meaning some faces of the red style visible


What you don't see in n°3 is that there is more than just faces in the Red Style - but you probably know that since you are actually isolating geometry.
But I think you have a more logical form of grammar : you see ALL the faces of Style 3. That's not ALL the faces of the file, but you know that since you've hidden the other layers. Also you can now see that only SOME faces of Style red are visible (n°4) whereas currently this is not possible.


That's it. Hope it makes sense, let me know what you think!

Michael, i don't want to disrespect all your work of course. Just thought there might be a chance you like it and actually consider implementing it.
Though i guess this is more complex to program than the current behaviour.

cheers,
patrick

I'm a bit confused. Your scene browser doesnt show "Surfaces" as having antything?

[EDIT] Never mind. With my object "un-named" the surfaces field is populated. Given it a name and it matchs the screenshots.[EDIT]

Hi Patrick,

> My main concern now is that you can get a lot of things
> messed up by accident. Selecting geometry and then
> accidentally changing them to another layer.

I'm not quite sure if I follow this one - the geometry is only changed to another layer/style if you specifically click on the little color swatch rather than on the eye.

I tried to make sure the eye area was not too narrow in size to help prevent mistaken clicks. Also the part that your mouse is over (the eye part, or swatch part, or name label part) will highlight with visual feedback so you know which one of those controls is active before you click.

I think I may need some more specific information on this particular problem, I mean is it happening because you are clicking on the swatch when you were intending to click on something else instead?


> So an undo would be great. Although i can imagine that for
> some users the extra undo steps will be a disadvantage (like
> zoom and pan operations are included in autocad's undo...)
> Maybe ctrl-shift-z shortcut for undo with styles operation and
> ctrl-z for normal undo? Or the other way around?

Actually, this shouldn't be much of a problem, because it uses the special "selection undo" mechanism.

That works currently in other places in MoI - for example if you're just selecting objects normally before running a command and you click somewhere off of an object and accidentally deselect everything, you can right then do a Ctrl+z to recover your previous selection.

But it is a special kind of undo - it won't store a history of all selection actions that you have previously done, otherwise it would be painful and get in the way a lot just like the AutoCAD zooming that you mention. So it only stores just a single "selection undo", and only when it is the "topmost" item in the undo stack. So that lets you recover from a "oops, I just clicked the wrong thing" kind of a problem but not get in your way when going through numerous geometry changes.

However, at the moment it actually doesn't restore the hidden state, just the selection state, so it actually is not 100% correct for solving what you are talking about. But I think it should be possible to extend it to handle hidden/showing state as well.


> Would be great! I would use that rather than hiding inside
> the style itself. H as a shortcut to hide geometry to a
> construction layer that is turned of by default. And
> accessible when you need it.

I think I should be able to cook this script up for you now actually, I will give it a try after posting this.

But here you wrote: "... to a construction layer that is turned of by default." - just remember that in MoI the main difference is that a layer is not "on" or "off" by itself, it is only objects that are on or off. In MoI the "style" just shows what state all the objects that belong to it currently have - either all displayed (full eye shown), all off (nothing shown), or some displayed and some hidden (half eye shown).

But it should not be difficult for a script to hide the objects at the same time that it is assigning a style to them.


> Default behaviour should probably be a bit more dummy
> proof with a lot of advanced behaviour implemented with
> shift clicking - ctrl - alt clicking.

Yup, that's generally the idea for why it is set up as it currently is! :)

For example with selection, if I didn't show all the objects with the default "selection action", it could for example be possible that doing a selection would actually do nothing if all objects were hidden. That's not very straightforward.

Right now the selection action is much more predictable - if you click it, the result will be all objects of that category (like "All curves" if you click on Types/Curves, or "All things with style=red" if you use Styles/Red) will result in being selected. It is the same selection result every time no matter what happens to be currently visible or hidden. That seems to be more simple behavior.

Especially when groups are around, it seems like it would be kind of strange if the default action did not guarantee that the whole group was selected, which is what would happen if it did not also show all the objects that were in that group as well.

But there will be an option in the next beta for you to switch to that other behavior of not showing objects when doing the selection action, if that makes more sense to you.

- Michael

Hi Patrick,

> Would be great! I would use that rather than hiding inside the
> style itself. H as a shortcut to hide geometry to a construction layer
> that is turned of by default. And accessible when you need it.

Here is that script for you:

script: /* Hide selected objects, and assign to style = Hidden */ var gd = moi.geometryDatabase; var styles = gd.getObjectStyles(); var si = -1; for ( var i = 0; i < styles.length; ++i ) { if ( styles.item(i).name.search( /hidden/i ) != -1 ) si = i; } if ( si == -1 ) { var style = gd.addStyle(); style.name = 'Hidden'; si = style.index; } var objects = gd.getSelectedObjects(); objects.setProperty( 'styleIndex', si ); objects.setProperty( 'hidden', true );


To set it up, in MoI go to Options / Shortcut keys, and hit the "Add" button.

That will add in a new entry at the top of the list, type in H for the Key part (or whatever key or key combination you want to trigger it), and then for the Command part copy the above script which is all one long line and paste it in there.

Then after that, if you select objects and type H those objects will get assigned to a style named "Hidden", and also the objects will be set to be hidden so that you won't have to do any other steps for getting them out of your way.

That should make that particular operation go rather more smoothly.

- Michael

does it possible or it is silly question to replace esoteric shortcut by a real name in the first column?
for your above example : Hidden ? (for H )
I am agree that is not more a "short cut" for the speed but sometime that avoid to must re open the Options for see the second column :)
(and sorry I will see the answer on 3 days so some suspense for me :)

Hi Patrick,

> The eye icons can also be a bit confusing - and maybe that's
> actually why i find the system confusing at times.

Well, they basically are showing you what is the current state of all the objects that belong to that "slot".

If all objects that fit in that slot are on, then you see the eye.

If all objects that fit in the slot are hidden, then it is blank.

If some objects that belong to that slot are hidden and some are on, then it shows the half eye.


> Say I want to see the faces of style magenta.

There isn't really a good way to do that currently - when you go to the Types section of the browser, the "slots" in there are not referring to or targeting style information at all. Style information is only currently targeted by the things in the Styles section, not in other sections.

So for example when you see that slot for Types / Faces, it means "All faces in the entire model".

However, it tends to be rather common during more typical workflow to want to do things like just quickly hide all curves to get them out of the way - the Types section will handle that kind of need currently.

The kind of thing where you're talking about like "all faces that are magenta" is not really as typical.

I do have some ideas for handling that better with a kind of additional "filter" mechanism that you could specify, but that will be a pretty advanced and rather specialized kind of a thing.


> The info of the styles and types would be complementary in that
> way rather than double up.

I'll have to check your later message, I don't really see how that would work as the default way to do things, it would make for a pretty complex interaction between the different sections.

However, it may be possible that if you did a special action on an item, that could be a good way to specify it as a "filter" which then would have this kind of an effect on limiting what the other sections were acting on.

I was previously thinking about having some kind of more separate "filter" panel or menu or something like that on each section, but this could be an interesting idea to use the entries in the sections themselves as the filtering UI, with some kind of special action to set an item as an filtering item.

But trying to do such a thing as the default automatic way is going to make the regular use really quite difficult for a beginner, the current system where for example "Types / Curves" always just means "all curves" is really a lot more simple...

I need to catch up a bit on your newer messages to see if I fully understand what you are talking about though.

- Michael

Hi Pilou,

> does it possible or it is silly question to replace esoteric shortcut
> by a real name in the first column?
> for your above example : Hidden ? (for H )

That would only be easily possible with no other steps if I had already created every single possible script in advance and put them in a kind of "script library" which had a "simple name" associated with each script.

That's basically what a "command" is actually.

But it's just not possible for me to create every possible thing in advance - I'm always creating new scripts that are customized for someone's particular request.

The only way I could have every possible script done in advance is if I could foretell the future and know in advance every possible batch type action that will ever be requested... Not so easy to know unfortunately! :)


If you'd like, you can actually copy that script code to a separate .js text file, and put it in a \scripts sub-folder underneath MoI's main installation folder, and then you can list the name of that .js file as the Command part in the shortcut key editor, rather than the full "inline" script code.


In the future at some point, I think I'll be able to make some kind of different distribution method for scripts, like maybe instead of posting the script code for copy/paste like I did here, at some point maybe I will distribute the code in a .zip or .js file and then you would do something like drag/drop it on to MoI's main window to "install" it.

But I don't have any mechanism like that in place currently, and actually it may result in more steps, because copy/paste is pretty quick, you don't need to create or save (or then cleanup) any additional files with the current method.


I guess probably the best method would be if I had a script library that was stored on my web server, and then had a kind of browser built into MoI that would go to the web server and show you all the scripts stored there and let you pick one. But that is a fair amount of work to make something that ties into an online service like that. It would probably be the best way but would require enough work that I'm not sure when I would be able to do it.

- Michael

Hi Patrick, I've finally gotten to your last post here with the images in it.

> Goal: showing the faces of the cube in the Red Style

I think I understand now that when you say "showing" you don't mean the action of hiding or showing things like when you click on things to hide them or show them (changing their state I mean), you mean just the status display of the eye?

Then what about with the actions like clicking on items in "Types" - would you want that to also work in a similar restricted way so that once you only had red showing, clicking on Types/Curves would only show red curves only instead of all curves?

I think that would have some major negative consequences, because it would mean for example that you could not do an operation on all curves just by going immediately to "Types", you would have to first go through all styles to turn on all of them first, before the actions in "Types" would impact all objects.

That's potentially a lot of extra steps for some of the most simple actions like "show all curves" which are very easy to do currently.


Also, I think it would be pretty confusing if the status display was a separate thing from the actions. I mean it would not be good to show the eyes in Types by a kind of automatic filtering by styles, but then target different ones when you clicked on them. For predictable and simple operation, it should be the same items targeted whether it is for status display (how the eye is shown) or what is targeted by actions like clicking.

So really the key thing under the system that you are talking about would be to understand the consequences of how the actions would work, not just the status display alone...


I think what would be more feasible would be if you could do some kind of special action that would declare some item or set of items to be working as a "filter", which would then cause the kind of narrowing effect that you are talking about, for both status display and actions. But I don't think it would work to do it totally automatic, you would need to do something special to get a filter, the default is a lot easier to understand when Types / Curves just always means "All curves".

- Michael

Hi Patrick - just another note on this - for the next beta I've extended the "selection undo" mechanism to also cover hidden and locked states as well, and it works with the browser actions.

So this means that if you don't like the result of an action you just did with the browser, you can hit undo (either the button or Ctrl+Z) to revert it.

It is a kind of a special "shy" undo - it will only revert just the very last hide/show/select/unselect action, so that it doesn't get in the way of stepping through a longer list of geometry changes.

This selection undo is something that actually works in MoI v1 for other basic selection actions like say you have built up a selection and then you accidentally clicked out in space which deselected everything - in v1 you can hit undo in this situation to revert that selection change.

With the next v2 beta that same thing will now be available for reverting the last browser action in a similar way.

That should probably help quite a lot to reduce worries about possibly messing up your visibility or selection states by using the browser.

- Michael

Michael, thanks a lot for all the feedback! And for the script - that will settle my issues perfectly for the moment!

I don't have time to get back on everything now, and don't think it's a good idea either, as I don't want to get you off your work!

My conclusion from what I just read is
1. I'm probably just messing things up because i'm not used to the style behaviour yet - it's getting better though.. Using different programs at a time and hardly getting any sleep might have something to do with it :)

2. that we probably favour different style behaviour for different reasons. While you would like to have all curves selected when clicking on curves rather than only those that are currently visible, I would favour the opposite. But I'm modelling architecture on a large site for the moment. So when I'm working on one building and need the curves of that building, the last thing I want is selecting all the other curves in the scene... When working on a single objects I can imagine the other behaviour is more straightforward.

Selecting all the visible curves is as much predictable behaviour to me as selecting all the curves - and the first option is much more useful to me. If you need all the curves on a regular basis, you can make a group for easy selection. Otherwise I think you mainly need the geometry of the part you're modelling at the moment.

>But there will be an option in the next beta for you to switch to that other behavior
>of not showing objects when doing the selection action, if that makes more sense to you.

Well, that actually settles my problem! So thanks a lot, hope you didn't do all that effort especially for me. I'm pretty sure some architectural users will favour that behaviour so it's a good idea to test it out in the beta i think.

Sorry i didn't make myself more clear from the start, but i think in the end we understand each others points!

Thanks a ton for the VIP treatment, you take customer care to a whole new level!
a happy customer

Thx for the explanations ;)