So I have a 2016 MacBook Pro with AMD 555 graphics. The card is selected in the settings. I don
t really understand the settings here yet… It seems that there are two modes… 1-Raytraced in the viewport and 2-Raytraced after you click the render button. 1-completely freezes my MacBook and takes over 5-minutes to orbit a little in the viewfinder. Its just unresponsive and not useable. 2-Its still slow but doesn’t freeze my MacBook.
It doesn’t seem like a hardware issue because the Radeon 555 is ‘okay’. A Vega 64 might quadruple the performance, but I’m not sure if it would be enough to make Raytrace mode useable. Am I missing something in the settings?
Also, I noticed that the render finishes on 100% when all of the black bars are filled in. What settings can be changed to keep it rendering until it reaches a low noise threshold?
I don’t think OpenCL support is fully supported yet but @nathanletwory will know more as he’s the main Raytraced mode / Cycles developer. Can you use CPU instead? My experience has been that mobile GPUs aren’t necessarily faster than laptop CPUs.
Raytraced mode is a different render engine versus running the Render command or clicking Render. When you use Render, you are rendering with Rhino Render and not Cycles which is what Raytraced mode uses. The two are pretty different but will both use the Rhino 6 material library. The big difference is that Raytraced / Cycles calculates indirect illumination which lets light bounce around for more realistic results using less light sources. In looking at your settings, I’d set things back to the defaults…
You find the Radeon card works then too… Calculating 300 reflection bounces between objects is a lot for instance and depending on the scene may be bogging down the card.
To increase the quality produced by the ‘scan line’ Rhino Render, use the Rendering panel to the right. For Raytraced, it’s the time you let it run to achieve more samples.
OpenCL should be supported. Thing is that on the first start of Raytraced the engine needs to compile all kernels and that can take many minutes. I haven’t heard of that process freezing the entire machine though. I don’t know how fast the 555 is, but if it isn’t very fast, then the compile process can take a while - on my Intel GPU (Iris Plus Graphics 650) it takes about 3000 seconds… no idea how long it would take on your Radeon Pro 555. We have a similar machine in our office with a Radeon Pro 560, and Raytraced runs fine on it once the kernels have been fully compiled.
555 and 560 are very similar. Maybe I will take a video of the freeze. But it took me over 10 minutes to ViewCaptureToFile and the whole Macbook froze until I clicked pause a dozen times.Then I tried orbiting the model a bit and it look around 20 seconds for a slight move. But now that I have the two big guns in the room, I have a few more questions…
How often does it need to load the kernels? Whenever I click Raytrace, restart rhino, open a new model…
You wouldn’t recommend a Vega 64 eGPU over like a Radeon Pro 560?
If I do add an eGPU, would you recommend not using that eGPU to drive an external monitor?
Would the Rhino Mac viewport itself benefit from a thunderbolt eGPU even if the monitor isn’t using the GPU? For example, using one port on the MBP for the eGPU and another for the monitor.
Only once, unless I update the source code to the kernels (which will happen in a week). It also will happen if Apple decides to update the driver for the GPU.
So after an update of either Rhino (where Raytraced core engine Cycles is changed) or OSX, when switching to Raytraced seems to take a long time for Raytraced to start let it do its thing. Touch nothing - it should eventually start Raytracing in the viewport.
Once that is done Raytraced will load the compiled kernels from the disk where it saved. If you switched away from Raytraced or killed Rhino before those were written to disk you will again have to wait until the compile process is done.
I have no experience with eGPUs. But the theory goes that it should Just Work. Note that on Mac the CUDA support is still non-existant, since I haven’t been able to work with it (in case you think of trying an Nvidia eGPU).
See previous answer. AFAIK no-one in the McNeel team has played with these… @dan, did I remember that correctly?
Does this happen if you use the CPU as the compute device?
@rajaa@jeff Do you know what system resources are required for the view cap dialog to appear? I’m thinking this delay may be due to the preview image getting generated while computing raytraced with the GPU.
Hi all, slightly anecdotal- I’ve only started playing with r6 wip in the last day or two. I have similar issues with total system freeze in raytraced, or arctic mode. Once on adding a bump map to a texture, a few times when editing the display mode on raytraced. General slow response and screen refresh/movement in those modes also.
I’m running an imac pro with 10.13.4 (17E202), so would not think it’s a hardware capability question.
Running ViewCaptureToXXXX on a Raytraced viewport will most likely take a very long time, depending on what your “Samples” setting is… If it’s greater than what the current viewport has currently Rendered, then the entire rendering will start from the beginning… if ANY of the capture settings are different from what you see in the current viewport, then the entire rendering will start from the beginning… and if “Samples” is something like 500, then it will take about 10 minutes to complete… Raytraced is not truly a “real time” display mode, even though it’s extremely fast, and the results are very nice, it still takes quite a bit of time to complete even a standard sized viewport @ 500 samples…and if you increase the resolution and/or samples, then it’s going to take even longer…
I’m only mentioning this because I want to make sure we’re really talking about a “freeze”, or if perhaps you’re just seeing the long delay required to render all specified samples in the capture dialog. If you set the Samples setting to something like 2, do you still experience this “freeze”?
your viewport resolution is huge - in the viewcapture dialog you can see it is larger than 4100x2600. Doing Raytracing at that size will take a long time, especially on CPU. I’d use a smaller viewport. Or alternatively set the DpiScale to 2, 3 or 4 (Advanced settings in preferences, search for RhinoCycles.DpiScale). This is a setting that affects what you see in the viewport - but viewcaptures will always be done at DpiScale 1. The viewport will look grainier, since the ‘pixels’ rendered will be larger - but doubling the pixel size means a quarter of the work needs to be done.
As @jeff explained the number of passes will affect the workings of the viewcapture. If you pause the viewport at say 100, but you leave the Number Of Passes at 500 a new session will be started behind the scenes and it will render those 500 passes. Same for any different setting.
If you don’t do DpiScale change I’d suggest using the hyphened version of the view capture commands -ViewCaptureToFile and -ViewCaptureToClipboard. Since there is no dialog no unnecessary raytraced session is started for the preview.
There isn’t a progress dialog yet for the Mac, so once you start a capture you’ll see a beach ball. For now you’ll just have to sit tight and wait until the beachballing is over. It is on the list to get implemented though.
The exposure change is probably an illusion due to more pixels becoming non-dark - they get hit/lit.
