If your lock-ups and hangs occur after moving complex geometry around followed possibly by rotating the viewport, then I have fixed that just last Friday - the upcoming Service Release Candidate (hopefully within a day) will contain the fix.
I have checked your file, and it isn’t in itself a very complicated model. On first glance I think it is due to the extensive use of reflective (and transparent) materials. This has Raytraced loading your GPU with quite a tough payload.
There are several factors that make using Raytraced with this model a not-so-interactive experience:
Your GPU is the primary display device. Running a computationally heavy scene as yours will essentially max out your GPU, leaving little room for other usage, including Rhino, but also access to your desktop
Your device has “only” a bit over 500 compute cores. Your card is great, but for Raytraced not exactly the most powerful
Your laptop has a high resolution display. This means the even a regular viewport, and even more so a maximized one, has a big amount of pixels to raytrace. More is slower.
Now, not all is lost, there are some things you can do to alleviate the load somewhat:
while you still create your model, but you want to use Raytraced already try to use as few reflective materials as possible.
lower the amount of glossy and transmission bounces in the Cycles section of the Options dialog
In advanced section of options dialog look for RhinoCycles.DpiScale, try 2 or 3 (toggle displaymode after changing in case you have a Raytraced vp already) - this will make pixels bigger. Larger values lead to more pixelated viewport results, but it will dramatically decrease the workload.
Play with the settings to see what suits you best. Let me know if any of this helps.
I still need to check your model more in-depth, the amount of objects seem a bit excessive. Maybe we can improve and optimise with that still…
I will try lowering the bounces, but is not the problem that the thing is locked into a loop with too little user polling?
As a user, it will be difficult to have one version of a project for the desktop and another one for the notebook. Respectfully, I would rather have an option for the ratracing to go slower, but not lock up my notebook computer. At least we need a warning, or we need Rhino not to be able to start with a raytraced window active.
The engine was a Honda model, but I did the rest, for a friend in Rhino 3D. I wanted a resume’ project. He moved the project Solidworks because that’s what their fab was comfortable with, yet because Rhino is so interactive, it’s an excellent tool for inventing.
[This is why I wanted changes for a better block manager. ]
You should be able to throttle as well. In the Cycles section of the Options dialog there is a throttle entry. By default it is set to 10, which means that between each sample pass Raytraced sleeps for 10 milliseconds doing nothing. You can increase this number to say 20 to double that sleeping time. This can give you a bit better response in the viewport. Other than that, without creating different versions of your model you probably will have to get used to using a smaller viewport for Raytraced. But I think that a combination of lowered transparency and glossy bounces, somewhat increased throttle value, and the DpiScale set to 2 you’ll hopefully see better response from this type of “heavy” scenes.
Raytraced does support blocks, but that helps mostly with decreasing memory usage - it won’t make the raytracing faster, as there will still be an equal amount of geometry to bounces rays of
I still haven’t looked in-depth into your file, but I think with the suggestions above you’ll see some improvement.
The DpiScale is for the viewport. Once you are happy with what you see in the viewport, and then you do a capture with ViewCaptureToFile or ViewCaptureToClipboard you’ll notice that you will get a rerender of the viewport, but with DpiScale set to 1 to get you the full-resolution version of what you see. It is maybe not ideal, an extra step, but you will see better viewport performance.
To illustrate the point: I am currently working on the Raytraced integration into the Mac version of Rhino, and while the machine is nice it isn’t very powerful - I have to render on three CPU threads (slow) on this high DPI display. To make life bearable I use DpiScale set to a whopping 3. The viewport is quite responsive, I see what I need to see before I fire of a final render with the capture commands.
@Brenda, I recorded a quick session with DpiScale 1 and DpiScale 3 for you to compare. I hope the recording is clear enough - I made it over a VNC connection, so my view of my desktop lags at times a bit, which is probably visible in my mouse movements…
edit: hmm, the compression of the movie makes the results actually look quite crappy. I’ll do a better one tomorrow when I’m in the office at my desk. But it should be clear that at least viewport rotation is much more fluent. Note that the predator head is rather big, it is 986716 triangles, almost a million. So that is close to three million triangles for the heads, and some 100000 triangles for the groundplane.
edit2: TestMaxSpeed with DpiScale=1 gives an FPS of 1.25, with DpiScale=3 it gives FPS 7.09
I tried setting the MS time to 50ms, which seemed to help responsiveness on my notebook with small files, though on large drawings, the raytrace process will not progress. It will just wait in the old “Rendered” preview.
When you try to open a dialog while Raytraced is active, and nothing seems to be happening you can try pressing the Alt-key. Most likely the dialog is “stuck” behind Rhino. We haven’t been able to fix that particular problem.
The rendering continues, the dialog isn’t impeding the rendering that is being done in a non-UI thread.
There have been a number of fixes also in Raytraced code between 6.1 and 6.2. If you used to rotate the view while data was still being “uploaded” to the Cycles engine you probably have seen a crash. This was fixed for 6.2. There have been several changes also that should give a slightly better response on changes.
Reading through this thread made me think of something:
Keyshot has a nice feature called „performance mode“.
It allows to change several render settings with one toggle button.
Convinient switching between responsive and high-quality settings might be useful for cycles users in general… and help in this case.
Basically all the setting mentioned above could be addressed by this command: Ray bounces, dpi factor, device,…
My notebook (W540, K2100, 24GBRam, SSD, 4800qm) is in my opinion is perhaps still in the 70 percentile of notebooks, judging by the two dozen assorted notebook computers I see daily. I feel that Rhino should not lock repeatedly. During one lock, the system became unresponsive.
Can we please have a setting/option to temporarily halt the cycles renderer, when a menu dialog comes up? If that is indeed the issue. BTW, I never saw any evidence of the menu being buried.
UI-wise, I believe that there is a good chance that while the user has the menus open, they may make significant change to negate the current render state, anyway.
Respectfully, which is more useful?
1.) Calling any menu locks Rhino irrecoverably, but the rendering appears to continues for you. You lose your work and sometimes the system hangs.
2.) Rendering halts while a menu is open. You lose a few seconds.