The Future of Rhino Render?

recently it has been talked a lot about renderings like cycles or neon, but what i want to know instead is since all this seems a bit confusing,

what is with the good old Rhino Render?

is there anything going to happen still? i mean besides that the Rhino Render is slow and that the options are pretty meager its not a bad renderer, in fact it delivers high quality results if handled with a bit care at least so did i see it and certainly a basis to start from. i am a minimalist trying to get what i need from the least effort and playing around with plugins is just not what i want. so will there anything happen with this part of Rhino at all @jeff @nathanletwory @andy i hope you dont mind if i ask, is there anything which you can/are allowed to share on this matter? i personally would prefer having rather this renderer further developed than any other open source free ware or expensive plugin.

below 2 simple images from 2 different renderers just to show that the render is really not that bad. both images are very simple without any special lights and with the most basic set up ever so dont judge the quality. each render is different of course so i had to screw a bit around in cinema to get it somehow looking the same, i could not understand if its the environmental texture which i had activated in rhino or if its some fresnel implementation which one cant handle. at least in cinema i had to add some fresnel and might have overdone it a bit, anyway its not about which one is better.

if Rhino Render would deliver this image faster with a few more options it would be sure more fun finding an appropriate setup.

Rhino Render ~3 Hours

C4D Physical ~3 Minutes

RhinoRender as a technology is at the end of the line. It will be replaced by a Cycles based renderer in Rhino 7. However, this will only happen once Cycles does everything that RR does - and more.

Having said that, RR has had some improvements in V6:

  1. Fresnel reflection
  2. Reflection polish and transparent clarity settings.
  3. Improved image based lighting.

Don’t worry about “losing” Rhino render. The results you will get out of the next version of it will be better, and much much faster.

1 Like

In the current rhino render, when threads set to AUTO and priority high, the mouse cursor stops working.
Tho the render seems to be on going in the back ground.
So, if I have something like glass material and metal, hitting the render button would not allow me to stop until most of the render in done and when mouse cursor starts to move.
Is this seen? I’ve changed my thread setting to 7 to not use full CPU power, so mouse can be moved.

hi @andy thanks for the feedback. now i have some questions if you dont mind.

the reason why i asked is that i actually like this renderer to some part and what i saw from cycles up to now, did not really convince me. not that the rhino render is a state of the art render of course and i also understand that all this is now under development but and this is where the stronger doubts take place, is that you are replacing an in house technology (at least i believe so) which works pretty robust and could maybe still be further developed, with a third party open source technology.

reading up that cycles runs under Apache License v2, meaning that this engine can be further developed if i understood that correct, but this does not explain why you are dropping the Rhino Render completely…
is it irreversibly dumb coded, or did your team change in that way that nobody wants to work further on it? i am just curious in different matters… i mean you can now write me anything you wish and i have to swallow it… but call me nostalgic i dont really like letting go on something which still bears something usable.

This is all about what we are going to do in a future release of Rhino (not V6). We will replace the render technology when we have something as usable and as robust as the current solution.

yes that was pointed out and was also understandable, it still does not explain why.

Clearly you feel otherwise.
Can you please explain why we should not replace it with something that works better and would be faster?

1 Like

@John_Brock i have no idea how you got to this conclusion.

my writings are differentiated between several matters, having your doubts actually reflected the least. i maybe have myself to blame for it, but anyway to clear up - i am simply curious wanting to know why… as exact and to its farthest extent as publicly possible, for anybody interested enough to read.

I don’t see why the decision to integrate cycles is not a good move. Bringing up the old rhino renderer is just a waste of time. Software development and “good old” somehow contradicts each other.

Cycles is modern, fast, capable for professional work and is open to all hardware (via openCL).
I think it’s a great decision. How this integration should proceed was explained by the Mcneel team a few times already here in the forum.

For me the only problem here is that it can’t go faster :wink:

Wait what? It can’t go faster? You have inside info that Cycles has reached its implementational epitome? That sucks. I suppose I then shouldn’t merge the performance improving patches from upstream then :frowning:


P.S. :wink:


okaaay, I do have noticed that you are always quick with bringing the latest cycles code over to rhino. I’m not a software developer myself (just html&css like roughly everyone else) so I’m not familiar with the right terms (you “merge” the code into rhinoCycles?).

But you know, for the feature- and update-hungry users it’s never fast enough :wink:

Are you talking about 2.79’s denoiser here?

1 Like

No, code for that has already been in - I ‘just’ need to hook it up. The changes I am talking about are these.

1 Like

Cycles isn’t complete. That’s why we’re not shipping it as the production renderer in Rhino. It is good enough to power a raytraced display mode, though.

What this means is that should Cycles development by the original developers end, any other group of people - including our team - can continue to develop the software with full access to the source code. Also, if we decide that the direction the development of the “main” Cycles is taking is not to our taste, we can decide to go our own way.

Note that “Toucan” is the name of the raytracing engine that powers the V4, V5 and V6 RhinoRenderer.

None of those things is the case. In fact, Toucan is an extremely well implemented raytracer designed on the basis of the state-of-the-art 15 years ago. This means:

  1. A shading pipeline based on the traditional non-physlcally correct ON_Material definition.
  2. CPU only design.
  3. Non progressive.
  4. Monolithic shader design (built for local optimization on the CPU)

While it’s possible to add new features to Toucan, it’s getting harder and harder. This is mainly because many of the features that users have wanted over the past few years were never part of its original design. Skylighting, for example, was very much bolted on and is neither fast nor high quality. Glossy reflections are much the same.

We still have all of the original developers - including, of course, Mikko and Jeff. Over the years, many people have had their fingers in there - including me. We all know how to maintain it.

About 4 years ago, I decided that I wanted to focus our in-house rendering efforts on usability. I wanted some particular features from the renderer - and these included:

  1. Immediate feedback on settings changes.
  2. Predictable and easily understood material performance.
  3. Great performance on scenes that use the new defaults (skylit, imperfect reflections etc).

None of these things could be provided by Toucan without a total re-write. Cycles, on the other hand, was clearly going in that direction. And what’s more, we had a Blender developer locally who would clearly be an excellent fit for the project.

We are about half way through the project to re-base all of our rendering tools around the new strategy. In the meantime, we have a hybrid solution that keeps Toucan and the old material definition. For V7 the plan is to abandon all of that and base everything around a physically correct material definition based on the Disney BSDF.

So…that explains the thinking. This is what Cycles will be able to do that Toucan would never have been able to do:

  1. GPU acceleration. We expect Cycles to render at least 10x faster than Toucan on the same system when development is complete. Right now, if you have an nVidia card that has a modern number of Cuda cores, you will already be seeing that. And we also expect GPU acceleration to improve much quicker than CPU speeds.
  2. Modern physically correct shading - meaning that light does pretty much what you’d expect when it hits objects.
  3. Modular shading pipeline - meaning that new components can be developed and pieced together using - say Grasshopper.
  4. Progressive rendering - which means you can see your material and setup changes immediately when you make them - and we can use it to create a working display mode. It also means that noisy effects don’t hang the preview.

Those are the big four. There are are others - the open development model is a really big deal too, and I think it will become more and more important over the next few years.

  • Andy

it seems to have triggered the idea that i had anything serious against implementing cycles. i did not at first, but now after some research i have found some issues which i will edge further down. anyway my initial concerns where mainly focused on an explanation for the complete replacement of Rhino Render hence the title, which you have elaborated very interestingly to read and i thank you for it.

the need for a complete rewrite of the render is what i thought i will hear. after some research i found that people write very basic render engines in the matter of a few hours if they have some experience with it. those are of course not full blown render engines and developing such might take more time, but you say that you decided 4 years ago to change this?

now i understand that it seems to be pretty contemporary not to build up render engines from scratch, but rather to puzzle peaces together. still some probably would invest in such a work if they had a need to integrate it into their own environment, like you guys would and probably could. and since you have a team there who was initially writing the Rhino Render, then why did you not start writing one from scratch right then?

during 4 years something usable would´ve evolved by now. moreover now the people here will be waiting another 5-6 years (not everybody has access to WIP) whenever you will release V7 for a mediocre-2nd hand-open source-freeware-puzzle somewhere just holding up-render which does not properly support caustics without faking them in its current state. instead of having a sturdy and rhino sensitive native render machine including your BSDF which should be easily manageable during 10 years of work i would presume.

now this is your decision and this most likely cant be changed faster than somebody frying his omelette. but if i were in your skin guys i would´ve pleaded for gathering what ever knowledge you have to hit us Rhino Users with some properly home cooked Gault Millau dish, instead of “serving” us some instant big mac which you got from the next door burger inn for free but which Rhino users have to pay for in the end, which might at least fill our bellies but does not digest properly.

i dont want to throw a tone of salt into the soup now to mess it up for some people reading along, i am still curious about the further development and needy for anything usable, but i am really not sure if you guys made the best decisions in this regards. i can see many people are liking where it will be going, i also want to, but i could not bring myself to hit that like button so easy this time.

Priorities. It’s not like the people who wrote the Toucan engine are now sitting around playing Fussball. They work on Rhino6 display and materials and UI and SDK and… and… and…

Basically, we could never do as good a job as the Cycles people are doing, so why invest several years of effort in making a slightly less round wheel? It’s also not just a matter of doing it right once and then moving on to greener pastures. Every line of code you write brings with it a maintenance load. New technology and apis come onto the scene all the time and you’d have to invest more effort again to support them. This is especially true of hardware accelerated computation.

1 Like

Just a question for Render viewport.
Will that be available even after cycles is release a official renderer?

I’m wondering for just setting up textures and moving things around,
raytraced will still be a bit heavy.

And is the improvement as Fresnel, and speed already in the current Rhino Render in Beta?

Yes to all questions.


Regarding the complete replacement of Rhino Render: it has been replaced already many times in the Rhino History.

  • Rhino 1.1, 2.0 had an unnamed scanline renderer
  • Rhino 3.0 used Accurender
  • Rhino 4.0, Rhino 5.0 and the upcoming Rhino 6.0 had and has Toucan

These are all Rhino Render. You see, it is not just about the code behind, it is about the concept. In due time the Cycles render engine will be Rhino Render.

Sure, Cycles doesn’t have proper caustics.
Sure, Cycles is open source.

Does that make it mediocre? Dunno, I’ll let the internet give you the results and let those speak for themselves.

Will Cycles always be without caustics? Not necessarily, but that doesn’t really matter, does it?

As it stands Cycles will be the next step from Rhino Render, and the current state allows a lot of development freedom in the future without having to do a complete rewrite. If we had decided to do a full render engine from the ground up we wouldn’t have had time to do any of the new SDK tools for engine integrations in C++ and .NET (and yes, those new tools are already in use by non-Cycles engines).

As far as I can tell everybody benefits from the work done to prepare a new engine for Rhino Render.