Raytraced mode and Cycles needs

Raytraced mode is becoming better and better, but there are still some kinks that needs to be ironed out for it to be a modern experience.

1- Slow GUI
Selecting a new display mode while raytraced is calculating is a bit of a pain as Rhino often just picks the one underneath the mouse cursor (even if I don’t click the button) when a new cycle is calculated. And the entire selection thing is a slow affair. I use Raytraced in CPU mode since the i7 is much faster than the old geforce 750m, so I guess there should be some better multitasking going on. 8 threads should be plenty for Rhino to both handle background rendering and smooth GUI navigation.

2- Independent viewports.
Having Raytraced on when modelling is too slow as Raytraced tries to update whenever a change is made, but when doing so it hogs the resources and makes modelling really slow. Here Rhino should update Raytraced independently from the other display modes.

(3-) Editing materials should also be independent of the raytraced mode, so we can continue tweaking as fast as we like, and then Raytraced can catch up in its own speed.

Cheers :slight_smile:

2 Likes

You may want to play with the throttle value to give more time between sampling. Also you can change the amount of threads used by the raytracing when using CPU. In advanced options type threads, pick the one for RhinoCycles, and set to something you think may be useful. By default it should say two fewer than the amount of logical cores. For a CPU with 8 logical cores it’d say 6.

The dropdown menu is a bit naughty indeed, it often thinks something is clicked while it isn’t…

For 2) and 3) you should lock the viewport. That will not update the viewport until you unlock it.

Hi Nathan,
my point is that the users should not have to be educated or even have to do anything for it to work smoothly.
If I set perspective view to rendered then I still want to be able to tweak the objects in the other views just as fast as if perspective view was sat to shaded. Rhino updates all four (or more or less) views at the same time, and that is great in almost all scenarios, but I think Raytraced needs to break this rule, or in an other way allow the user to work fast in the other views.

I understand that it can be troublesome when models get complex, especially with lots of reflective and refractive materials, but the Raytraced view is essentially already updated independently from those other views through the ChangeQueue.

How would the independent updating work? Only flush changes every now and then when a scene is really heavy?

One thing that at least should be fixed is the aborting of a sample pass. For heavy scenes it can take a while before the abort is noticed. Once that is happening properly I don’t think we need other mechanisms to have the Raytraced view react better.

I have created a YT item for this: RH-39893

1 Like

Yes that’s my thought, start updating in the background whenever it manages to cancel the current pass.

The Raytraced view already runs in a separate thread, so it comes down to get the mentioned YT item fixed (:

Hi Nathan,
why is Raytraced mode 3 times faster than Cycles render?

Two more things:

1- Cycles doesn’t use the same rules for fitting a camera to the viewport size so if the render size is 1920x1080 and the viewport is 1200x900 then it clips the top of the image to fit the width.

To over come this issue i make a new floating viewport the size of 1920x1080 which duplicates the layout and correctly zooms to fit the height and THEN render that. Now it is 1:1 and Cycles correctly fits the view with out clipping.

2- The Cycles render mode pops up behind the floating view instead of in front.

3- If I set the Raytraced mode iteration value then Cycles Render setting also adjusts to this. That is undesired for me when I work on the laptop as i would like a fast Raytraced mode, but a high quality render output.

4 Box texture mapping doesn’t look the same in OpenGl and Cycles:

Did I mention that I have used Cycles for production this week? And the image above is just simple materials in the default scene with a single rectangular light? It’s super for concept work like this. Great job so fra Nathan!

In this case probably the time for writing out the extra pass data (depth buffer, normal channels, and several others). Does it stay three times longer with higher pass counts, i.e. 1500 samples?

The same rules as what? Are you talking about a production render vs viewport render, both with Cycles?

Does this happen also with other semi-modal dialog, like a undocked panel?

Re 3 - I’ll see about that. It was earlier wanted it’d change the global setting too. Not hard to revert :slight_smile:

Re box mapping - we noticed that here at the office. We’ll be looking at that next week after midsummer holiday.

1 Like

It has to do with how it updates the passes I believe. I have tried it on both machines that uses CUDA and on those it updates the seconds in “chunks” and seem to wait a bit for each pass. Here you can see that 100 samples took 59 seconds to render but only 18 seconds in Raytraced mode. (Both same size and I can not tell the quality apart)

The odd thing is that when the viewport that is rendered (cycles) is large (tested at 1200x1200px) then it pauses for each pass, but if I lower the viewport size to 400x400 then Cycles is almost as fast as Raytraced.

It refreshes the render window in slower passes and pauses between each pass. Don’t know why. It seems to redraw the render view in lines while Rayraced updates the whole view in one go. How does it work for you?

I made a simple render scene, with a dark background and a transparent material so you see the redrawing easier.

Cycles render: 9m 23 sec
Raytraced 4m54sec

(Feel free to do what ever you want with this file) You can test it here:

Wineglass.3dm (372.7 KB)

Oh, by the way, I get worse banding in the shadows in Raytraced than Cycles.
The banding starts showing at 500 passes and becomes ugly at 1000. Here at 1500:

Here compared to Cycles:

Thanks for the investigation. The banding in Raytraced is due to conversion from float to half-float: there is loss of precision going on there. I possibly can skip the conversion, use directly float results, but it isn’t highest on priority list.

Further I’ll be working on the 6.0 issues that are deemed must-does, then I’ll be working on performance, and other good stuff.

1 Like

“Most important first” is a good priority!
I’ll keep posting bugs and needs as I find them. They will be a mix of nice-to-have’s and deal-brakers for production use, so just ask when I’m not clear.

A must-have is for the HDRI multiplier settings to work.
The HDRI is almost turned off if I set it to 0.99, only a tad lighter than if it is at 0.1.

A nice to have is for the “cycles number” to not be stacked with “time” when a view is small. I use extra small views sometimes to find out how many iterations I need for the production image too look good enough.

This is on the list. Going to work on the viewcapture stuff now, then HDRi multiplier.

4 posts were split to a new topic: Raytraced / Cycles lighting questions

imagehttps://aws1.discourse-cdn.com/mcneel/uploads/default/optimized/3X/8/c/8c4ee24f0313c3b67ec0417f6cbbfbdb531a66ab_1_690x173.jpg

Hi @Holo,
how did you set up the lighting on the scene above? Looks nice~