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