will the Cycles render engine come for the mac version of rhino like in the windows WIP version?
If it will be come - comes it with the RDK in v6 or maybe earlier?
@nathanletwory <- maybe special Question for you
Curious on this as well. I know some sort of export plugin to blender has been in the works but not sure of where it’s at.
Eventually this all should also be ported to Rhino for Mac. Current focus is getting it to work properly on Rhino for Windows, then port the plug-in code to work on Rhino for Mac.
Cycles core code itself already compiles on the Mac (since it works in Blender already), but I haven’t invested time in getting it compiled on the Mac just yet.
The main issue to work on is getting the real-time render engine integration code all the way into the RhinoCommon part working properly on the Mac. Once the RDK is properly ported to Mac we can begin on Cycles for Rhino as well.
Be sure to keep on the look-out for news regarding this
Thanks for the good news.
I think many here and me would try also a “not perfect” - WIP version like the “explicit history” for mac.
I also tested blender for Mac to render some scenes but the usability (I done only a short test) is not my favorite and I really wish an implementation in my Rhino_mac Version
Heh, usability is pretty much a matter of “I am used to X”. It took me quite a while to learn the Rhino way after having used and developed Blender for more than a decade. I still try to select with RMB, getting hugely annoyed that the previous command gets repeated
There’s a lot of “not quite mac” stuff in Rhino. It takes getting used to, as all my 3D work has been mac based. Oddly the auto save under OS X was the first app I’ve used that actually implemented it and it was odd having to hold modifiers to get “save as” to work and whatnot.
On the blender plugin front, I’d be happy to assist in testing. I’ve been beta testing 3D and graphics apps on and off for eons, starting with After Effects 1.0 before Adobe bought it.
Blender is my only renderer for all things Rhino, and my current workflow is to export as OBJ, do clever stuff with object groupings and names to make it easier to assign materials once in blender and various other kludges to make it all work. Got a pair of MacPro’s each running dual GTX970’s to render with. For network rendering I use a shared network volume to dump frames to and the “do not replace” option, which for small scale farming works way better than any sort of traditional client / master / slave / whatever approach.
Hell I’d just be happy to not have to reassign materials once I get stuff into Blender and not have to parent the entire import to a null to fix the 10X scale problem I can’t seem to get around on all OBJ imports.
Good to know there are interested people in getting this done. It isn’t on my todo list for the near future though, but I will tell you when I get to it
same with @lewnWorx, if the
export can be better compatible with obj that’ll be really nice first step.
Any update on this? It would be great to have at least 1 alternative rendering option for Mac rhino.
Also, any update on network / distributed rendering?
The Cycles engine is already functional in the Rhino WIP for Mac version - it is called
Raytraced just like on Windows.
No further useful progress on network/distributed rendering.
How do you access it? Is it by typing the command? (I’m not at my computer at the moment).
Network rendering would be a great help so please don’t forget about it!
No, it is a display mode, just like
Oh, that’s really disappointing.
Why is that disappointing? You can still get renders out on a bigger size than the current viewport with the ViewCaptureToFile command.
Cycles in the viewport works just fine:
OK fair enough. I didn’t think view capture would work. Do you get any feedback on how long the view capture is going to take? Will have to give it a try
There is no time estimate, but there is a progress bar where the command prompt is while the capture is ongoing.
Oh, living in the dark when waiting for an iterating renderer to complete is irony at it’s finest… There is not a single user in the world that will ever find fiddeling with viewcapturetofile with higher than 1x resolution to be an intuitive way to render… it’s a hack… but that’s not my point, so sorry for the sidetrack…
Cycles knows how long the first iteration took, and then how long the first 10 iterations took, so would it not be quite easy to estimate how long the rest will take? Or have you experienced that some iterations takes unpredictably longer to calculate than others?
(((And yes, I am on a still ongoing mission to make cycles a properly supported renderer for both V6 and V6 for Mac. Just shipping Rhino Render Next would be a great jump in the right direction. Rhino 4 Mac deserves that! Even though I know that this is quite the dead horse I will keep on pounding on it since I belive V7 will benefit from that noise)))
It shouldn’t be too hard to hook up the estimation Cycles generates itself.
Anything that eases the pain of staring at a black screen will always be welcome!
But even better would be to lock the perspective view and use that as an imageviewer if that would be faster than using the render pop up GUI view.