If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.
Exciting News: Chaos acquires EvolveLAB = AI-Powered Design.
To learn more, please visit this page!
New! You can now log in to the forums with your chaos.com account as well as your forum account.
I need another answer/confirmation. If I buy an Apple Mac Studio, works good with Rhinoceros and Vray?
Sorry for my stupid question, I'm not a computer technician, and on that point I don't trust on our technician.
Thank you in advance
The topic was discussed at different places, but please refer to this post which explains the situation quite well.
Since it is at V-Ray 6 beta forum, will paste the text also here to be sure that it will be visible to all users.
The answer is from Nikolay Bakalov, the Lead Developer of V-Ray for Rhino:
Originally posted by jason_vayanosView Post From what I understand, the V-Ray for Rhino and V-Ray for SketchUp are similar applications
yes, but not in terms of host application APIs. They are completely different things. V-Ray for SketchUp and V-Ray for Rhino share all the cide, except the hostapp SDK dependant part
Originally posted by jason_vayanosView Post Would love to hear what Chaos thinks, and if there are plans for support.
V-Ray itself supports Apple Arm chips, which is evident - C4D sketchup, maya, houdini...they all run natively on the M1/M2. Our plans of Rhino on Mac exist since 3-4 years ago. However the problem is the Rhino API. Historically V-Ray for Rhino is written on C++, using the Rhino C++ SDK on Windows. On Mac, however, McNeel do not offer a C++ SDK, but only .NET/Mono one. Hence the language we must use is C#. None of the already existing C++ code could be reused, and both SDKs have absolutely nothing in common. This means we need to rewrite everything on another language and against differnt SDK, that could potentially have fewer features. Then we need to support both implementations.
this is not quite feasible.
We know that McNeel have written their own Mac plugins on C++, hence such SDK exists. We have asked McNeel several times about publishing the SDK one way or another. The answer has always been 'No'
As you can see, if is not that we don't want, quite the opposite, however on these condirions, we don't really have a choice
Comment