Cycles implementation is not good.. (yet)

I was excited when i read that cycles is making its way into rhino - but i think in its current state it is unfortunately not very useful for several reasons:

  1. Response time / interactivity:
    The main purpose of cycles should be an interactive preview.
    In the current state viewport orbiting, object transforms etc. update way to slow, the fallback shading is not working right either.
    This happens with cuda and cpu. Undersampling is not used at all - why?

  2. Defaults:
    Rhino was never famous for its default settings, the initial viewport shading still looks like a bad dream from 2005, and with cycles it is no different.
    It took me 10 clicks in 2-3 different panels just to get a black background, no lights and no ground plane.
    Where do the sampling defaults come from? 1000 image samples etc. - blender has quite different defaults, and they are more reasonable.

  3. Color Mapping
    This is a deal breaker. Without some kind of color or tone-mapping (cycles has filmic now), and no way to render 32bit images, it is pretty much useless in any kind of production scenario.

  4. Materials
    Plaster, Pastic, Gem, Glass,… i like to think that rhino is a professional software and that it can be expected from its users to get accustomed to words like ‘lambert’ or glossy bsdf. Why have a precise language when geometry is concerned, and kindergarten expressions once it leaves the realm of modelling?

Bottom line - in its current state cycles is not more than a nice gimmick that ships with rhino. I was hoping to use it somewhere in my pipeline, and also with students, but it is not ready yet. I don’t know if mcneel plans to improve it during the v6 cycle, but it would be unfortunate to be stuck another couple of years with the rhino renderer which has probably 10 users worldwide ; )

All other serious options are payed plugins, and especially in schools that poses a problem.

  1. This currently depends much on your hardware configuration. Progressive resolution can be enabled if needed. The goal is to have in the future heuristics in place that set RhinoCycles.StartResolution automatically, along with automated toggling of RhinoCycles.UseFastDraw. On a high-DPI screen you can play further with RhinoCycles.DpiScale. Your case sounds like you have an underpowered setup. Care to share your _SystemInfo?

  2. 32 samples in viewport is OK for Blender where the user generally is more a render geek as well, we chose to target the non-render geek. In the future there will be more and advanced control over Cycles.
    Changing to full-black and no GP and skylight off with Rendering panel open takes 5 clicks.
    SelLight click on object properties, uncheck On if you have lights in your scene for an aditional three actions to a grand total of 8.

Doing the same (but removing the default cube) in blender after startup you need to delete the default cube, three to get black background and one more to restrict the default light from render visibility, also 5 actions. Say you have a scene with 10 lights, to toggle their state you have to ensure the outliner is tall enough, click in search box, type lamp, shift+drag on render restriction column (and hope you don’t have regular objects with lamp in the name either).

  1. On the list, although very useful not the highest priority for the initial integration. This is render geek stuff. Slated for v7.

  2. Terminology is for render geeks. Integration in v6 was done with the render non-geek in mind. The future will bring advanced control (and terminology) over the engine and shader setup.

I continue to improve the integration.

The Cycles integration isn’t meant as a replacement for these plug-ins.

I see…
Still i want to stress that color mapping is not ‘render geek stuff’ but a vital feature:
When rendering Geometry from industrial design or mechanical engeneering you can get away without tonemapping, as your objects are mostly viewed and lit from the ‘outside’.
But in most architectural scenarios things are not that simple and some basic form of color mapping is important.

I am not talking about Lut tables, log space or anything like that - just something simple to avoid the white burnt out regions…

Even if its a simple reinhardt mapper - that is basically one line of code + overhead

Tonemapping is that. Currently at most you have the gamma setting to play with. Filmic is on my list to do.

thanks for the infos, one last question: is the version on github up to date? (

That is the repository where I daily work, yes. You can also check the related repositorys and These are the repositories that form the entirety of the RhinoCycles plug-in. The first link is to Cycles code itself, along with all the patches we made to fit it to our purpose, the second link is the wrapper library I created to allow us to use Cycles from the .NET environment. The link you posted is the Rhino plug-in code for the integration.

1 Like

Not certain we have hope for a successful result here.
With its predecessor we could get consistently EXCELLENT results (not PERFECT - “excellent”) in about 30 seconds per frame, with conventional hardware. With RAYTRACED and CYCLES we see 30 - 50 minutes per frame, and NOISE even at the last, but ONLY if you’ve invested upwards of $300 to a thousand bucks for a video card for a “free” included viewport mode that still doesn’t work as intended. MY solution ? I drop back to -5, run my animations THERE if I need better than “RENDERED” mode (zero-point-zero seconds per frame). Otherwise I skip the hype., “hoping” it’ll MAYBE be “solved” some time in the future ?