I think having a more unique Mac version offers the chance to market that point. ‘tailored for mac’… ‘a real Mac app’…(or whatever)
to some or maybe many people, that will be a decently strong sales point.
(not mean as a counterpoint towards you mr.pelican… nor meant as a guess at mcneel’s reasons… just sayin.)
Thanks for that one, Pascal. I’ve added my vote and a comment to the YT issue.
I find it hard to recognize what is unique to the Mac any more. With versions of windows often covering or even exceding the look and feel of the Mac interface.
The Mac GUI was unique when it was the only GUI … but now with strong product lines like Adobe generally creating identical user interfaces in and on both the Mac and Windows… apart from the Control vs the Command keys, when using both I find little difference. Which is what Rhino 3D should have been on the Mac… so one could use either machine base (Mac or Windows) and still felt confortable running Rhino 3D on either.
Greg
I like the Mac version better (missing yet to be elements aside) and took the time to modify the Windows version to match the Mac as closely as possible. Conversely, one can do the same with the Mac version - make it look like “your” WinRhino where you can.
In time it is logical that specific unique elements of both may morph into each other.
I don’t deny anyone there preference which GUI they choose to work on. I use both all the day long.
But in terms of hardware compatibility and user platform. i.e. Graphic Cards… you will wait an extra year and then have only a few choices to come close to that which is available on the PC platform (and pay a third more for the Mac version). Not to mention that plug-ins to Rhino 3d that require a working relationship with some graphic boards… and that some plug-ins will never be on the Mac side of Rhino 3D (some developers cannot afford the time or expense of developing for the Mac).
Not to mention that in terms of hardware for the Mac there is only one Round Desktop Mac in the last 8 years to come down the pipe. And at a value of 8 to 10 thousand dollars… I can build 2 or 3 quick PC’s for that money. This does not even touch on the fact that the actual market is trending to iPads and iPhones and $5apps.
Greg
Actually only sorta true.
You can run any NVidia card you’d like in a cMP, without needing a Mac specific version. You just need the web driver installed. You’ll lose the boot screen (but as long as you’ve got an efi card around that’s not a problem either. I have 2 cMP’s both with dual gtx 970’s of various flavors in em. Apple would just prefer people remain unaware of this and the fact you can upgrade the procs as well because they want you to buy the trash cans. Toss a SSD, a couple 3.46 Hex cores and a current gen graphics card in a 5 year old CMP for 1/6th the cost of a NMP and have a screaming fast platform for less than a new Mac or PC. The cMP was the last truly scalable machine apple ever built and it’s still very viable today.
Pascal: Your suggestion to “complain loudly about clunky workflows”, is something I don’t hear nearly enough! 
I’ve got some pent up energy on this topic, so please forgive the length of this. The forum does many things very well, but is it good for usability items? Hmmmm… not so sure. Over the years, usability suggestions are continually subjected to a predictable gauntlet of interrogation (by both commenters and McNeel folks, alike). Rinse and repeat for every new idea:
This makes for some good entertainment at times, but rarely seems to advance meaningful change (with the exception possibly being the very bold move a new light bulb icon in the layers—Wheee!). Part of the challenge on the forum is that there are (other than “how to” questions) at least two different types of posts:
A) Does X function properly?
B) Does X function optimally?
Generally, people assume that ALL posts are about A. This is a huge problem if you’re posting about B. Further, there is no clear way of distinguishing between A or B other than through wordsmithing.
“Type A” items are Quantitative/Analytical/Performance issues, comprising the majority of comments here. They’re generally pretty easy to evaluate and implement since they are usually Yes or No items. If Not functioning properly --> Validate problem and fix. If functioning properly --> Instruct user about their error.
“Type B” items are Qualitative/Emotional/Delight issues occasionally raised by the naive or stubborn. This topic is my primary concern at this juncture. Usability items are MUCH more difficult to evaluate and implement because different users may value very different (and often contradictory) ideas; thus, agreement on “the problem” is often rare, and improvements are almost impossible. Absent larger, clearly communicated and agreed upon goals from McNeel, the end result is often “misunderstanding”, and/or “why fix what ain’t broke?”
Despite appearances, “Type B” items are incredibly important to the ultimate success of products—especially ones that people spend a good deal of time with. Software users, like car owners, may intellectually and analytically convince themselves of the benefits of “Type A” because it’s sensible and capable, despite being a bit homely or clumsy. Emotionally, most people will fall deeply, passionately in love with “Type B” if it fits like a glove or gives them cheek-splitting grins, even if it’s a bit tempestuous or impractical. [If you’ve ever driven one of those new Corvettes on twisty back roads (as a friend of mine foolishly let me do with his new car a few weeks ago), you know exactly what I mean. If you haven’t, immediately seek out a test ride!)
What might help?
From my perspective, a primary problem is that there (still) seems to be some ambiguity among users about McNeel’s goals for MacRhino specifically, as well as a future where WinRhino and MacRhino will soon both be in the wild together. Whether McNeel is in fact still identifying these goals or simply needs to more clearly communicate them in an obvious manner is unclear.
Here are a few questions that seem worth answering clearly and obviously:
Will MacRhino/WinRhino files be 100% interchangeable?
Yes for geometry (as is currently the case), but I believe this is not essential in the near future for materials for rendering. It’s hard enough for one person to do a high-quality rendering on one machine, let a lone two different ones with different operating systems.
Will MacRhino/WinRhino working methods be 100% similar?
Seems possible (and possibly prudent?) in the long run, but in the short run, MacRhino will be better received by new Mac users if it is a super well-refined Mac-like product. Don’t like this WinRhino users? Use WinRhino.
How are Mac/Win improvements to be handled in the future?
This is a key topic. Ideally both would move forward equally, but this is impractical for a variety of reasons unless (or until) they are running on the same core code. Because MacRhino users have zero legacy issues, it seems a much better platform to explore innovations beyond mere tweaks. My suspicion is that MacRhino users—lacking years of working methods that have ossified into canonical conditions carved into stone tablets (even though they may be less than ideal—will have “fresh eyes” that will be useful. Like guests at a family reunion, they can innocently ask, “So, what’s the story with these lime green Jello cubes with cottage cheese mixed into them? Do you actually eat them, or just sort of push them around on a plate until they disintegrate to please Grandma?”
Should MacRhino/WinRhino interfaces be identical?
I’m a strong supporter of the interface work done thus far. Eventually matching interfaces seems desirable. For now, though, push the MacRhino work as far as it can go on its own. Could even treat this like “skins”. If using MacRhino for exploration and innovation, it probably makes sense for WinRhino to eventually adapt the MacRhino aesthetic once you like it. Legacy WinRhino interface should be an option in Windows if it’s changed (for the vintage crowd). Bonus points for also allowing MacRhino to have the option of a (current or legacy) WinRhino interface.
Rendering Futures?
"This is (and has been) Rhino’s Achille’s Heel for a long time. No other widely used program that I know of requires the purchase of a very expensive (about the same price as the software?!?!) 3rd party, professional-grade rendering engine for casual users to simply get a reasonable rendering of some doohickey they want to 3D print. To launch MacRhino without a reasonably decent rendering engine built into it seems truly unfortunate—especially when Toucan is exactly that, but has been deleted because: A) materials aren’t compatible with WinRhino (new Mac users will care little about this), and B) “at some unknown future date really cool stuff will happen with regard to renderings!”. Wake me up when we get there. Relying on a renderer from 3rd party companies will not only take time, but it puts McNeel at a competitive disadvantage simply in terms of purchase price, since another program will likely be required to be purchased.
Suggestions for Usability Discussions/Explorations?
I once served on the board of a school for youth with learning disabilities. Great group of people. They were fond of saying, “Whatever we can do, we can do better.” And they meant it. Continually tweaking things to remove pain and maximize gain. McNeel has often impressed me with a similar attitude about relentless improvement.
That said, improvements for Type A-Functional issues is the overwhelming focus. With Rhino being based upon my least favorite drafting program in the world (OK, mid 1990’s Arris was worse), there is PLENTY of room for usability improvements.
Suggested are (any/all of the following:)
McNeel to post a clear list of goals and priorities for MacRhino and how it is to relate to WinRhino and future developments (if this already exists in one place somewhere, would appreciate a link).
Create a sticky at the top of the MacRhino thread, or maybe even a separate forum for usability/wish list items to be separated clearly from bugs and questions.
Introduce toggles for every new thread: Bug / Question / Improvement
Invite people interested in UIX and usability improvements to create a sub-group focused on this topic. Could even imagine a private link of beta explorations to members of this group.
Other ideas welcomed!
Whew… I’m as tired of writing as you are of reading this—Sorry! ~Dave
Well, at the risk of falling into one or more of the pigeonholes you outlined above…
Since you obviously don’t have those years in there, I would like to simply state that Rhino working methods have continually improved over the last 20 years or so - and you are benefiting from it, because MacRhino is using all of those hard-won years of user testing and optimization.
Aesthetics actually have not all that much to do with it. It is a question of using the native tools and interface elements supplied by each OS instead of having to design custom interfaces for either or both. So little chance of the Windows version having Mac-like “aesthetic” and vice-versa.
It also again implies that Mac users are all about exploration and innovation and Windows users are not. This is completely non-factual. And aesthetics don’t have all that much to do with functionality in this case.
Again, non-factual. Rhino might have been based on that program a couple of decades ago when it all started, but both have moved on since. Over the years, there are thousands of people from all different disciplines have worked on improving Rhino and taking it in its current direction, very different from “that other program”. To a Mac-user it may seem so, but Rhino “for Windows” is actually not a very Windows-like program. Usability has always been privileged over strict adherence to Windows “standards”.
There have been many suggestions/discussions of UI improvements for Rhino over the years - long before MacRhino even existed. (On WINDOWS? With canonical conditions carved into stone tablets? Oh my, how is that possible?)
In the end, this is where we agree. Ask any core Rhino user (Windows or Mac) and they will just tell you they LOVE using Rhino. It IS emotional. The Rhino community of today feels a lot like the Mac community did in the 80’s (btw, I was one of them). They knew they had something that was different, better, and that it felt good when you used it. I still have an incredible joy in using Rhino every day (yes, even on Windows), if I didn’t have that, I think I would just get out of the business.
–Mitch
I don’t find your information to be “on topic” It deserves its own posting in a programming section where you both can fence back and forth intellectually to your hearts content.
Greg
(Greg: Sorry to disagree—this discussion is a deeper look at the core issues that relate to the original post: “Having trouble adapting to the Mac version from PC”)
Hi Mitch… I suspected this would prompt a vigorous response from you!
First, let me apologize for the lack of clarity when using the expression “MacRhino aesthetic”. I do not mean simply “the Mac look” as a visual thing only. I mean “the look and feel”, implying far more than looks. This is a user interface and usability reference including very specific operational methods that may benefit from improvements, such as more intuitive “Subject-Object-Verb” working methods.
True. I only have one decade of WinRhino experience, and the Gumball was developed following my suggestion to McNeel’s developers when I had even less experience (and yes, this too encountered the same gauntlet of interrogation and doubt I’m trying to describe for other ideas by many here). My question is does it need to be so hard to suggest improvements?
As for topic of amore: the order of operations in Rhino is the central item that prevents me, personally, from LOVING Rhino, to “liking it very much”. (OK, the snaps in Rhino are absolutely irksome as well—powerful, but clumsy, and I light a candle every time I try to fillet solids). The way in which the Object needs to be identified prior to the Subject to be operated on in most operations is completely unlike English. THIS is the pernicious inheritance from AutoCAD that still lies very much at the heart of Rhino, no matter how many other very good refinements (and there have been many, many, no doubt!).
Did I LOVE PowerCADD+Wildtools? Almost without reservation. (And, not surprisingly, I say this rarely.) The working methods in PowerCADD and Wildtools were powerful and joyful. If you’ve not experienced them, try them. They are very much in alignment with many of the neat inventions you’ve concocted. They’ve done things with 2D vector geometry that most people can’t imagine are even possible, and with a kind of ease that is initially indistinguishable from magic. And no, I’m not a fanboy. I simply believe that good work deserves to be acknowledged as such. Would that they would develop a 3D program and possibly give McNeel a run for their money!
Could I LOVE Rhino? I sure want to—it’s by far the best 3D surface modeling software out there and the developers and user community are unequaled. For many, especially people with less than two decades of experience, Rhino is powerful, but only sometimes joyful. Should it take twenty years to fall in love with Rhino? Seems a bit of a long time to wait… 
Absolutely, and that’s helped MacRhino be very good from early on. The freedom of development from established methods has been very healthy, allowing a number of things to be examined and questioned along the way. We all win. So help us here since I, and possibly others, are a little confused—are you upset by the suggestion that both MacRhino and WinRhino can be better, or do you disagree that this is possible? If it is possible, are efforts in this direction something that only veterans with two decades in the trenches able to engage in? Or something else?
Uhm… Like you, I use lots of different software on different operating systems. Anyone using computers of any kind is inherently interested in exploration and innovation. Where we appear to disagree is with regard to the definition, role, and importance of “aesthetics”. It ain’t just about pretty graphics.
I’m glad you experience incredible joy using Rhino…and envious. I want to also, believe me. So, here I pose the question whether more joy can be introduced in MacRhino specifically, and possibly also in WinRhino. If so, what’s the best way to pursue these goals? The constant barriers and attacks levied against those who venture suggestions here on this forum do not help anyone, nor do they help McNeel develop the very best new product they can for a new market with possibly different expectations. Got any suggestions?
~Dave
[quote=“MrPelican, post:64, topic:19925, full:true”] so one could use either machine base (Mac or Windows) and still felt confortable running Rhino 3D on either.
[/quote]
what parts are uncomfortable for you?
sketchup… maybe the most widely used one of them all
Ha. Nice one.
However, beauty is in the eye of the beholder. I know many students who do complex architectural models in Rhino, then do their renderings with the default render engine in SketchUp.
Apparently, they like “the look”. VRay was available, but too cumbersome. They really dug Toucan, too.
~Dave
Continuing the discussion from Having trouble adapting to the Mac version from PC:
what parts are uncomfortable for you?
[/quote]
After opening a few of my files and giving the first candidate a short road test, it looks to me that a great many people at McNeel have put in some long hours to make a well healed Macintosh application. They seem to have covered the bases and clearly adopted the Mac GUI. My only issue is the crowded masthead of information at the top of the 4 up view. It seems to take more vertical space than the Windows version. and the duplicate bunch of tool icons on the left side of the main screen now have a on/off icon (above) to hide it. and to get an object to orbit in i.e. the perspective viewport, I seem to get the typical “item options” when I right click over an object… but when the mouse is moving and I right click It starts the object to “orbit”… and its slower (graphic card) on the Mac vs my PC. These are my first impressions and small issues. I spoke to soon without thinking, and didn’t give it a chance… I’m sure it will be well received.
Greg
I have a (long) list… I’ll try to write everything down - just give me a couple of hours No, seriously, I just have to much work right now… perhaps later today.
Philip
OK, yes, I’ve heard this several times already. First, I don’t think this is necessarily a good analogy, if you think of the input objects as the “subject”, and the action as the “verb”, there isn’t always an “object”. In most cases Rhino actually lets you use noun/verb OR verb noun (it’s one of the few programs that does, incidentally). That is you can either pre-pick objects and then do something with them; or choose the action first, then choose the objects to act upon. Obviously there are cases where one or the other is impractical and this excluded, but in most cases it works.
I do agree there could sometimes be more intelligence on the part of Rhino in trying to interpret the user’s desires depending on what kind of objects are prepicked, such as in your Connect example above. I also agree that the Extend sequence has always been annoying. Part of this is the attempt to put too many functions into one single command with options. Most of these situations I have just macroed around, for example, I virtually never use Extend>to Boundary so my alias for Extend is actually a macro:
! _Extend _Type=_Natural _Enter (post-pick required, of course)
If I need a boundary I use the toolbar or menu command.
I think we need Specific examples for specific commands here, because I don’t believe you can generalize across the board.
Not at all… Completely wrong. I welcome any improvements to Rhino on both sides. Unlike some others, I don’t see MacRhino and WinRhino to be two separate entities - for me, it’s just Rhino. I’ve said that since MacRhino started developing in 2007 and will continue to do so. I’m not in favor of the walls people try to build between the two versions and platforms. I’m one of the people who has to use/teach (and now sell/support) on both.
I am also in favor of Rhino remaining as open and flexible as it is currently. Sometimes that has unwanted side-effects of requiring more effort or some customization to do certain operations. I prefer that those things remain possible, rather than simply saying “this is only needed by 5% of the users, so we won’t bother”. As with your Connect example I do believe efforts should be made to streamline and rationalize the process for the other 95% if possible. This may mean actually separating out some multi-option operations into separate procedures, so you could have a “ConnectLines” command for example. In other cases, dialog interfaces that don’t exist today need to be implemented, for example a combined Extrude dialog with all the options in one place and that has a realtime preview. (asked for this about 5 years ago)
I have never once tried to put up barriers to possible improvements. I will however challenge statements like “this or that is bad and needs to be improved/modernized/whatever” that aren’t backed up with any concrete example of how it could be made better, or that concentrate on one specific area of use at the detriment of others. On both platforms.
Sure. Continue posting specific examples of what doesn’t work well and suggestions/procedures of how it could be made better. For both platforms.
–Mitch
I agree with your response entirely, Mitch. In particular, it’s (increasingly) important to talk about “Rhino”, regardless of O.S.
Notably, there is no category here to do this. I have long wished for a logical place for a global “Rhino Wishlist” (platform neutral) so one could easily post ideas for improving commands common to all.
McNeel: Any chance a “Rhino for Mac/Win” category at the top level of the forum list (or at least a Rhino Wishlist that shows up in both Mac/Win discussions?) could be created so everyone could discuss global issues?
Heck, might even be neat (therapeutic?) for people to meet their neighbors who live on the other side of the party wall. ~Dave
Ok, here’s my list. It’s not so long after all… I’ll make another list with bugs and wishes in another topic (that one is going to be longer). I’m using Rhino on both platforms (WinRhino since 1997) and I’m going to continue doing so - WinRhino at work and MacRhino (and Bootcamp/WinRhino) in my home office. Here are my findings after trying to use MacRhino (exclusively) on my home computer as I actually already purchased the commercial license.
First of all I have to say that I like the interface where the toolbars and layers/object properties can be hidden and activated simply by touching the screen borders.
The problems:
My biggest concern is that MacRhino is sluggish in every way compared to the windows version on the same MBP (Bootcamp) - all commands have a short delay. This is serious and destroys the whole experience. I also have the feeling that it’s getting worse after modeling for a while (turning on control points can take a second, for instance)… or has this something to do with my computer being too old…?
I have problems with the command option boxes (is that the right term?) often appearing in the ‘wrong spot’ and covering parts of the model. I also have to “look for” them in different places as the pop up here and there… All the information in the same spot would be better. WinRhino’s command line is a good example, but it also could be a floating dialog of course. I’d also like them to be semi-transparent.
The biggest problem, however, is that some of those command option boxes doesn’t accept the space bar as enter - while many does (like in the Windows version). Instead I have to (remember to) press ‘enter’ or the RMB. I think this is killing the work flow and I don’t like it at all! I really would like to have some sort of fix for this!
That’s it. Ill be back with a bug-and-wishes report. Thanks for listening!
Philip
Forgot this…
Software information
Software versions
Rhinoceros version: 5.0 (5A855)
IronPython version: 5.1.2015.131
Language: en (MacOS default)
OS X version: Version 10.10.3 (Build 14D136)
Plug-ins
None
Third party kernel extensions
None
Hardware information
Computer hardware
Hardware model: MacBookPro5,2
Processor: Intel Core2 Duo CPU T9600 @ 2.80GHz
Memory: 4 GB
Architecture: Intel 64 bit
Video hardware
Graphics: NVIDIA GeForce 9600M GT 512 MB
Memory: 512 MB
Screen size: 2560 x 1440, 1920 x 1200
Displays: LED Cinema Display (109dpi 1x), Color LCD (133dpi 1x)
USB devices
Apple Inc.: Built-in iSight
Apple Inc.: Display iSight
Apple Inc.: Display Audio
Apple Inc.: Apple LED Cinema Display
Apple, Inc.: Apple Internal Keyboard / Trackpad
Apple Computer, Inc.: IR Receiver
Logitech: USB Receiver
Apple Inc.: Bluetooth USB Host Controller
Bluetooth devices
Apple: Apple Wireless Keyboard
Apple: Apple Wireless Mouse
Apple: Apple Wireless Trackpad
OpenGL information
OpenGL software
OpenGL version: 2.1 NVIDIA-10.0.31 310.90.10.05b12
Render version: 2.1
Shading language: 1.20
Maximum texture size: 8192 x 8192
Z-buffer depth: 24 bits
Maximum viewport size: 8192 x 8192
Implementation settings
Use texture compression: No
Appearance settings
Antialiasing: 2x
Mip map filtering: None
Anisotropic filtering: None
Quite possibly, especially if it has 4GB.
RAM is cheap. If one intends to keep using a old machine, consider investing in a RAM upgrade. Further, after several years, a complete wipe and reinstall can be beneficial as well. (Manual restoration of data)
When buying a new machine, after determining the base amount of RAM for the intended use, consider doubling that. You will not regret this decision, both while the machine is new, as well as, and especially, towards the end of its life cycle.