RhinoCycles not available

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 :slightly_smiling:

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 :slight_smile: threaded code is great for getting headaches :wink:

/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 :slightly_smiling:

/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.

Ahh - an uninstall-reinstall will solve it.

Apparently not for everyone, according to a couple of other threads here… --Mitch

I will have to leave this for @nathanletwory to answer - but as I understand it, all the right files are in the installer, it’s just that the versioning is wrong on the files so some of them are not being properly replaced.

I would imagine that the installer “Repair” option would also work.

The ccycles.dll and raytraced mode crashes should be fixed in newer builds. However, there were also reports about a runtime dll. This is separate from the error I fixed.

My first guess would be to ensure users have the proper C++ runtime installed, but I am not sure what the DLL as mentioned in WIP failes to load and Latest WIP error is part of. At least it isn’t something that is used by RhinoCycles.

edit: quick search on the internet yield http://superuser.com/questions/986496/missing-api-ms-win-crt-runtime-1-1-0-dll

/Nathan

@nathanletwory, i guess i have after brian recommended to update it in this thread. The error which prevented the WIP from opening seems related to the missing dll mentioned in your post above mine. After updating, i can open Rhino but still the same warning as @DavidWood posted comes up. If i choose cycles display mode, rhino crashes.

c.

Reinstall fixed this problem and added the cycles display port option. Looking good!

With the installer that introduced the incomplete Cycles update you will have to reinstall Rhino. Newer builds have this problem fixed. I am expecting a new WIP release today if everything goes as planned. If you get updates through the options dialog you should get whatever is more recent.

If such an update exists and is applied, but the problem persists please notify me.

Thanks,

/Nathan