From the menu: Render > Current Renderer, only the RhinoRender is available. I noticed this yesterday when I needed to make a pretty picture and today, after updating to the latest WIP, this is still the case.
@nathanletwory, any tips on how to get it back?
@wim, youāre right that it isnāt currently in the menu. The original RhinoCycles.rhp is now a utility plug-in, meaning that at the moment Cycles is available only through the viewport as a mode. It should be available as the mode Raytraced, but I have seen also that it still is under the old name Rendered with Cycles. This is done in preparation for v6, where Cycles wonāt be directly available as a renderer, rather there will be a separate plug-in that enables the old behavior. I intended to make a post about that already two weeks ago, but apparently that intention never got realized. I apologize for that (perhaps I can play here the I-was-working-really-hard card).
There are three main things Iām currently working on. First I work on preventing crashes when resizing viewport (some mechanism changes made this sometimes crash while rendering into viewport). Once that is done I continue with the so-called shadow catcher node, the second major item. This is necessary for the Shadows Only -ground plane. And the third task is to ensure ViewportCaptureTo* works properly for the Raytraced mode.
I will have a plug-in available in the near future to get the semi-modal rendering (into the separate render window) again, but the above list needs my current attention.
Tips for getting RhinoCycles back as renderer (sooner rather than later): make me happy so code typing efficiency gets boosted. Happiness is fostered through the posting of nice renderings done with RhinoCycles/viewport, good cheering while I frantically type code, and virtual puppy eyes that clearly give the message the plug-in is dearly needed.
/Nathan
1 Like
My v6 still says āCycles Renderedā but Iām not sure if this is connected to the inability to delete custom display modes. I think I made one named this when you just had to switch the pipeline to Cycles. In any case, I donāt get one named Raytraced. If I could delete the Cycles Rendered one maybe Raytraced would show up on a new install.
The responsiveness of the Cycles viewport is a limitation for me right now. Mesh wires and isocurves lag behind the shaded meshes which themselves donāt update instantly when manipulating the view. Iād like to have my students use Cycles eventually but there are a few features Iād need for what I teach them and the viewport speed will have to improve before I try replacing Neon and Brazil in my curriculum. Itās getting closer though.
Hereās a render (which yielded a few bugs I need to file now) and a cute puppy for inspiration! Thanks for the continued progress on Rhino Cycles.
1 Like
FWIW, I didnāt have any of these display modes but itās easy enough to make a new one with Cycles as pipeline.
This part of application settings has been wonky for a longer time. There are several issues running for that. If you could test one thing for me: rename settings to settings_ in %APPDATA%\McNeel\Rhinoceros\6.0 and start Rhino. Please tell me if that gives you a Raytraced displaymode. Once done you can remove the new settings folder and rename settings_ back to settings.
/Nathan
Yes, that gives me a Raytraced display mode.
Thank you for testing.
/Nathan
I just tested that and it cleard out the old name for me too, Iāll test it at the office too, as I donāt have cycles there.
But why is Cycles so slow at realtime manipulation? I just made a testfile with a box and the default studio environment, and rotating the view is really slow (dual Xeon, quadro 4000).
Also it crashed Rhino when I closed Rhino if the viewport is still running cycles, repeatably it seems.
Hi Natan, I Got it working on the workstation too, i7 with Geforce 970, but itās very slow here as well and that was a disappointment. Itās unresponsive, seems to be waiting for me to stop rotating the view before it wantās to update.
The Quadro 4000 doesnāt have that many cores, only 256, which isnāt that many for instance compared to GTX 760 with 1152 cores. Also, if youāre running your displays on the same device youāll see some performance hit, as both Rhino and Cycles will be trying to use the device for their work, but even then it should still be usable.
Thereās very likely still room for speed improvements throughout the entire pipeline, there are many places that could be a bottleneck for better performance, but optimization isnāt the biggest focus at the moment. Iām getting close to having everything done whatās needed, once every necessary part is in place Iāll definitely be looking at improving overall performance in the viewport.
Major places I have to look at: each and every transition between managed and unmanaged memory. RhinoCycles is being written in C#, Cycles is in C++, thereās a C#/C layer in between. Iām pretty sure Iād have already much better performance if RhinoCycles where just a āplainā C++ plug-in, but RhinoCycles is also used to improve RhinoCommon realtime render engine integration by both expanding it and putting it to the test 
I understand it can be frustrating that it isnāt super fast yet, and above isnāt meant to make you just accept slow performance. Iāll be working on that, just not necessarily at this very moment.
Iām currently working on this 
threaded code is great for getting headaches 
/Nathan
1 Like
Thanks for the reply Nathan, I fully understand that reliability wins over speed at this moment. Regarding Cuda cores: What surprised me isnāt the Quadro 4000 speed, but that the 970 wasnāt faster. With 1664 vs 256 cores it should in theory be 6.5 x faster. (It is about that much faster when calculating the passes, but not when panning or rotating the view.)
You can test this by opening V6 then make a cube sized 10x10x10, turn on raytraced display mode and run textmaxspeed. At standard 4 view layout (not maximized) on a 1920x1200 monitor it takes 15.91 seconds to redraw 100 frames, thatās 6.2 fps. Iāll check on the quadro to night.
Neat, I didnāt know about TestMaxSpeed. I can definitely say that the slowness is due to how currently the signalling of changes and the handling of those, combined with pausing and unpausing of the render engine works. With this command I think Iāll be able to nicely test this when I get back to it.
I agree that this should be MUCH more fluent, even with complexer scenes.
/Nathan
1 Like
This worked here too Nathan, thanks. If I renamed my old settings folder back to Settings and deleted the newly created one I reverted back to the display mode list without Raytraced though so I skipped that step and just kept the new Settings folder.
Ok, the reverting part was there to ensure the other settings you may have done were retained, but if this floats your boat then by all means 
/Nathan
I thought so but the desired change of having the Raytraced mode was lost if I revertedā¦ I guess I just wanted to let you know in case it shouldnāt have worked like that.
Hi Nathan,
Iāve just updated to the latest WIP build, and now get this error when opening Rhino 6.
If I switch the viewport mode to Raytraced, it crashes Rhino.
David
I get this same error and same crash. No raytraced view mode by default but if I add one with the cycles pipeline I get a crash
Same here
Sorry - this is a known problem with this WIP. The next one will fix it.