Hi,
Needs serious help. My blood pressure is rising over this issue. I purchased a Mac Studio M1 in the hopes it’ll render/operate faster than my Rhino 6 running in the Apple trashcan. Everything is fine except when I capture to file the render. Rhino freezes. Has any experienced this or has any advice?
Thanks,
Capture to file will essentially rerender, and that is a blocking action - you won’t be able to use Rhino while it is rendering your shot. It’ll take about 4 times longer than what it took for the viewport, depending a bit on the chosen settings for the viewport capture.
Is Rhino 6 even supported on Apple Silicon?
Hi Nathan,
On Rhino 6 I was able to capture to file after raytracing a model. After clicking on capture to file I can assign the size of the image file and resolution and then save it to anywhere in the computer. On Rhino 7 I can do the same on capture to file but the issue is it freezes once I save it to say, the desktop or an assigned folder. Any advice?
Hi diff,
Rhino 6 does not work on M1 chip. I wished it did after this fiasco.
@nathanletwory, I can confirm what @dbr9tifosi describes above.
It doesn’t crash Rhino, but takes quite long to export the image. For a resolution of 800 x 600, it took about 5 minutes. Rhino is all the while non-responsive and stuck at the save dialogue, and the cursor is beach-balling.
You could maybe introduce a progress bar or something, to make it clear that Rhino is re-rendering the view at the desired resolution? Or pop up a window that shows the render progress, like most applications do?
Re-rendering like this in the background and Rhino behaving like any other crashed application is confusing.
@diff-arch, so this incident happens to you too huh. How did you resolve it? I finally come to terms with this glitch so my solution is to create models in v7 and kick it over to v6 to render. It’s the most economical way of getting around this annoyance. It beats buying a new Apply Studio Display and screen capturing the image.
If I were to screen capture my Thunderbolt Display, @300dpi the image is around 5"x"4 (unacceptable). BTW, how many users here screencapture rather than use capture to file? I would like to know.
I didn’t really solve it. I just waited and finally the image got saved, but it takes way too much time and memory in my opinion.
I don’t really use Rhino for rendering, since I don’t like the UV-editor and the renderer has always been slow and broken on macOS. For personal projects, I usually export my stuff to Blender and proceed from there.
We seem to have a very similar setup. I also use a Thunderbolt Display with my Mac Studio.
I do that a lot. It’s way quicker! I can’t remember when I last used ViewCaptureToFile to be honest.
Please keep in mind that Rhino V7 is intended for Intel CPU Macs, not Silicon CPU Macs.
We are all relying on the Apple provided software translation layer called Rosetta. It’s a lot better than nothing, but it’s not great for performance or for OpenGL graphics reliability.
For straight up surface modeling, this compromise setup seems to work fairly well. Rendering is frustratingly slow as you well know.
The fix will be Rhino V8, which when released, will support Mac Silicon processors natively without “Rosetta”, and will use the new “Metal” display language. We expect to finish development and release V8 sometime next year.
We anticipate Rhino performance to be quite good.
Since you own a V7 license, I encourage you to download a try the V8 Work-In-Progress builds. While incomplete, it will perform much better that V7 relying on Rosetta.
For additional discussion on this issue:
@John_Brock, great news to my ear. Rhino 8 will operate natively on the M1 chip. When will the final release of v8 be next year? Spring of 23’ (hopefully)?
I was bummed to discover that v7 uses a middle man (Rosetta) to run the program. That explains how slow it is but still faster than v6 on an apple trashcan.
How stable is the v8 WIP?
All those details and discussion are in the second link.
Cheers
@John_Brock I’m aware of the progress that’s being made with the integration of Metal and it’s appreciated, however the current version of Rhino 8 WIP is irrelevant for what’s being discussed here, because the raytraced view doesn’t even work on macOS yet.
Also the issue is more of a miscommunication or unfavourable UI design, since Rhino gets unresponsive, renders in the background without signalling this to the user in any way, who in turn thinks that the application crashed. The rendering being slow, is only part of the issue.
It’s a work-in-progress or beta version. I wouldn’t recommend it for doing serious work. It’s way too unpredictable. There are weekly updates and often times new bugs seriously cripple something. Also, the raytraced view still isn’t working on macOS.
I think the Serengeti introduction post makes it very clear that it is NOT ready for serious production work, and you’re using it at your own risk.
I would never describe a WIP build at this stage of development as “Beta”. It’s clearly “Alpha” and feature incomplete.
We are making steady progress.
When the WIP cycle is close to ending (many months from now), and we’re close to a “Release Candidate”, then I’d be comfortable calling it “Beta”, but certainly not until then.
That said, there is no good fix for this now other than using an Intel CPU Mac with a decent GPU. That’s why I have 2 of them.
It’s a difficult situation and we are mostly at the mercy of Apple.
Again this has only marginally to do with the issue here. I’m sure you have agency enough over Rhino to do a better job communicating what Rhino is doing at a given moment to the user, than what’s currently happening when CaptureViewToFile is called.
Rhino being unresponsive at a save file dialogue with the cursor beach-balling, and no indication whatsoever that rendering is going on in the background, seems like something that can be improved upon, and not only by making the rendering process faster.
I would respectfully disagree.
The issue here is the relative performance of Rhino V7 running on Silicon processor Macs.
To be accurate here, Rhino is asking macOS to save the file. macOS is controlling the beachball cursor based on some timer that Rhino has no ability to control. Windows does the same thing for the same reasons.
Rendering on Macs is restricted to the CPU. On Silicon Macs, this CPU rendering is running through Rosetta software emulation.
Rendering on Windows computers with nvidia GPUs, lots of CUDA cores, and VRAM is offloaded from the CPU to the GPU’s resources with big performance improvements.
Hi -
Since that’s the core issue of this thread; as I understand it, the recommended workflow is that, if you need an image that is larger than your screen, you should use the Render command. The Raytraced viewport display mode is meant to be a preview.
-wim
No, the issue is communication between Rhino and the user. Lets for instance image that instead of being stuck at a save dialogue and the re-rendering happening obfuscated in the background, you could witness the rendering happen in the Rhino view or a pop-up window, then you’d understand easily that you have to wait until the rendering is done, beach ball or none. There are obviously other ways to get to a similar result, for instance showing some sort of progress bar.
It’s nice that you do your usual shilling for Windows and NVidia, but we’re in the Rhino for Mac category.
Since CaptureViewToFile also re-renders the view at a given resolution, isn’t it exactly the same as using the Render command?
With the Render command, you get the feedback that you are asking for.
-wim
I’m petitioning for getting a similar amount of feedback, when using ViewCaptureToFile with a raytraced view to make Rhino an overall better experience.
fwiw I am working on this in my plugin this week, and it does not make sense to me that raytraced renders a whole image for this – I am just going to quickly copy the pixels currently in my viewport, whatever they may be (after all it’s called view capture to file/clipboard, not render to file/clipboard), and if people want to render, then they can use the Render command.