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?
From the menu:
@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
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.
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.
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
%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
Yes, that gives me a Raytraced display mode.
Thank you for testing.
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
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.
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
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.
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.
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
Sorry - this is a known problem with this WIP. The next one will fix it.
Ahh - an uninstall-reinstall will solve it.