To all,

Michael G. has made amazing progress with his Moment of Inspiration modeling software. I use it in line with the other modeling programs that I use every day in the manufacturing world. I intend to purchase the next revision v2 for myself after owning v1, and purchasing the v2 release for the company I am employed with outside of my freelance work. My staff and those that I support with CAD have been deeply impressed with what I have been able to show them in presentations and proposals and as far as up to production ready models, that I am obligated:-) to purchase this software for them to use as well.

Sorry to go on, but I see no reason at this point to question Michael G.'s motives or his ability to continue to improve upon his program.

Michael T.

Small bug in both statements... true cost of Rhino (in the states) is approx $780 online. Of course, outside the US is horribly overcharged. Don't know why McNeel continues this silly policy...

Also I see little point in trying to directly compare Rhino and MoI, as now Rhino has stepped far outside the role of being just a modeler. And the features being developed for Rhino 5 will exaggerate this even further, as it seems to me that Rhino's becoming the Maya (or possibly the XSI) of the CAD world. You can't possibly compare Maya to Hexagon or Silo on a linear scale. If anything, I expect that Rhino and MoI will evolve along more complimentary paths in the future...

Burr wrote: "Rhino "Redoing it's mesher", in it's current, "overbloated" state, is going to be, quite possibly, an impossible task"

Sorry Burr, but I doubt this statement holds much water. There have been two alternative meshers developed recently, one from Tsplines (which overrides the default mesher) and another one from McNeel. McNeel could build another new mesh system and have an option to use either the new one or the old one as default until all the kinks are worked out. I expect that's how they will handle it, so nobody has to worry about breaking stuff in the process... Also I would like someone to point me to a truly good example of overbloating, something other than the huge # of available commands. The discussion has come up many times and there are always good reasons why the seperate commands should remain in place. The best reason is that one can quickly access a specific command by the keyboard and not have to click through options they don't need. options can remain sticky for that particular method. When you have to repeat a function many times; this is a blessing, not a curse... 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. And it would be quite easy for a scripter to create a single uber-command which analyzes the type of input objects and then calls up the standard Rhino command to handle that particular case. This is something I've already suggested, and i may do it myself at some point for commands such as Booleans... 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. But I hope it looks and works like Grasshopper's UI which is already very nice! :) So I doubt anything is really "impossible"...

Sorry for the OT... :)

While I don't believe there is too much to worry about in the near future, I can't help but agree with Olio just a small bit.


Already owning Rhino v2, MoI's USP (unique selling points) for me were:

1) It's gorgeous mesher; I stopped using Rhino for the mere fact that what I would get out of it was too heavy / ugly to work with in my animation app.

and

2) The gorgeous GUI; Even with the great GUI, for me the Mesher was the justification for me to buy a similar app (and by the same developer of Rhino) than just upgrading to the latest version of Rhino.

I will also say that I was saddened when I was considering upgrading my Rhino package (v3 at the time) and heard that Michael wasn't no longer part of the project. I had actually thought back in the v1 days that McNeel was Michael's company!

Imagine my glee however when I discovered MoI and learned it was Michael again doing the development! :-)


So if Rhino did come out with a comparable mesher and say a better GUI then MoI's USPs will take some damage in my mind...


The one place where I agree with Olio directly is with say the documentation; that is definitely time Michael could be working on new code while the docs are done by someone else with his direction...


Michael is an amazing programmer with a gift of developing bug free code so I'm also happy with how things are going.

I don't think there will be too much to worry about for good amount of time to come.

-Will

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