Thanks guys for very informative and interesting replies, I just wish I could articulate my thoughts better, but I think every concern I have/had has been discussed in the thread.

Long live Moi!

jnshorty,
As I said in my post, good luck with waiting for that new mesher :)

The fact that you or anybody thinks that Rhino is laid out appropriatly is a confirmation that people will eat anything.

Maybe the oportunity to do documantation for 2 months, is also a welcome mental break that a smart programmer includes into his process, so the next phase of 2 years worth of work can remain "Bug Free".

I also think that this thread is rediculous and it is not the Kuliana of the Beta or users to comment on Michaels "Personal Business". Our job is not to manage the development.

Hi jonah,

> Also I would like someone to point me to a truly good
> example of overbloating, something other than the huge
> # of available commands.

Why would you need any example other than that?

Having a huge number of commands and trying to expose them all in a conventional toolbar + menu UI is precisely what leads to the appearance of complexity or "bloat".

It's a pretty simple consequence - if you have a menu that lists 100 things in it, it becomes harder to scan through all those things to find the particular one that you are looking for.

Certainly there are some users such as yourself that do not mind having a "huge list o' stuff" kind of UI but for most other people that is where the "bloat" kind of perception comes into effect.


> The discussion has come up many times and there are always
> good reasons why the seperate commands should remain in
> place.

There is really only one primary reason and it has to do with limitations in Rhino's selection mechanism.

When I initially designed Rhino's selection and command flow structure, it was only focused on working on whole objects. That's because the initial commands that I got working were things that worked on whole objects like booleans.

When it came time to work on commands that dealt with sub-objects, I did not really have anything set up in the "pre-pick" selection stage that could address that, so I decided to make a filtering system but make the filtering controlled by individual commands so they could automatically set the selection filter to what that command needed.

That decision had some consequences, it meant that commands in Rhino needed to be separated out into smaller individual commands that could each set the particular selection filter that it needed. I did not really have a problem with that because at the time it seemed logical to try and break things down into different pieces and then try to keep each of those individual pieces streamlined and simple. What I did not consider so much is that it forces some complexity (in a high number of commands) to be pushed up to the very top level of the UI where it impacts everything.

That problem did not really become apparent until much later on when more and more commands began accumulating. Of course, once you have a lot of stuff working in a certain way it becomes really hard to "turn on a dime" and it is difficult to go back and try to change fundamentals.


Also one other part that ended up being bad about relying on commands to set sub-object selection filtering is that it leads to a kind of messy inconsistency in how different commands work. Some of them are able to use the more common "noun, verb" type structure where you can select objects first and then run the command to act on them. But ones that needed sub-objects had to pick things after the command was launched instead, leading to a kind of non-uniform behavior.


When I set out to design MoI, I really wanted to learn from these mistakes and address some of the fundamental design flaws that I had inadvertently baked into the core of Rhino.

Having a selection system that would more naturally allow for pre-picking sub-objects such as edges or faces of a solid was one of the major foundational improvements that allows MoI to have commands that combine more functionality into them which helps to keep the UI much more simplified.


There are quite a few other areas similar to this where MoI is set up specifically to address a design flaw in Rhino.


> If the claim of overbloating has to do with the UI, it's well
> known that Rhino V5 will have a new one. Not sure what
> that will look like but it's happening.

That definitely sounds interesting! Do you have any information or screenshots that show how it will be set up?

Like I mentioned previously, it becomes difficult to change things once there are a lot of pieces that are depending on how existing things work. There's not only a lot of commands in Rhino itself but also a kind of whole ecosystem with other company's plug-ins that also depend on how things currently work. All of that tends to create a kind of inertia where there is a lot of pressure to avoid large overhauls of fundamental stuff like the UI.

So don't be too surprised if any improvements in Rhino are more of a cosmetic nature rather than a fundamental re-work.

- Michael

Hi Burr, although to be fair it is not really so much "bloat" in Rhino that is stopping it from having a new mesher.

It's primarily just that making a mesher is a huge amount of work all on its own, I've probably invested something like 8 months of full time work on mine.

It tends to be a finicky area that requires a tremendous amount of testing with different shapes and trim boundaries.

It can tend to be difficult to schedule a task like this that will require such a huge investment of someone's time.


But I have viewed my own time investment in this area as very worthwhile, because it's really a fundamental piece for a lot of people. It's just so common to need to get polygon data out for use in rendering.

If the meshing does not work well, it tends to lead to a huge amount of frustration when your beautiful clean and finished NURBS object turns into garbage at the final stage.

- Michael

Hi jonah,

> I do agree that Rhino needs more command consolidation,
> but again it goes back to what i just mentioned before. Many
> users don't want the specific commands removed.

Yes, actually that's another factor that creates additional inertia making change difficult - if you have an established user base who have become accustomed to how things are currently set up, there will be a lot of people who won't like any changes made to it even if they are overall for the better.

- Michael

Hi Michael,
I was a bit confused on what I was talking about also. I was mostly refering to the "display Mesher" that I think you just refered to. Specifically, I was going to reference the "Point picker" that I think you also mentioned (Only because I have seen you already address this fundamental issue) and how Rhino would have to basically "abandon" it's entire userbase to do a "complete re-write" from the fundamental core of the application.

I dont think this will happen anytime soon. (And even if they started now, or 1 year ago, they will still be several years behind MoI's development. Moreover, since they have injected multiple developers into the Mcneal programming cubicle, trying to do this Bug Free will set them back even that much further!) I think your stuck with it the way it is.

Again, I think the base of this thread though was off and the managment of the development is not our place. But also, it's not for me to decide this for others like olio and jbshortey, so I should shut my pie hole also. :O

Burr wrote: "good luck with waiting for that new mesher :)"

JB - Don't have to. I have MoI if I need it ;)

Burr wrote: "The fact that you or anybody thinks that Rhino is laid out appropriatly is a confirmation that people will eat anything."

JB - Don't assume that I use the default layout or toolbars, because I don't! I use a self-scripted system of popups and hotkeys, complete with repeating commands, fast navigation control, axial mirroring, etc designed to facilitate single viewport modeling. Yes I know people will say the user shouldn't have to do such things. But keep in mind that UI's are a very personal thing as we all have our logic circuits wired in a different order. For example, many people love the Modo and Hexagon interfaces. I don't like either of them. Perhaps I'm the crazy one? And everybody else is right? :)

JB,
You are correct sir. I have seen your work and knowledge of rhino go by in the forum and know that you are an experienced and Knowledgeable contributor here.

I think I was confused and we are talking about different things.

Hi Burr,

you wrote:
> and how Rhino would have to basically "abandon" it's
> entire userbase to do a "complete re-write" from the
> fundamental core of the application.

There's even another issue yet, which is that there is a certain kind of user that actually can benefit from Rhino's UI structure because it is set up to be similar to AutoCAD in many aspects.

So for example if you are working at an engineering firm that already uses AutoCAD for doing drawings, when you then take a look at Rhino it would feel a lot more familiar and easier to use to someone with that particular background.

There have definitely been places where Rhino was able to fit in more easily into a company because of that.

But being similar to AutoCAD tends to be bad for people who don't use AutoCAD regularly though.


Anyway though, that can be another factor - a change in Rhino could actually make it not fit in as well as it currently does for some particular companies.

- Michael

Hi Michael. I wasn't claiming at all that the Rhino UI isn't flawed. Quite the opposite, I'm looking forward to seeing what they are developing! Most of the time I work with a maximum of one or two custom floating toolbars and nothing more. It boggles my mind when other users post screenshots littered with hundreds of buttons everywhere. My attention span is so short, I feel completely lost... :)

About the pre-selection, V4 actually does have pre-selection of faces and edges if you press SHIFT+CTRL+LMB. Some of the commands even work using the input. Such as pre-selecting a face and then running ExtrudeSrf. But it won't filter the command for you as MoI is able to do. You have to enter the specific command on your own, so there is little benefit for modeling tools. But it does work for analytic commands such as selecting an edge and running _Length or _SplitEdge. This is an undocumented feature which I imagine will lead to improved command filtering down the road. Tsplines can do pre-selection rollovers so I imagine this component was added by McNeel to support them. Possibly the mechanism is one and the same?

And yes, you are right about the existing "ecosystem" of plugins. They make it difficult to make big changes and already there is a lockdown of the SDK until V6. That's both a good and bad thing for its users, as V4-complied plugins will run in V5 but some changes to current features may be delayed...

jonah

Burr wrote "You are correct sir."

OK, we both agree I'm crazy then... :)

"I HOLD YOU IN CONTEMPT....I HOLD MYSELF IN CONTEMPT!!!"

Thanks JB. :)

Well on this sidenote of GUI of Rhino and Moi,

When I model in Moi, I feel handicapped in the way I need to find a icon for everything I do, sometime I need to pick a categorie first then find the button, then press a sub command.

In Rhino I never use the toolbars, I type everything. in that respect I find that working in Rhino has the best and fastest UI.

Is there a reason Michael of why Moi is not allowing typed commands? it's the reason I still use Rhino man:)?

In MoI everything can be typed in. Open MoI and hit tab then type "Merge" or any other command. (Well V2 anyway)

haa! that was not obvious...nice...what about a autocomplete list? or abbreviations of commands?

< In MoI everything can be typed in.

You can type a novel if you want ;

else references
http://moi3d.com/1.0/docs/moi_command_reference.htm

If you dont like shortcuts, and like to grab the inline scripts you see go by in the forum, you can save those inline scripts to a js file with whatever name you like, and place them in a folder named "scripts" in the MoI root folder and have the same function.

I think Michael has on his list a mechanism for accessing commands and plugins and such to manage them. He has mentioned he is working on where to fit that in. Possibly down by the options/help button. Again, taking great care for the future. I'm looking forward to this one also.

Possibly this will have the abbreviation mechanism you mention. :O

Hi olio,

> When I model in Moi, I feel handicapped in the way
> I need to find a icon for everything I do,

Well yes, using icons is normally part of a GUI or "Graphical User Interface"... :)


> sometime I need to pick a categorie first then find the
> button, then press a sub command.

It's not really a big problem when you only need to open categories every once in a while.

Since a category stays open once you have activated it, if you need to use other related commands from that same category you don't need to open anything for those additional uses.

That's one reason why MoI's system is a lot better than a traditional drop-down menu at the top of the screen, which forces you to always open the menu over and over again in all cases, since the drop-down part disappears after every use.


> In Rhino I never use the toolbars, I type everything. in that
> respect I find that working in Rhino has the best and fastest UI.

Sounds like you should set up some keyboard shortcuts in MoI, that way you can launch a command by just a single keypress.

Note that MoI supports using just a single character like "E" as a shortcut key. In Rhino that does not work because of the command-line interface.


> Is there a reason Michael of why Moi is not allowing
> typed commands?

Well, it wasn't a priority because it is not really what "normal" applications use.

For example when you are in a word processor, do you go somewhere and type-in "bold" when you want to make something bold? Or do you use a shortcut key or an icon button for that?


Actually though like Burr mentions you can type in commands in v2 if you want, if you press Tab first to put focus in the entry box.


There is also an option in the most recent v2 beta that will treat any typing as a command-line type entry so you don't need to push Tab. To set that up, edit the moi.ini file (there is a button for that under Options / General) and set

[UI]
CommandLineTypeTextEntry=y


But basically that kind of type-in mechanism is a very AutoCAD-centric type workflow. Unlike with Rhino it has just not been a priority to make MoI set up similar to AutoCAD, since that interface is pretty antiquated and not really friendly to users who have not already learned and spend a lot of time in AutoCAD.

- Michael

Hi olio,

> what about a autocomplete list?

Having a big autocomplete list pop up is probably a good indicator that there are too many commands and things are just too complex...

So probably that would not be a part of MoI anytime too soon since the idea is to make MoI more streamlined and not get to that nasty level of complexity in the first place.


> or abbreviations of commands?

Well, that's what keyboard shortcuts are normally used for, that abbreviates a command to a single keystroke, you don't get much more abbreviated than that!

In the future I'll probably try to set up some method for type-in aliases though.

- Michael