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