I am having the same issue with large files, just checked and it takes 55 seconds for Raytraced the first time to start showing any results, but only 12 seconds the next time.
And it is ok to navigate BUT only because the “UseStartResoultion” is toggled ON:
Thank you, Holo.
I had suspected that there was indeed a reason why you became interested in Rhino3D performance. : )
BTW, I had lowered my Rhino OpenGL Antialiasing down to 4x, but Cycles is still using 8x. Hmm.
It’s also using 22 threads. I am guessing that it must be CPU threads, and they had picked the highest that current processors have, THOUGH, it might be inefficient to divide beyond howmanyever CPU cores/threads a user has in their system. Still, that might only take effect for CPU-only Cycles rendering.
Cycles has no anti-aliasing settings. What makes you believe it does?
You might get even better response with UseFastDraw enabled.
The very first time is long because Raytraced is evaluating all textures as well. If you have textures on complex objects, or they are large, you’ll see it takes more time. On subsequent runs Raytraced gets those textures from its own cache, so it is much faster, having to handle ‘only’ geometry. In both cases the actual data uploading (putting it to your GPU) takes time too, and that is more noticable with large amounts of data.
Those threads are used really only when doing CPU rendering with Raytraced. By default it picks two less than the amount of available logical cores, with a minimum of 1.
Those AaSamples are actually only used when doing branched path tracing, which isn’t possible to set at the moment. Fiddling with that setting does nothing for Raytraced.
Thanks, Nathan. I thought it worth a try.
Overall, I didn’t notice any…noticeable improvements in my workflow time, so I set the settings back.
