Hi,
I am having a problem with V6 on my notebook in the Raytrace Mode: It locks Rhino, causing it to become completely unresponsive. It’s happened twice, already, requiring killing via Task Manager.
Um, 6 times, now.
[Lenovo W540, 4800qm, K2100, 24GB Ram, Samsung 850SSD.]
What kind of scene are you working on? Could you share the model with me, and post the resulting text from the Rhino command _SystemInfo?
The model you can share through rhino3d.com/upload with me (nathan@mcneel.com) as recipient.
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.
Thank you for the reply. I will upload them tomorrow, when I am on my laptop, again.
Thank you. As I just edited my first answer: I did fix a crash problem last Friday. I don’t know if it fixes your particular problem, but wanted to let you know.
Looking forward to the model.
/Nathan
Hi Nathan,
Drat! I forgot to compress the file. I am sorry, but it’s uploaded.
Thank you for looking into this for me, as I am loving V6 on the Desktop.
Sorry about my rudimentary file, as well : )
Hi,
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:
Now, not all is lost, there are some things you can do to alleviate the load somewhat:
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…
/Nathan
Thank you Nathan,
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.
That file has a mere pittance of objects. I have done projects with thousands of objects.
http://wtrtechnologies.com/thumbnails.html
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.
I found that option once, and then lost it again, for some reason. It’s hiding.
DpiScale is in the Advanced section
The highlighted settings you can play with. I noticed I forgot to mention transmission, it is also one to lower.
And DpiScale:
Note that the throttle effectively increases the time needed to reach the maximum sample count set, but I guess it is an ok tradeoff if you get more response in the UI.
Will not the DPI scale make my stuff uglier(er).
When I am next at my notebook, I will try the other settings, yet I feel strongly we users need a reliable fix for this.
[The replacement for my “mobile workstation” has a 4k screen.]
Thank you.
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.
I tried the DPI fix; it’s ugly. I think it’s too ugly for the Raytraced to be useful on a notebook.
I just got Rhino 6.2. It will now at least start rendering on a large file whereas 6.1 would not, but when I open the Preferences, Rhino will lock, though I can rotate the view without locking Rhino.
I don’t know why the rendering should continue while a dialog opens.
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.
Hi Brenda, hi Nathan,
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,…
Do you think that would make any sense?
Something like that is on the list for the future, likely v7.
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.
