just wondering if there is a timeline for the mac rhino release? in an office of 20 there are only 2 of us on windows. 90% of the mac users are interested in rhino, but the limited functionality of the current mac version makes it difficult.
The experience so far is that the product is released when it is deemed ready, not on an arbitrary deadline. Seeing as how the Mac version looks today, I’d say possibly towards the end of next year or in 2015.
Something to keep in mind is that there is only one developer working full time on Rhino for Mac, as far as I know. At least it started out that way for quite a while. The task is one of converting Rhino Windows code to OSX, making changes only where necessary to duplicate functionality.
The Windows version is McNeel supported when running under Bootcamp, and many users, myself included, have had success running under Parallels. So if the issue is simply one of having Apple hardware and not wanting to buy a different machine to run full Rhino, then it is easily done at very low cost. (Well, you will need to buy Rhino for Windows and maybe Parallels instead of running the free Mac development version.)
+1 on the date of “when it’s done and done right” till then it’s free. Use it and participate in the forums for stuff you don’t like!
Andrew.
Please let us know which functionality you are missing most. That helps us prioritize.
Thanks,
- Bob
Hi, for me it is definitely lack of UV mapping for material, and also material definition for layers.
Thanks. I didn’t realize the material by layer was not working yet.
Here’s one, Bob – for The (Amazing) Gumball, enabling the features in “the tail”, such as local geometry transformations, would be delightful (and highly useful). 
As a general note, having “one” error message, instead of “two” for attempted use of missing features would be nice.
You mean the “head” (arrowhead), don’t you?.. Yes, that would be good.
–Mitch
“the tail”, as I heard another user call it, is the dashed white line and the little white circle. See enclosed image.
What’s the arrowhead supposed to be doing that it’s not? (I thought it was simply for moving, which it does do for me).
Nope, in WinRhino, you can click on the “head” and get a little box popping up to input a specific distance. Idem for the rotate arcs and the scale boxes. All of this stuff does not work yet on MacRhino (it’s a Mac-Win display issue, I guess, the on-screen popup box is just not implemented yet). If you try in MacRhino, that’s where you get the “Missing dialog” error boxes popping up - twice…
–Mitch
Right. […twice! 
] Agreed. This also would also be very helpful in the nearer, rather than farther future.
Been thinking on the topic of prioritization since I taught introductory modeling with Rhino (both Mac and Win) for several semesters. The fact that many students could complete their work with the Mac version is testament to the robust development already. However, there are a few niggles…
A possibly useful guide to help prioritize development might look something like this sort of order. Parity with WinRhino in the following order:
- All basic modeling features, with Help in the right column associated with the tool (per WinRhino)
- Transformations
- Rendering/Texturing (The rendering engine is already truly superb, btw!)
- Grasshopper / Python (Which, selfishly, I want asap!)
I’m sure I missed a few major topics that are incidental, and others might object to this order and/or have better suggestions. My rationale is that the “new user” is the most likely adopter of MacRhino in the near future. Seasoned modelers will want more sooner, naturally, but they probably have WinRhino, which they can fall back on for missing features. If they don’t, they probably have another program they can fall back on.
Given the experimental nature of MacRhino, I also see some potential for improving on WinRhino in some areas, and here are a few areas for significant improvement currently:
-
The first is the snaps. While powerful, they are cumbersome (and often maddening) requiring advance decision making and a lot of screen navigation while drawing. An improved system, if it were possible, would be like Maya’s (or if anyone knows the elegant PowerDraw/PowerCADD) where a user could be drawing a geometry and then hold down a desired snap key on the fly.
-
The second area for improvement is with regard to polygons and more robust features. While I am less fussed about this one (since Rhino’s forte is NURBS), it might still be really useful given the proliferation of 3D printing and the number of (crappy) STL files floating around out there that people are wrestling with.
-
Third, Cplane color would ideally relate to World axis colors instead of being Green and Red all the time. Color is a significant visual cue and it’s easy for even seasoned modelers to get disoriented currently when working with their Favorite Blob of the Day. If this can’t be done (even as an option) at a minimum, make the Cplane colors something NOT the same as X and Y colors. New users are baffled for weeks over the current solution, and without divine intervention from someone who understands this nonsense, they often simply shake their head and walk away. I’ve seen it time and time again…
Hi Bob,
- BoxEdit is a feature that would really help new users. To be able to click an object to see/edit its size and coordinates is very useful.
- Layout would be eargerly welcomed. To be able to set up sheets and print to scale is essential.
- The advanced display modes in WinRhino 5 are getting lots of positive reactions. It would be great to have these customisable modes in MacRhino as well.
- Worksessions would help for large projects with multiple users.
Regards,
Andrew
Hi David-
Can you give me an example of this please? Or more than one, if you have the.
-thanks
-Pascal
I am not sure what you mean here…are you saying that the default front and right cplanes should have axis colors that correspond to world space directions? If so, what about custom, arbitrary cplanes, what should happen there? As it is there is one simple rule: each viewport has its own cplane and coordinates , unless the user specifies a W, are understood to be in local Cplane units and orientation. I am not at all convinced, if I understand your comment, that mixing World and local Cplanes will make anything easier for anyone, but I may be misinterpreting…
-Pascal
Having not used ‘proper’ CAD since my university days, I’m really enjoying using Rhino and am really impressed with its capability even in its beta guise. So much so, that it’s got more than enough functionality for me to use it without needing to have any other CAD software. I’ve recently started a company using CNC for rapid prototyping and small production runs. For me, my selfish priority would be having ‘blocks’ fully functional as it would really speed up my workflow, particularly for when I make changes in subcomponents. In my dream world, I’d also like RhinoCAM ready as soon as possible, so I could keep as much as possible in one machine!
You’re going to need to convince Mecsoft that they will sell enough units to make it worthwhile to completely re-write their software to run on Mac… That seems doubtful at the moment… However, as virtually no CAM runs on a Mac right now, they might be able to capitalize on the “pioneer” effect… I would think they would have a lot of success in the EDU market, but frankly not much elsewhere as very few people in industry seriously consider using a Mac.
–Mitch
Hi Pascal,
Several points of clarification are probably needed to better explain my dissatisfaction with Snaps:
1. Cumbersome/Maddening:
When “creating” new geometry (in a freeform design fashion), one does not always know precisely what part of a geometry one would like to snap to in advance. One needs to continually be turning on/off various snaps (which requires a ton of mousing away from the geometry to the menu and back) to pre-visualize what using this snap might look like. It would be great if Rhino “sensed” several important aspects of the geometry one were trying to snap to (such as end, midpoint, center, intersection, and maybe others) suggesting it as a possible snap point while still drawing. I think of Adobe Illustrator a little bit here.
SmartTrack, sort of does this, but its continual display of dashed lines all over the Cplane, no matter where you are is generally so much information that it is useless.
2. Screen Navigation:
Nothing is a greater buzz-kill than lining up the snap that one wants, only to find that it is not enabled. Mouse off drawing to menu, select snap, mouse back to drawing, then recreate the visual result you originally wanted to create, but this time with accuracy.
4. Examples:
Frequently, when I try to move a point (lets say, on a surface) in one of the orthogonal four square views, I find it looked fine in that view, but when I go to perspective view I find the point-move snapped to something controlled by another four square view and is nowhere near where I want it. Because of this complexity, I’ve encountered a number of Rhino users who recommend drawing desired geometry anywhere, then moving it to the location they desire. This seems like a poor workaround. Yes, I realize the solution is possible with some magic combination of snaps and Ortho / Planar settings, but this seems like this could be far, far simpler.
3. Suggested/Desired Behavior:
A) Magnet suggestions might be nice, but should be an on/off toggle
B) Ideally, I would love if each Snap had a hotkey that could be pressed while drawing to activate it. This would prevent the endless “mousing-around” to find the magic combination that works. To me, no other solution is as powerful. However, I realize this might wreak havoc with entering dimensions. Maybe alpha keys could be isolated from numeric keys while drawing?
C) If one is drawing in an orthogonal CPlane, geometry should ALWAYS work ONLY in that CPlane, not in any others.
D) The use of the SHIFT key would be nice to constrain preset angular movement vs free movement.
E) Pet peeve: if OSnap is for Object Snap, why is it not GSnap for Grid Snap? I know of few people who snap to grid on a regular basis, other than beginners, and Snap seems a bit misapplied.
Does that help clarify things any?
Exactly.
Endemic to this discussion are McNeel’s goals for MacRhino. Does McNeel feel (as I do) that beginners will love MacRhino as an initial learning platform that leads to professional super-hero use? Or does McNeel feel that those who already have super-hero capes from WinRhino will be the target market and migrate over? If the former, some interface aspects of WinRhino (which are base on AutoCAD’s…ahem, “superb” interface skills, if I recall) require some thoughtful reconsideration—and this CPlane business is one of them (along with snaps, as I also mentioned above).
I hear your concerns about possibly mixing world and custom Cplane colors, but feel these concerns are worth re-evaluating slightly for one simple reason: anyone able to create a custom Cplane is WELL beyond a beginner user, clearly understanding the difference between a custom plane and a world plane. I, personally, think it would be a nice reminder to know that a custom CPlane is not in the world planes, since I, too, sometimes wonder why things look weird all of a sudden in a custom CPlane view. “Oh right… I did that!” is what finally dawns on me.
Regarding beginners, which I have a lot of experience teaching Rhino, I’ve encountered a number of new users who, once they’ve created a custom Cplane (usually by accident) can not figure out how to get back to the default Cplane. Their solution is to open a new document and paste all their work into it. (Incidentally, I count 26 Cplane tools, and missing from this list—which should be at the top for beginners—is Restore Default CPlanes)
My primary concern is with the Green and Red CPlane colors. Okay, if you don’t like the idea of world colors for the default CPlanes (Red, Green, and Blue) why not just change the world axes colors to something like Magenta, Cyan, and Blue? End of confusion. The fact that two of the world axes colors are IDENTICAL to the CPlane colors, regardless of viewing orientation, makes sense only to those who know what a CPlane is. However, very, very few beginners understand that CPlane is a Rhino convention that is not in any way related to the World planes. I don’t blame them a bit, largely because the CPlane in the perspective and top views align Green with Y and Red with X.
Go to Starbucks sometime and introduce a new user to Rhino to test my observation. Ask them why Z is green / and X is red (which is expected) in the Front view; and then why Y is red / and Z is green in the Right view without you explaining it! 
Rhino does precisely this - just leave the most common ones on - you should seee an on-screen indication of which one is activated when you snap.
Use the “Alt” key to temporarily disable snaps, turn on “Project” to project a snap.
Rhino does precisely this. Shift will toggle ortho while it is held down.
–Mitch