I have published a beta version of the render plug-in that exposes the render engine behind the Raytraced view mode as a production renderer that can be selected as the current renderer.
It is otherwise exactly the same as the Raytraced mode. Currently the previews aren’t rendering properly - that will be fixed in a future Rhino WIP. Ideally this plug-in won’t need many releases alongside Rhino WIP. Only when the Render API changes.
Hi Nathan,
Can you outline what the need/use for the plugin is as opposed to the viewmode?
-Willem
Hi Willem - one thing is you get the render window with adjustments, post effects, saving etc etc. Dunno if all that is hooked up yet for Cycles, I could not get an image when I looked at this quickly yesterday.
@nathanletwory, I tried this again just now in the BOTD
version quartet = 6.0.16307.3531
version number = 6.0 2016-11-2 +1 (8c00608d = 2348834957)
build description = Public Build
and it does not work right, so far. The render window opens but I only get a small rectangle of white or jumbled color in one corner, the rest is ‘background’ checkers…
Or just black. In that case it locked up my machine.
-Pascal
That looks less correct - unless you drew and textured your scene to be like that.
Does ViewCaptureToClipboard with render size different from view port work ok? I would expect ‘no’, since the same modal rendering method is used.
What gpu do you use?
Hi Nathan - this is the dreaded AMD Fire Pro GPU - am I right that in this case Cycles still uses the CPU or is that not the case any more? So far ViewCaptureToClipboard at different sizes does work Raytraced viewport and ViewCapture does not mix very well today, but for regular display modes it works as expected.
-Pascal
Hi Nathan, cool, but I just tired it out on my laptop and when I tried to pause it nothing happened. And when I tried to stop it I got the “Server is busy” error and I have to terminate WIP manually through task manager.
You can try to enable GPU rendering through RhinoCycles_ListDevices and RhinoCycles_SelectDevice (pick the OpenCL GPU one), but for Fire Pro it will give garbled output. I have a machine with such a card as well. My other machine with an R9 works just fine, though.
If you use the hyphen-version of ViewCaptureToClipboard you can sidestep the GUI and the annoying rerenders that happen on changes.
Hmm, do you happen to have an OpenCL device selected? If so then it may take some time to compile the OpenCL kernels. You probably should just wait for it to come back.
/Nathan
Oops, https://github.com/mcneel/RhinoCycles/blob/master/RenderEngines/ModalRenderEngine.cs#L132 (compare to https://github.com/mcneel/RhinoCycles/blob/master/RenderEngines/ViewportRenderEngine.cs#L186 )
The modal rendering engine apparently is naughty and always tried first gpu when autoselection (default) is on. Raytraced viewport mode doesnt.
So for AMD users the busy at the first start is when your GPU driver is compiling the OpenCL kernels. It can take several minutes, even up to 5 or more…
That said, once compiled it should work, render normally. Unless you are a FirePro owner 
The next WIP probably does things better.
/Nathan
If you want to ensure your CPU is used then select device 0 with RhinoCycles_SelectDevice
/Nathan
Yep, if I force the CPU, it works. Thanks.
-Pascal
The next WIP will be using Device.FirstCuda (which falls back to CPU if no CUDA device is available), just like the Raytraced viewport engine does.
/Nathan
Edit: The pause works, it just takes some time to activate. But Stop messes up.
I would like to see the two first passes, not wait for the third.
And millisecond feedback isn’t important but doesn’t hurt as long as it isn’t slowing things down like “prompt” updates in Python does.
Both Pause and Stop on the RenderWindow work fine here AFAICT. If you are rendering something huge or intensive the actions currently really take effect once the current sample has been rendered.
The preview thumbnails turning up grey should be fixed in the next wip:
I found a behavior that leads to a crash or a broken behavior ofter performing these steps:
Reproduced using
(6.0.16306.9301, 11/1/2016)
Beta
SN: 4-1600-0106-100-0000668-30752-30
Result: Either Rhino WIP crashes or at some point the renderer gets into a somewhat stalled, not updating anymore. After this, even starting a new scene and launching “Rendered” mode again helps.
(P.s. I hope this is the right thread to report this)
Thanks for notifying. This is actually something I’m currently tackling in a larger geometry aggregation branch. The branch will also subtly change how materials get assigned (under the hood).
First I’m going to put in new material conversions largely based on the Disney BSDF though.
Do you think that this behavior might impact other render plugins? Right now we do slow material updates with our Iray for Rhino rendering (2.0, also WIP) plugin and after investigating I see very slow material updates when I quickly change colors using our renderer. Right now we cannot tell which parts are causing the slow updates.
I think for Raytraced case it is due to how geometry data is being pushed to the render engine, along with the shaders.
Currently the shaders aren’t handled in the Raytraced layer very efficiently causing unnecessary trouble for the shader manager in the render engine.
I find though that I generally can make quite quick shader changes without slow updates, at least when I am playing with my shader graph tool where I can continuously update colors with speedy viewport reaction by the render engine without (many) crashes.
I did commit some fixes that should go out in the next WIP that hopefully makes things a bit more stable (but still far from ready).
All in all I think that changes to a material should trigger without much lag changes on the ChangeQueue. If you have a large amount of objects that need to be changed because of a material change that could potentially slow processing changes down. I hope that the aggregaton branch I’m working on will show a way to improve that.
/Nathan
FYI this is the speed that I see with Raytraced:
Thank you for the detailed answer Nathan
