Hi Jason,
> I like how the fillet operation works, and that's a given
> and forgive me for not citing specifics.
Well, it's far more pervasive than just Fillet, there are a whole lot of other similar things in MoI, where multiple Rhino commands have been combined into one MoI command which is context sensitive based on the current selection.
This is generally enabled by MoI's ability to select sub-objects in an easy way before you are running any command. This is a key design flaw in Rhino that I worked hard to improve in MoI.
You see, when I designed Rhino, I did not include any way to select sub-objects when you were outside of a command. Instead I relied on each command setting up an object picker with the particular object filter that it wanted, and then the selection of the sub-objects happened inside of the command.
That seemed like a good design at the time, because it allowed each command to be more simple and more focused on a particular task. Simple and focused seems like a good thing, right? Well, in certain ways it is, but it has a bad side effect of requiring a much larger set of commands to cover things. So that's why for example with Fillet Rhino has a bunch of individual commands that do different varieties of filleting on different kinds of objects.
What I did not foresee so well or really worry about so much was that having a general policy of having a lot of commands leads to an overwhelming mass of them in the UI that creates complexity and makes things harder to find and to use. In some ways that's actually OK for Rhino because it is kind of more focused on a more technical user base, but it's really bad for beginners.
It was a major goal right from the beginning with MoI to solve this problem, that's why context sensitivity based on selection is such a fundamental principle in MoI's overall design.
So for example in MoI the Fillet command covers the tasks that in Rhino require 4 commands: FilletEdge, FilletSrf, Fillet, FilletCorners. And even aside from that MoI's command also allows you to select faces within a solid to fillet which will target all the edges of those faces, sometimes that is a convenient way to target edges.
Similarly:
The Separate command in MoI does the jobs of both Explode and ExtractSrf in Rhino, because in MoI you can pre-select just some faces to separate to do the same as ExtractSrf.
MoI's Trim command covers the stuff from both Rhino's "Split" and "Trim" commands, because MoI's command has an option for whether to keep all pieces as in Rhino's split or whether to pick some pieces to discard as in Rhino's Trim. The difference between Split and Trim in Rhino is particularly bad because due to emulating AutoCAD's workflow you pick things in the reverse order when you do Trim in Rhino as opposed to Split - instead of picking the object you want to trim you instead pick the cutting objects and then run Trim and pick the object you want to trim after that. Then Split in Rhino is more conventional and you pick the object you are splitting first and then cutters in the next step. But this opposite workflow between Trim and Split in Rhino is frequently confusing to people learning Rhino for the first time. MoI is designed to be much more consistent with the picking order throughout it. The good aspect of Rhino's Trim command is that it works well for people who are coming in to Rhino who already have an extensive AutoCAD background. Actually many of Rhino's odd things are set up to make it friendly to AutoCAD users.
In Rhino there are separate commands for booleaning solids or curves or a solid with a curve. MoI's boolean commands are context sensitive and can be used with either solids or curves or a combination of solids cut with curves all with the same commands used.
MoI's Offset command handles both Offset (for curves) and OffsetSrf in Rhino.
MoI's Edit > Planar command handles creating a plane using the selected curves, or also capping planar holes in a selected surface object, combining both Rhino's PlanarSrf and EndCap commands together.
MoI's Extrude command handles Rhino's ExtrudeCrv, ExtrudeCrvAlongCrv, ExtrudeSrf, and ExtrudeSrfAlongCrv commands inside of it, because you in MoI you just select a curve (or an edge if you want) or a surface and then run Extrude you don't have to run a different command for different object types. Then the "along curve" part is an option within Extrude.
MoI's Sweep command handles the equivalent of Rhino's Sweep1 and Sweep2 commands - in MoI you pick the profiles first, and then you run the sweep command, then you pick either 1 or 2 rails and it decides to do a 1-rail or 2-rail sweep depending on how many rails you picked.
MoI's Blend command handles both Blend (for curves) and BlendSrf in Rhino.
So this kind of context sensitivity based on the selection and getting more work done out of a smaller number of commands is a fundamental and essential part of MoI's design. It's what enables a more streamlined UI and is a major factor in MoI's improved ease of use.
> Regarding contextivity (not a real word), I think there is
> improvement as we covered in another thread where base
> on objects I pick that I can issue commands without mousing
> over to another menu. Similar to other 'right click' command
> menus, or hotboxes etc there are ways to have a command
> control where the mouse is.
So the only thing that "context sensitivty" means to you is popping something up in your face right at your mouse point?
All the careful design work that I did to enable making so many commands context sensitive to the selection and combine more work out of a smaller number of commands means nothing to you? Or have you just completely not looked into MoI enough to even know much about it?
> I don't think my comparison of C4D is wrong, and
> did I not mention modo? modo started as a modeler
> but it had modular windows and toolbars from day one.
Modo also incorporated a lot of rendering functions from day 1 and so included quite a lot of different functions within it.
The ability to re-arrange the UI is much more important when the software just has a whole lot of stuff within it. Also it's not exactly a great thing for beginners when a company focuses on making the UI customizable but does not do a good job on making the default initial UI work well. In MoI the focus is much more on making the initial UI work well at first, and some easier UI modification stuff will come in the future. Advanced users can actually modify the UI already to an extreme degree by editing the HTML UI files.
> I will look at the shortcut key, due to my ignorance I
> didn't spend a lot of time to review it.
The help file is a great place to find some information, here is the help file section on shortcut keys:
http://moi3d.com/2.0/docs/moi_command_reference11.htm#shortcutkeys
Also, previously you wrote:
> If Maya can do it, MoI can do it.
Do you really believe this? Maybe you could try to be a bit more realistic - keep in mind that Autodesk is a large company that has a bunch of people working on its products. Meanwhile MoI is done all by myself and I do everything including replying to kind of ridiculous posts on the forum comparing my software to Windows 3.11 and stuff like that. So because my time is so limited I have to be more careful about what I focus on.
If MoI right now had a less refined UI but had more capabilities for easy drag/drop customization, that would just not be as valuable to as many people as a better default UI is.
It would be kind of cool if you would make just a slight effort to look at using MoI first before making silly criticisms. Why are you so obsessed with UI modification above everything else?
- Michael
