Instead of using ViewCaptureTo* commands just use Rhino Render itself. It is the same engine for both Raytraced and Rhino Render since Rhino 7.
Raytrace renders at a much higher quality than Rhino’s stand alone render. The difference is night and day. Capture to file is the only way to export the Raytraced render. The other way is to screen capture the Raytrace render but you’ll need a monitor with a 5260 x 2880 resolution (Studio Display). The reason being on a 2560 x 1440 resolution (Thunderbolt Display ,what I have), the screencapture is pixelated. I was hoping to avoid purchasing a Studio Display after just purchased a Mac Studio but the writing is on the wall. A Studio Display purchase is inevitable.
That may have been the case in v6, I don’t properly remember, but as Nathan says (and he codes this part of Rhino), in v7 setting Current Renderer to Rhino Render and using the Render command, will render using the same engine as the Raytraced viewport mode. You can control samples/quality/etc in the Rendering panel.
Hi jd,
I quite a new Rhino user, relative to the members here. So can you elaborate on the “using the Render command”? Normally, I just press my right button when I’m in perspective view and select Raytrace. Is that different than the Rendering Command you are referring to? I check my rendering preference and it’s currently on Rhino Render, not legacy Rhino render.
Sure – first, Rhino has a standard Render command, which you can type in the command line, or invoke by Render > Render in the main menu, or by clicking the Render button (with the blue ball icon) in the Standard toolbar:
When you give the Render command by any of these methods, Rhino will use whatever is set as the Current Renderer, to render the model; it will pop up a window in which the rendering occurs.
When you right-click in the viewport and choose Raytraced (or whatever else), you are just setting that viewport to render with the chosen engine.
I just posted yesterday a problem that I think similar, if not the very same, to this forum: I’ve a Mac Studio Ultra 64 (RAM64 GPU64) and while rendering an animation, after about 2 hrs of work where R7.23 was completing a frame every 18 seconds (using only 50 iterations per frame and all the CPU cores, of course), suddenly my machine mostly freezed, even outside Rhino.
Everything became very sluggish, mouse freezed in “ball” and xy position, and the same mouse cursor was “manageable” only every minute and for some seconds, and not in Rhino.
I waited for some control back… but after some hours of wait I had to force quit Rhino.
And checked for no bad objects in my (easy) scene.
I perfectly understand that now R7 is not using Metal (Rosetta could work even on Metal, like on games such as Shadow of the Tomb Raider), and the activity monitor is clear (not using render, here, but just to see the main processes are “intel”).
What I would ask is:
(1) a way to avoid the complete machine freezing on such a powerful Mac Studio (reduced process priority, at least for one CPU core, so to avoid freezing?).
(2) progress bar / visible output so to understand the process status.
(3) Just a dream… a Metal update on v7 for the render engine (I’ve just purchased the R6 to 7 update, together with my new Studio, and I wouldn’t love another pricey update to make the renderer just work on a 2 years old Apple Silicon…).
1 Like
Hi
#1 & 3 : I, in your situation, will simply [for now] use blender’s Cycle to render [and animate]
Metal is not coming to R7.
#2. +1 visual what’s going on, is certainly lacking.
Akash
1 Like
Hi Gianluca -
Could you provide the necessary steps to reproduce that freezing issue?
-wim
1 Like
I was trying to make an overview video of this simple Nuki adaptor:
Therefore a designed a line for the camera to move, around the object, and a point in the center.
I set the lens to 28mm.
I did set the render quality to good quality, 72dpi (953x883 viewport)
I did set the samples to 50 (+ override production quality)
I tried to choose the 360 background to a Rhino sample (“Studio”), but I didn’t see anything to appear in the viewport (but this might be an error of mine: it’s my first animation). The background remains Gray.
Then I did the SetPathAnimation, with line and point.
I chose 1000 frames, jpg, renderfull, perspective.
And I started the recording. All 20 CPU cores working. 16/20 secs per frame.
Now I’ve started the same process again… let’s see… (this whole sample animation should take apps 4hrs, for 1000 frames)
PS. even the fact that for any single rendered frame Rhino opens up a new window, then calculates the render, save the file, closes the window… wait about 6 seconds to open again a new window, calculates, closes, reopens, etc. It’s not very nice…
Why don’t you keep a working rendering window opened, with a progress bar, instead of all of these open/close/open/close/…?
I suspect the core problem is the middle man/woman Rosetta. Somehow there’s a gap between between exporting a file from v7 to placing it somewhere in the computer (desktop/documents/folders).
I had a similar problem in v6 on my Intel trashcan, where v6 would freeze when I capture to file to the desktop. Technical support said try saving the file destination anywhere but the desktop and it worked. Tried this method on v7 and no go. So the culprit must be Rosetta.
Looking back at first erratic run (and images timestamps), out of the 1000 frame I asked, my Mac Studio arrived to frame 97 at “full speed” (app 3-4 frames per minute), then it passed to 1 frame every 6-7 minutes.
The first 14 “slowed” frames where correctly following my animation path, therefore “only slower” (and with Mac/cursor freezed). Then from frame 112 onwards, all the resulting images changed the viewport, from perspective to front view, but with no animation anymore. In other words the subsequent calculated frames (6 minutes each) were always the same basic frontal view. Up to when I force quitted at frame 130.
In the second run that I’m doing now, not anymore 1000 frames but “only” 200, there’s a similarity: my Mac Studio did the first 97 frames ok, at full speed (appx 3-4 frames per minute), then immediately passed to 1 frame every 5-9 minutes.
The CPU cores are not anymore used at 100%, I’m currently at 10% in average, but the Mac Studio Ultra is almost unusable… while I’m now writing I see what I type 3-10 seconds later.
This is really strange…
The current average CPU cores temperature is 47% (very low), fans are at 1300rpm (slow), power usage is 27W… and still everything is sluggish, almost unusable (still better than the first run, when I couldn’t do anything). Every calculated frame there is a spike in CPU cores for some seconds, then back at 10%.
Now I’m at frame 109 (out of 200) and the images are being completed veeeeeery slowly, but correctly.
Curious to see if the viewport will change again at frame 112… I’ll see in 15 minutes…
UPDATE: frames 112-113 were calculated ok, but… Mac unusable (now writing from ipad). I think I’ll force quit again in short. Trying to issue the ESC command, but is not recognised.
UPDATE 2: After pressing ESC “several times” (Simpson-like) I managed to stop the process at frame 114… Clearly… I’ve to find another solution to render animations…
It sounds like you’re running up against some resource limit in your complicated setup.
You might consider breaking your animation runs into multiple segments limited to 90 frames to be faster, then combine the runs for more frames when you build them into animations.
Well… if I run into resource limits with 20 CPUs, 64GB RAM, 64 GPUs and a 4TB SSD with a 7GB/sec throughput… ahem. And I think a Mac Studio is… “uncomplicated” by definition: there’s nothing you can upgrade from the purchased system :)))
Breaking the animation into multiple 90 frames segments might be a workaround (not that easy), but… probably better to head to a different solution outside Rhino, at the moment… I’ll give a look to Blender.
But… for such an important program like Rhino… I hope McNeel will deliver soon a Silicon-working version with NO or very little cost upgrade (not to spend 300$ after some months from my last purchase…)
The “fix” so Rhino runs natively on these new Silicon Macs, will be an upgrade to Rhino V8, available sometime next year.
Thanks
Thanks John, always kind and prompt to reply.
Only let your developers consider that Apple deprecated OpenGL in 2018 (4 years ago) and released Metal api’s in 2014.
I’m not (anymore) a developer but I think this problem is not a matter of Apple Silicon (anyway 2 years old): it’s a matter of a choice to keep on not using Metal, that was available for Intel and M1 (and performing better than OpenGL).
Rhino could have used Metal since years (8) and would have not had problems in exploiting the M1 GPUs through Rosetta (like Shadow of the Tomb Raider, Metal + Rosetta, running not at maximum possibilities, but quite decently). And the porting from Intel/Metal to Apple/Metal would have been probably far easier in 2020.
Having said that, the situation is clear: Metal + Silicon in V8.
But please do not reverse a McNeel (understandable) “wait strategy” in developing for Metal (2014) to your trusty MacOS users base wallets.
Suggested solution: zero or symbolic-cost V8 upgrade for Apple Silicon V7 users (especially for who purchased in 2022).
1 Like
that’s silly. support the amazing developers. buy the new version. It’s a fixed one-time fee for version upgrades. If THAT is such a huge cost but one can afford an m1 mac what does that say about the person?
OP bought a mac studio for crying out loud.
1 Like
Not going to happen, so don’t hold your breath. A Rhino license is a Rhino license and upgrades cover all versions from V1 forward for the same price and no matter what the platform or hardware the user is running.
2 Likes
Silly? About the person?! mmmm… a bit of an uneducated and harsh comment, Tushar?
It’s not a “mere matter of cost”, as otherwise I wouldn’t own a Studio Ultra 64. And I love supporting amazing devs, and I purchased version 5, 6 and just upgraded to 7 (as soon as I moved to a Silicon device).
It’s a matter of principle, here. Of equal opportunities across the Rhino professional user base.
There’s a significant MacOS McNeel install base, out there: Metal is 8 years old, Apple Silicon 2 years old. OpenGL deprecated since 2018.
Apple owns a large market share within our pro’s base (even not considering the same chip architecture within iPad tablets). Recent IDC figures show an Apple Mac supply growth of 40.2%, within a global PC market declining -15% (Lenovo a -16.1% decline, Dell at -21.2%). Over 10M Macs sold in Q3-22, amid a damn war and global recession (mostly everything Apple Silicon now).
This means that Rhino potential market is significant.
And given this “significance” I believe a Silicon compatibility in V7, released two months after the Silicon release, would have been a sign of care for a growing base. Even a late 2023 “V7.9”. Even without updating to v8 (that - ok - would offer new features, “to be paid for”).
Current bottom line is that current Silicon users are not working on a peer plane.
Peace 