How will Rhino Mac evolve alongside Rhino 6 Win?

Rhino Rhino for Mac
1

With Rhino 6 in beta right now, what is the longview roadmap for how Rhino Mac will stay abreast with dare I say the greater functionality of Rhino for Windows? Or put another way, how will Rhino Mac not be the weaker sibling in five years? I only ask these questions out of enthusiasm for Rhino Mac, as I use both platforms, but ultimately prefer working in OSX for various reasons. I also admit that I’m out of the McNeel development loop, and if Rhino 6 for Mac is also in development, then that answers most of my questions.

Thanks forum.

1 Like
2

to throw in a first little chowed and nagged off bone to the discussion, from what i know is that there is at least an intention or lets say an idea to bring out mac and windows at the same time with the upcoming version. i think a lot of the “new” development is being recoded to make progress more adaptable for instance windows grasshopper is being rewritten completely if i recall that correct which is (also) targeting a platform independent plugin support. so the future may look pretty similar i suppose but everything i say now is also a little interpolated.

from those many years which i more or less peripherally followed rhino for mac i am still left with the impression that its being a one man show only… i have seen many ups and downs and in some regards some functions are now better than before others still left blank for ages while the most important ones are not performing 100%… even though it got also much faster but its still not there…

i am also afraid that the performance will not be targeted seriously enough in future since i believe better computers compensate too easy for the performance issues i for example have with a 7 year old mac book pro. but on the other side performance on an older computer can also quickly show where too much processor or GC power is being wasted, a howling cooler just because i drag and drop files around or copy a few flat lines through the screen is just now what i expect, something which worked better in windows many years ago on even older computers…

so comparing mac and windows on the same computer, mac is still rather a toy than a professional tool…
even though you can work it its no match to the windows version. sorry to say, i know that may be some harsh critic and comparing it with autocad for mac which is a full blown disaster on a not 200% new computer puts it into a far better light again, but waiting so many years and seeing the gaps i can only hope that this will catch up soon since i do like this tool very much because of its potential to become a real mac must have.

1 Like
3

I should think that Mac and Windows will continue to have slightly different user interface guidelines.

1 Like
4

Hi @jarombra-

Well, great question! I’d love to know how it will evolve, but all I can help (hopefully) with is how we currently intend for it to evolve? :wink: Ok, before I rattle on and write a miniature novel…

TL;DR: As of Rhino 6, Rhino for Windows and Rhino for Mac share the same codebase. Development is happening at different rates on each product, but they will have much more feature parity than they do now. Rhino 6 for Windows will ship before Rhino 6 for Mac.

A little background is necessary here (I’ll leave out some details and simplify a little bit)…

Rhino for Windows and Rhino for Mac share a TON of code. A lot of this code is in the “core” - the geometry engine that drives Rhino. This is the exact same code. Bugs in one will be bugs in the other.

At one point during Rhino 5 for Windows’ development, the code for all of Rhino was “branched” and separated into a different project. Changes that could be merged from Rhino 5 for Windows were merged into Rhino 5 for Mac (our initial release)…but they were two separate “code-bases” (or projects). If the Rhino for Windows code was not building, that didn’t impact the Rhino for Mac builds (and vice versa). This meant that developers of Rhino 5 for Windows did not have to care if the code that they committed would work on Mac. By the same token, development of Rhino for Mac would not slow down Rhino 5 for Window’s development. So, even though Rhino 5 for Windows and Rhino 5 for Mac share a LOT of code, they were/are still independent (at the code level).

Ok, now let’s talk Rhino 6…

We knew this separation of the project code was unsustainable. So, late in 2014 - simply because the timing was “right” - we merged the Rhino 5 for Mac codebase back into the Rhino 6 (for Windows) codebase…effectively unifying them for Rhino 6 (for both Mac and Windows). OH, and we did one other really important thing: we created a process by which, whenever a McNeel developer checks in a change to Rhino, it has to build on BOTH platforms: Windows and Mac. If that test fails, the developer has to correct their work so that the builds will not break. What does this mean? Lots of things: developers have to pay attention to the impacts of their code cross-platform and find solutions that work on both while they make even the smallest of changes (and there is absolutely no doubt in my mind that this is slowing down the development of Rhino 6 for Windows). This also means that even more of the code will be the same. Notice that I said: “it has to build on BOTH platforms” …that doesn’t actually mean it has to “work as intended” on both platforms…that’s a whole 'nuther story (for later). In sum: we are taking huge steps toward writing cross-platform code and “unifying” the products at the most basic level: source code.

At an organizational level, learning to develop cross-platform does not happen overnight. It’s really tough. Some of this is technical, but a lot of this is not. People are comfortable with the platform and the tools they know. Sometimes going over to macOS - for a seasoned Windows user - and doing the simplest of tasks is a real chore. The same happens for macOS developers.

I doubt it, but this likely depends on which plugins you depend on and which third-party developers decide to develop and release for Rhino for Mac. I think there will be people who will say in the future: “Rhino for Mac is a toy because it lacks [insert really obscure niche plugin here].” But it could also cut the other way: “Rhino for Windows doesn’t have [insert really obscure macOS-specific feature used by 10% of people here].” I kinda think this distinctions are rather silly. We want to create an awesome product and development platform in Rhino. Much still needs to be done to get plugins working on both platforms…but this is something that we necessarily need to do with cooperation of third-party developers.

I’m glad you are. Let me know if any of the above doesn’t make sense.

Best,
-Dan

8 Likes
5

Very interesting read Dan, and thanks for taking the time to spell it all out. I imagine much of the simultaneous platform building is a benefit of using Xamarin Studio eh?

Despite my enthusiasm for Rhino’s cross-platform future, I am increasingly worried these days that Apple itself will throw smaller-sized developers like McNeel a curveball by stymying their high-end computer product lines and subsequently abandoning their high-end users. For example, at this very moment, I am more than ready to upgrade to a new modeling system, and I would much prefer a powerful new Mac desktop, but the only available Mac Pro uses at least three-year-old hardware and is twice as much as a PC anyone could build with arguably twice as much power than the MP. Double twice! Without digressing into a bitter aside about Apple’s increasingly veblen (in distinction to utilitarian) lineup of products, I wonder if in the next five years or so if CAD/VFX/GFX software developers will have so few actually-professional Mac users that they will not be able to afford cross-platform development. At such a point, Apple will cross an irreversible threshold and be forever just the Audi of computers; great cars to drive around town in, but god forbid if you need to haul anything.

Doom and gloom in abeyance, as long as my MacBook Pro keeps chugging, I will still support McNeel’s cross-platform development, as with The Foundry and other smaller but excellent development groups.

6

No problem. Happy to do it.

Yes, certainly having better cross-platform development tools is a big part of this working! It’s really cool the direction Microsoft + Xamarin are going right now… .NET is getting stronger and stronger.

However, there are many developers who are not .NET developers - both within McNeel and within our development community. Either we need to provide a C/C++ SDK in Rhino for Mac - which is a MAJOR undertaking - or those developers will need to port or wrap their plugins using C#. Again, no small task…depending on the plugin.

Well, I really hope this doesn’t happen.

I too am waiting on the new MacBook Pro…as are many people, so I hear.

Best,
-Dan

1 Like
7

If they share the same code… Why? :slight_smile:

8

While the underlying Rhino program code might be the same (geometric kernel, how commands function, etc.), the user interface and Mac operating environment are completely different from Windows. Thus there are whole layers of code in Mac Rhino that need to be written and tested separately from Rhino for Windows.

Rhino 6 for Windows will come out first because it’s nearly ready and people don’t want to wait until the Mac version “catches up”. I imagine as time goes on, that the time between the releases of the Windows version of Rhino and the corresponding Mac version will diminish until it disappears entirely, don’t know when that might happen though.

–Mitch

9

Right, I see, but… isn’t this a bad move if the target is to create a cross-platform modeler?
I mean, from a marketing/third developers point of view, the Mac version will always be seen as a secondary platform if the Windows version comes out first.

Isn’t it better if the Windows version stays in public beta until the Mac version development “catches up” and a cross platform version 6 release could be done?

10

Nope, the Windows version has been in “public beta” for more than 4 years now (or is it 5?)… that’s far too long already…