Are there any plans to bring VisualARC to the mac release of rhino? Since the mac version now supports plug-in’s, this would be a very pleasant addition.
Hi Joost, we are planning to adapt VisualARQ for Mac, but we still need that the Rhino Mac version supports thirdy party plugins that are not written using RhinoCommon. (VisualARQ uses RhinoSDK instead)
When Rhino adds RhinoSDK support in MAC we will determine time and work to adapt VisualARQ to it.
Does Rhino adds RhinoSDK support in MAC
Any update on this. Its beet over 2 years.
I am hanging for VisualARQ to launch on Rhino for Mac
@Seychellian Rhino for MAC still doesn’t support third party plug-ins written in C++, so unfortunately we still don’t know when we will able to develop VisualARQ for MAC.
Seems like McNeel’s development of Rhino for Mac has really taken a back seat to Rhino 6 for Windows. I am hoping that now it’s been rolled out they’ll be moving full steam ahead with the Mac version. The lack of plugin support is a real bummer for those of us on the OSX version. I am guessing that Mac users make up such a small percentage of the Rhino market that the economics don’t really justify the resources they’re having to commit to the exercise. Like I said, it bums me out because i’m full time on a Mac and although I have a Windows computer, moving across to it and trying to work across the 2 devices is a pain. Plus emulation software like Parallels is a pain and doesn’t really work properly. It sounds like its still a few years away before we are using VisualArq on a Macintosh.
That was the plan all along and they have been completely open about that…
Sorry I don’t follow the progress that closely. Do we know if that includes the inclusion of third party plug-ins, specifically those written in C++?
Hey fsalla, perhaps you could enlighten me, are the plugins that are developed for Mac significantly different to those developed for Windows? Is it a relatively easy exercise to just convert your Windows plugin into a Mac one. Im curious to know if, when Rhino 6 for Mac is released with plugin support, developers will be rushing to put a Mac option out there or if the complications of re-writing it to work on the new platform will dissuade them. I have a cynical feeling that the options available on the Mac will remain limited even when Rhino 6 for Mac is out there.
VisualARQ on Rhino Mac? When?
Let me answer you some of your questions from my point of view, as a VisualARQ developer:
As far as I know, developing a plug-in for Rhino for Mac is pretty similar than developing a plug-in for Rhino for Windows.
Here is the problem! Once a plug-in has already been developed for one platform, porting it to a different platform could be very difficult, depending on some the decisions made in the development process, like what programming language, which SDK, or which User Interface library, are going to be used.
Talking about Rhino plug-ins, there are two main SDK available:
- Rhino C++ SDK: which obviously requires to use the C++ programming language, or
- RhinoCommon: which could be used from many different programming languages like C#, Python, VB#, etc, as it is a .NET Framework SDK.
A C++ plug-in, like VisualARQ, needs to be recompiled for Mac, and this process requires many changes in our case:
- Learn how to develop on macOS or find and hire one (or more) experienced macOS developer.
- Convert projects from Visual Studio to XCode.
- Duplicate some parts of code that calls Windows API functions and convert those calls to macOS A
- Rewrite all user interface, as we’re using MFC, a Microsoft C++ wrapper of Windows User Interface API, and make it mac-like.
- Test, fix, test, fix, test, fix…
- Create macOS version of installer, updater, documentation, etc.
I don’t know how much time will this process take, but only the third point on that list will take us more than a year of development.
And this is without taking into account that there is no public C++ SDK of Rhino for Mac, and I don’t when will be available, so we cannot start this development yet. I know that McNeel could provide us with a C++ SDK, but they told us this SDK is not yet frozen, so it could be broken in a 5.x update, which will require the plugin to be recompiled again. This should change when Rhino 6 for Mac is released, as it will share the source code with the Windows version.
At the contrary, a Rhino 5 plug-in developed in RhinoCommon should work in Rhino 5 for Mac (yes, Rhino 5 for Mac does support third-party plug-ins), as long as all libraries used by the plug-in are available in .NET for Mac. Unfortunately, as far as I know, not all standard libraries are available or they don’t work like the Windows version, being the GUI toolkits the more problematic:
- WinForms: a native Windows API in .NET. It does work on Mac, but it has an old Windows look & feel.
- WPF: an alternative .NET GUI from Microsoft, currently not supported on Mac.
- Eto: an open-source cross-platform GUI library developed entirely in .NET by Curtis Wensley (@curtisw). Rhino 5 (for Mac) and Rhino 6 (for Mac and Windows) use this library, and McNeel encourages all plug-in developers that want to write a plug-in that should work on Windows and Mac to use also this library.
I don’t know the exact numbers, but I do think that the Rhino for Mac market share is small compared to Rhino for Windows, and this could influence in the decision on if a plug-in needs to be ported. If Rhino 6 shares licenses between Mac and Windows (which I don’t know), it could be very easy for a Mac user to use Rhino 6 on his Mac, running Windows on Boot Camp or WMware Fusion. I know, it’s not an ideal solution, but it works.
Visualarq for Rhino6?
Wow, talk about a comprehensive response! Thanks a lot for that @enric. I wish I could tell you that I understood it all but some of the technical stuff went over my head. From what you’re saying it sounds like VisaulARQ for Mac is, at a minimum, 3yrs away. In this case I may have to try to use Parallels again although I really don’t like the workflow of being between 2 operating systems (and frankly I really hate being in a Windows environment). I guess the inconvenience is probably worth it to have access to the full gamut of features that Rhino has on its native OS though.
On another note… as a developer of Visual ARQ, can you tell us what the big picture aim of the company is? Does it aim to become a player in the BIM market and compete with the Revits and ArchiCADs of this world? Or is that impossible to do that when you’re not a stand-alone program? It seems to me that it’s marketing itself as a niche option which facilitates architectural users making Rhino an option rather than a complete architectural solution. Should we hold our breath expecting VisualARQ to become Revit in Rhino packaging?
Obviously we do want to dominate the global BIM market!!!
But we’re aware that there are really big players (like Revit or ArchiCAD) that have lots of users and file format of some of them are de-facto standard in some countries. So instead of developing a full alternative, we decided to start developing a complement, so architects can use VisualARQ in the early design stage, and then move to Revit (or any other BIM software) to continue with analysis or documentation. We’ve been adding features on each release, and now, with VisualARQ 2, we think that you can do full project using VisualARQ (plus Rhino and Grasshopper), and you don’t need to move to any other software… at least small-to-medium projects.
So, yes, we do want VisualARQ to became a Revit alternative, but we have to remember that we (Asuni) are a small company and we don’t have the resources that Autodesk or Graphisoft have. But McNeel was also a small company 10 years ago (now it is a little bigger), and Rhino+Grasshopper is now one of the top used applications in architecture.
I’ve been a Revit user for 7 years (no boast, lots of people with more years) and been backing Rhino and visualarq not long after I started with Revit.
Autodesk does a lot wrong; and Asuni & Mcneel is getting a lot right…
If we can do anything to help let us know!
Tutorials maybe? Or some other user-created content that might drive up numbers?
How is the Mac version comming along? Rhino for Mac has made lots of improvements. Is there any chance VisualArq will be available on Mac?
Thank you for the thorough response. At this point (in my opinion) it seems that politics is holding up development -not technology. I emailed McNeel regarding C++ support for Rhino for Mac to support 3rd party plugins like VisualARQ. The response I received is that they are NOT developing C++ for Rhino for Mac but are developing RhinoCommon cross platform support.
If I understand correctly:
McNeel is not developing C++ (Rhino for Mac) support but instead wants 3rd party plugins to use RhinoCommon
VisualARQ is waiting for C++ support so that they can develop a VisualARQ for Rhino for Mac version (which will never happen)
The two companies do not seem to be on the same page.
Why doesn’t VisualARQ just develop the Rhino for Mac version using RhinoCommon (which DOES support C#)?
That’s true. The reason they do not want to make a public C++ SDK is because C++ is not as flexible as C# (.NET) and any change in the API will break C++ plug-in compatibility. And as Rhino for Mac is very new, the code is not yet stable enough to make a it public. RhinoCommon has many advantages, like more flexibility to change the API without breaking plug-ins, cross-platform compatibility between Windows and Mac, easier to learn language, etc.
Yes, VisualARQ is entirely developed in C++, so we must wait for a C++ SDK. McNeel is open to provide us a C++ SDK, but we’ll need to publish a new VisualARQ version on each Rhino release (minor or major) if there is any breaking change. When Rhino for Mac shares the source code with Rhino for Windows (it should happen with Rhino 6 for Mac), then, maybe, McNeel can make a more stable SDK (public or not).
Unfortunately, that is not a viable solution. As far as I know, there is no support for creating custom objects in RhinoCommon, which is a requirement for VisualARQ. Moreover, even if there is support for custom objects in the future, porting more than 1.600.000 lines of code from C++ to C# can take years.