Hi Michael,

I've spent the last week looking at various Nurbs/Solid Modeling applications to complement my main OS X poly modelers (C4D & Modo with an ample sprinkling of Sketchup too) and have spent a fair amount of time with Moi (around 20 hours). I've used Rhino a fair amount over the years so the core 'modus operandi' of Moi made complete sense to me (I also downloaded the latest OS X beta of Rhino too, seeing as it's currently free to use and it also enabled me to asses if there was much from the Rhino toolset that I'd miss in Moi).

I love the whole streamlined design ethos of Moi, it really clicks with the way I like to work. Even though Moi's nurbs modeling toolset is a very different beast to the parametric poly modeling of Sketchup, IMHO they are very similar from a user experience perspective. Both of them allow you to quickly sketch out ideas whilst maintaining true CAD accuracy; where Sketchup has 'inference locking', Moi has 'construction lines'. These modelling aids alone are the things that make all the difference to me in both applications.

I really could make do with the Rhino OS X beta for the moment as I know most of the toolset relatively well but Moi enables me to achieve my goals in a fraction of the time.

However I do have a couple of bugbears from my time with Moi so far:

- My first is that the OS X version runs via Wine (at least that's the case with the V2.52 beta, not sure if the V3 beta is now a native application seeing as it's only available to licensed users) but to be honest it's not that much of a hindrance and it's certainly more flexible than giving over a ton of resources to run Moi via Parallels. My main concern is that the copy/paste workflow between Moi & Rhino doesn't function on OS X as it does on Windows.

- I love the fact that the interface has been designed for touchscreen interaction (my 24" Cintiq has never been so happy), although I think the UI needs a few tweaks as it's not very flexible for larger screen sizes/resolutions (lot's of wasted space). And for a program that's centred on simplicity, far too many power features are accessed via scripts (but being a geek I've obviously already customized the demo via stuff I've found here in the forum, via Petr's excellent script page and those in the manual - but this is a general observation about Moi seeing how accessible it is compared to most other nurbs modellers). I get the logic of the layout I just think it could be a little more dynamic, especially seeing as it's delivered via HTML/CSS. I'm aware this subject has been discussed a multitude of times already on the forum so I won't labour my point (too much!). A prime example for me is the number of clicks it takes to get from say a transform action to a boolean action (three separate clicks). Reducing this by even a single click (by allowing the user to both open the construct tab and select the boolean sub menu on mouse release) would make a huge amount of difference to the overall user experience.

These are minor quibbles though in the bigger scheme of things. It's been a very long time since a modelling program has so instantly clicked with me and I feel certain that I'll be purchasing Moi at the end of my demo period (especially if V3 is being released as an OS X native application).

Keep on keeping on.

Jonathan M

Hi Jonathan, I'm glad that you're having fun with using MoI and that it's clicking so well with you!


> - My first is that the OS X version runs via Wine (at least that's the case with the V2.52
> beta, not sure if the V3 beta is now a native application seeing as it's only available to
> licensed users) but to be honest it's not that much of a hindrance and it's certainly more
> flexible than giving over a ton of resources to run Moi via Parallels.

It's actually a combination of Wine with some native Cocoa elements for some key areas too, that's why for example you get the native OSX file dialog when you go to save a file.

This is the same for V3 as well, producing a fully native application would involve a major amount of work so it's not going to happen anytime soon.



> My main concern is that the copy/paste workflow between Moi & Rhino doesn't function
> on OS X as it does on Windows.

Actually clipboard functionality is another area where some native OSX code comes into play. Copy/paste between MoI and Rhino on OSX should be working as long as Rhino is open at the time that you're doing the pasting. It could be possible that this has been broken by changes in Rhino I suppose.



> although I think the UI needs a few tweaks as it's not very flexible for larger screen sizes/resolutions (lot's of wasted space).

Yeah this is a consequence of the current UI design target which is having one single UI that can work on both a small screen netbook as well and does not require only a high resolution screen to run. In the future I'd like to try and do something for high res screens to take more advantage of the additional space. That's will involve a lot of work and planning though.



> And for a program that's centred on simplicity, far too many power features are accessed
> via scripts <....>

Not letting more specialized "power user" functions clutter up the UI is one of the things that helps keep the UI overall more streamlined and more useful to beginners... So this is pretty much intentional that a lot of special one-off things are delivered as scripts instead of baked directly into the main UI. In the future I do want to work on making it easier to manage plug-ins and scripts by some kind of script library UI, I have not had a chance to focus on that yet though.

Thanks for the feedback!

- Michael

Hi Jonathan, re: copy/paste between OSX Rhino and OSX MoI - I just tested this with the most current Rhino OSX release and it seems to be working fine for me over here.

Just make sure that Rhino is running when you do the copy from MoI, if Rhino is running MoI will do some extra work to put Rhino format stuff on the clipboard for pasting into Rhino. If Rhino is not running, MoI will only put MoI-specific stuff on the clipboard.

Also Moi does not read some kinds of things that Rhino has like lights, polygon meshes, or block instances. If you've got block instances explode them first before trying to copy/paste them from Rhino into MoI.

- Michael

Thanks for the reply Michael.

In general I'm all for keeping things simple, approachable and accessible, so I think your plans for a UI based scripts/plugins library sounds great.

At the moment there appears to be a lot of fragmentation of available resources for customisation of the MoI user experience & toolset. I understand that MoI is a 24/7 thing for you (judging by your responsiveness on this forum) but it's a pity that new users have to search across a range of resources to find quite simple things (seeing as both Petr's script resource and the Wiki are over a year behind current developments. A prime example from my own usage patterns this week is that I was looking for a way to have the object snaps permanently open (as I like to change these on the fly as I work) and it took a number of searches on the forum for me to find the script/html file I was looking for. I would consider this feature to be core to MoI and not a 'power user' feature and the sort of thing that should be easily accessible.

I'm sure you have enough on your plate getting the V3 version officially released in the coming months and you probably have a long queue of worthy feature requests to implement in the V4 dev cycle when that begins so I just wanted to highlight a few observations of my experiences so far. Overall I'm still astounded at how you've made such a deep modeling technology so accessible (no small software/UX engineering feat) and I'm glad that this is still your primary design goal. As great as Rhino is, the last thing the world needs is another nurbs modeller with thousands of commands to clutter the UI/experience (the vast majority of which will remain untouched by the majority of users).

jm

Hi Jonathan,

> At the moment there appears to be a lot of fragmentation of available resources for
> customisation of the MoI user experience & toolset.

Yup, this is because streamlining the process of customization has not been a high priority for MoI yet. Customization just in general is something that I consider to be in the specialized "power user" type area of usage and not really part of the core basic functionality.

The main resources though are previous messages here on the forum and also Petr's page which you've already found.

I have to admit, I sometimes wonder about the wisdom of having the various kinds of customization and scripting available in MoI at all.. It can be somewhat discouraging for me to help people do individual types of customization but then end up with criticism about it not being all documented and categorized or whatnot at the same time as well...

At any rate, I do definitely want to improve the customization experience in the future, there are just other more basic and more widely applicable things that still need attention as a higher priority.


> A prime example from my own usage patterns this week is that I was looking for a way
> to have the object snaps permanently open (as I like to change these on the fly as I work)
> and it took a number of searches on the forum for me to find the script/html file I was looking
> for. I would consider this feature to be core to MoI and not a 'power user' feature and the sort
> of thing that should be easily accessible.

It's a kind of odd example - MoI is really designed so that it works well to just leave all object snap types left on all the time. Things that caused problems in Rhino like with how Center object activates all the time are set up differently in MoI.

It's intended that other than for some specialized purpose you should just leave all object snap types enabled all the time and only turn on or off object snapping as a whole (by clicking on the bottom toolbar button for it) if they are getting in your way for a particular situation.

That's how I use it, and from what I can tell from the overall low amount of discussion about this particular thing I'm pretty certain that the vast majority of users do that as well...


I guess maybe it's possible in your case that you feel you need to have this particular UI set up because you do need it in Rhino? But you need it in Rhino because of how some of Rhino's object snaps work where some of them kind of hog attention and so can't be just left on all the time.... The same issue has been designed out of MoI's snaps specifically so you don't need to constantly enable/disable individual snap types in MoI.

- Michael

""""""""""(seeing as both Petr's script resource and the Wiki are over a year behind current developments. """"""""""""""

Those resources pages are also more geared towards "a release" which was a year ago or so for the released V2.

The beta process moves fast and many things change, even core stuff.

The resource you are looking for is right here! There are many people that follow along and understand some of the changes that are happening and can help give you info you are looking for, and Michael responds every day.

So instead of digging in the wiki, just ask here, and you'll get 5 or 6 responses within minutes.

> I guess maybe it's possible in your case that you feel you need to have this particular UI set up because you do need it in Rhino? But you need it in Rhino because of how >some of Rhino's object snaps work where some of them kind of hog attention and so can't be just left on all the time.... The same issue has been designed out of MoI's >snaps specifically so you don't need to constantly enable/disable individual snap types in MoI.

And you've succeeded magnificently well in this department. As I mentioned I my first post the overall construction lines/object snapping workflow is the thing that has impressed me most about MoI. It's just a personal preference that probably has more to do with how I use snapping in my polygonal software suites - C4D & Modo, both of which have vastly inferior snapping to MoI hence my reliance on Sketchup for polygonal prototyping (which also has excellent snapping via it's inference workflows). It's nothing specifically to do with MoI or Rhino, I just at times (especially on detailed models) I like to turn down the 'visual clutter' of having every snapping indicator flash in my viewport.

Apologies if I appeared in any way over-critical, I hoped I was being constructive about my own personal experience with MoI. An experience which in the main has been nothing but pleasurable.

jm

Hi Jonathan, no problem - and certainly your feedback is valid too!

It would be better if there was more information in the wiki. But I sort of don't really like messing with it that much so it tends to get neglected. I just prefer to focus my energy here on the forum and in improving the software itself.

And certainly a better overall organization of scripts and customization resources would be helpful. I do want to have that in the future. In a certain sense I don't want to spend a lot of energy on the wiki for this purpose since I think that a kind of built in library browser would be better in the long run. The trick is finding enough time to work on that, it will probably still be a while since there are just other more fundamental areas to cover first.

For UI customization a tricky problem is how to allow UI customization while at the same time incorporating changes to the UI that come from new feature additions as well.

The things you are asking about will come eventually I think, it kind of takes a long time to do a good job in these particular areas though.

- Michael

Also is copy/paste back and forth between MoI and Rhino working ok for you now?

- Michael

I noticed that they released a new beta of Rhino this week so I'll download that in the morning and let you know - it's 2am here in the UK - burning the midnight oil once again so must get to bed!!! :)

Downloaded and tested and it works perfectly on OS X as it does on Windows. Must have been a glitch in the beta build of Rhino I was running. :)

Thanks again

jm