The display has been rewritten since it is the same display code as what Rhino 6 for Windows is using. One of the driving factors in display development was to be able have all of the code capable of executing at OpenGL 3.3 or above specifically to allow us to use some different features on Mac.
I know a lot of the work in V6, that will show in in V6 for Windows first, was rewritten specifically so the same core code could be used in Mac V6. Writing two independent applications for two different operating system and trying to make them act similarly is impossible.
The only sane solution is two write the core code so it is platform independent and will run on both.
The interface is different but the underlying code will be the same.
thanks @stevebaer that sounds great, just to be sure: that means for version 6 on mac there will be the same code running as the windows version which now has already been written? that means one could already try that out? and if its just scrolling in the viewport, i would be really happy to sign up as a tester to help with some feedback whenever its possible. user performance is a very important aspect, since its what connects us to the software.
another question, which OpenGL features are you referring to for example?
@John_Brock yes so i have heard or read before, as far as i remember there was also some concern if this might impact the windows performance. but generally i think this helps growing those two platform together, this decision is hopefully a gate opener for platform independent plugins.
No one can try out Mac V6 WIP yet, not even in-house testers.
When V6 for Windows is released, then moving Mac development to the V6 code base will begin shifting and V5 will begin winding down. At some point V5 Mac development will stop and the Mac WIP will be available to Mac Rhino owners, just like it is now. The only “sign up” is owning the current shipping version and be willing to take the risks of WIP software.
Platform independent plug-ins are more difficult because there is very little overlap in the development tools over the two platforms. It’s technically possible now but it’s pretty limited.
This is the same situation as V5. There is a huge portion of code shared between the two products and that percentage is increasing in V6. There will always be specialized platform specific code, but we try to minimize that when it makes sense. We are getting closer to making a V6 Mac WIP a reality every day, there are just some features we need to get in place first (as well as get our process in place for delivering WIPs).
It probably isn’t worth getting into nitty-gritty details, but we have switched our display over from a legacy “state machine” OpenGL system to a modern system that uses custom shaders for all drawing operations.
Psst… JB, we actually are building in-house Mac V6 WIPs. They just need a little polish first so we don’t waste your time testing out an application with some obvious features we need to fix first.
This is actually one of the whole reasons we have made such a large effort to support .NET and Eto in V6. Those technologies do allow for cross platform plug-ins. We already see this is possible with a large number of Grasshopper components just working on both Mac and Windows.
I can get it running long enough to check the new licensing tools, but it’s not close to being good enough for a public WIP. That will happen soon enough. The developer frying pan is currently full of sizzling V6 for Windows “fish”…
13 posts were merged into an existing topic: Screen Real Estate
Screen Real Estate
Just wondering if 6 months later V6 for Mac is any closer to being WIP ready.
We are regularly compiling in-house V6 Mac Rhinos but they are nowhere near close enough to release. We are concentrating on fixes and testing for V6 Windows. Since Windows and Mac now share the bulk of their code, the changes are getting in. There are some missing tools in Mac V6 that make it impossible to test both Windows and Mac concurrently so testing is getting a bit backlogged.
Once V6 Windows is released, we will be concentrating on getting the V6 Mac WIP out where users can get at it.
So no specific date yet, but LOTS of development work going on.
Just out of curiosity what is the saturation of use of Rhino on Mac compared to Win it must be worth it if you’re continuing to develop it for Mac, or maybe McNeel is just so weathy they don’t care. I am just curious as a Mac user to know how popular the product has been for Apple fans.
Being hunkered down here in technical support, I don’t have hard numbers.
I can tell you that way more Mac licenses have been sold to students, and many of them have returned them for Windows licenses because of the missing commands and no major plug-ins being available.
We worked very hard to make these limitations known up front but it seems that very few people took the message to heart.
And no, we are not wealthy.
did that happen only during a period of time or is it still happening?
since rhino 6 has been rewritten towards a more platform independent database the developers will sooner or later have to rewrite their plug ins to follow up the SDK is that correct? that would mean that rewriting plugins could hopefully lead to having the developers consider platform independency.
something which bugs me and i would wish that this would become targeted, is that drag and dropping images into the viewport to create a picture frame should work in mac rhino at least in the version 6 then, but also that files which actually can be opened are open when dragged onto the rhino icon. its pretty cumbersome to open rhino then to click “open other” or to click import just to have another window opening and then navigating to the file or for the wise ones at least to drag and drop the file then into the finder pop up.
As with Rhino 5 for Mac, with Rhino 6 for Mac, we only currently plan to support cross-platform .NET plugins authored using RhinoCommon.
At this time, we still do not have plans to provide a C++ SDK with Rhino for Mac.
Many plugins for Rhino are already authored in .NET, but still have Windows-specific dependencies, especially when it comes to UI. We are a bit behind providing documentation and samples the our cross-platform UI toolkit we are using - Eto - and that’s something I want to rectify soon. Still, one would have to rework portions of UI-heavy plugins to work with Eto.
something which bugs me and i would wish that this would become targeted, is that drag and dropping images into the viewport to create a picture frame should work in mac rhino at least in the version 6 then, but also that files which actually can be opened are open when dragged onto the rhino icon
Thanks for bringing this up. Drag-and-drop is a great example of the difficulty of making code cross-platform compatible. Drag-and-drop is functionality that is provided by the underlying operating system in different ways on each platform. The RDK - on which the advanced material/rendering tools are built upon - makes heavy use of drag-and-drop. We are currently working on abstracting the code for drag-and-drop to be platform independent - but still call the underlying platform-specific code to behave predictably on each respective platform. That way, when a developer calls code that relates to drag-and-drop, they don’t have to do one way for Windows; then another way for macOS. We’re trying to dog-food all this stuff before we put it in front of third-party plugin developers, but we still rely heavily on their feedback to make sure we’ve got it right.
No! Details appreciated. Thanks.
nothing i did not read before but to be honest i still have no clue, it took me a long time to understand that Rhino Common can be “our” future our in the context of Mac Windows. but this all depends on how much developers especially those not using or having macs in their environment care about this and also on how much Rhino Common developers will lose out on dropping Windows specific codes.
can you elaborate in short why?
In short? Probably not, but I can try anyway: “Given our resources, it’s really difficult for us to do well.”
There are lots of other reasons, but that’s the most succinct I can muster right now.
just following on from the above, I wondered whether there is a foreseeable timeframe for being able to open Rhino 6 files in Rhino for Mac?
I understand that a Rhino 6 Mac version is probably quite labour intensive, but now the Rhino 6 Windows is officially out, it would be super helpful not having to continuously export Rhino 5 versions of documents to make them cross platform.
I wouldn’t count on the RH5 version to ever be able to read RH6 files. The time involved in making such possible is way better spent to get the first WIP for 6 for Mac out.
My personal wishlist for Rhino 6 mac:
- better and faster display when you open large dwg/dxf files. Sometimes it is so slow you cannot even pan/zoom (brandnew macbook)
- better layout function with predefined paper sizes, Rhino shouls be able to open properly also layouts done in AutoCAD
- hatch transparency
- being able to order block list
- being able to open dynamic blocks and chang values
Personally I think more and more users would like to finish their project in Rhino. Do all the 3d-modeling (where Rhino is really great), and then do the 2d documentation for the workshop and for the planning permissions.
Therefore in my opinion the functionality I was writing above would be extremely useful.