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 ;)