ok guys, i am probably pretty early with this but referring to some functions which will not be added or repaired anymore in Rhino 5 for Mac as publicly seen on several occasions, i am now curious if there is any kind of information whatsoever on when we can expect an early rhino 6 WIP for Mac and when the final product could be released.
i read somewhere that there is not even an internal version for this, but as far as i remember that was a while ago so maybe there is some news on this. also to make a prediction for the final release may be a bit difficult i am aware, but a very rough estimation could be still interesting.
Not anytime soon.
Our focus is releasing Rhino V6 for Windows.
Mac Rhino development is split between working on continued improvements to V5 and getting a V6 Mac Rhino in-house developer build working. It compiles now but is not ready for even basic in-house testing.
I have no realistic estimate when there will be a publically available Mac Rhino WIP based on the V6 code base.
Thanks John, i didnt expect much of an answer of course but still did i have a bit hope to hear something more thrilling. what you are saying almost sounds like its never going to happen, so maybe a half a year to some wip or longer maybe a year?..
another thing which would be interesting to know, have you got any insight on which parts will be rewritten? or is the whole code going to be turned up side down? i am also asking because mac rhino has some certain performance hick ups which never got solved fully and which i was not the only one in pointing out but never really got taken serious, at least so it seemed. for example to name a very important one, the viewport scrolling movement even though it got better over the entire development time still has no chance against the windows version on the same computer.
maybe it never got taken serious because people with machines 5 times faster then mine tested it, i dont know, but fact is that my machine is still powerful despite its age, and the windows version really runs faster on it. i mean the mac version is though not so bad but noticeable slower.
so if this all would get rewritten entirely i honestly would personally be very excited hoping that the known performance from the windows version finally turns this product into the hot wheel it deserves to be.
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”…
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.
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.
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.
