No, code for that has already been in - I ‘just’ need to hook it up. The changes I am talking about are these.
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:
- A shading pipeline based on the traditional non-physlcally correct ON_Material definition.
- CPU only design.
- Non progressive.
- 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:
- Immediate feedback on settings changes.
- Predictable and easily understood material performance.
- 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:
- 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.
- Modern physically correct shading - meaning that light does pretty much what you’d expect when it hits objects.
- Modular shading pipeline - meaning that new components can be developed and pieced together using - say Grasshopper.
- 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.
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.
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
Sure, Cycles doesn’t have proper caustics.
Sure, Cycles is open source.
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
i really have no idea why you doubt that this would be still my concern. i believe nobody would say anything against that. maybe i should reduce the amount of words i use.
reading some comparison between a few render engines, cycles was not upon the fastest, and by far not upon the best quality either. it basically needs almost the same time as maxwell to deliver an aproppriate result and then it still looks grainy. yes maxwell is also grainy but delievers superb quality in the end and seems to be much faster with the GPU rendering now. grainy pictures is also mostly what i could dig up generally looking for some images about cycles. a really good quality render in high res made in cycles is hard to find and probably takes forever. the denoiser may help in keeping the rendertime low in future, but i am a bit tired of trying to find some information about some decent results.
i dont have doubts that the engine may catch some fire one day, but currently its not what i would wish to have and in the end you will have invested a lot of time in this “new” rhino render having learned nothing for yourself other than copy pasting or did you invest in some own development already? if you had invested this time into your own engine entirely you might have ended up with something even better or as pointed out before more tailored to rhinos needs. but we will never know, because the next time you guys redecide to catch up on some groundbreaking changes it will be many many years from now.
and yes caustics are an important point for realistic glas and water renderings. the noisy interior images you linked me to instead are not a very convincing argument.
Since you are a visual guy, let me put it to you visually:
Or if you are into visual communication (and film quotes):
“If my aunt had wheels she would have been a f*'n bike!”
It’s the past, cycles works and will evolve and they have the will to further develop it within Rhino.
For cycles, as GPU is getting faster and cheaper thanks to the gaming/mining cluster.
I’m sure in the years to come, it’d be the way to go rather than depending on CPU for processing.
I don’t know how the rendering speed goes against other renderers, but comparing the cost to get another render engine solution that may add hundreds of dollar to the cost of Rhino itself may not be suitable for those who have their render engine of their liking.
For denoising, there seems to be lots of tuning that can be done. Maybe not accessible yet in the rhino cycles, but I’m sure @nathanletwory is working on it =) . And as below link is from couple years back, there’s probably better solution for the noises…
just a little remark here:
to my knowledge, mining is the reason why the prices of grafic cards (especially amd radeon RX470,480,570,580) have skyrocketed over the last year.
right, I take it back…
I decided to spend a little time on testing Cycles on glass and liquids and ended up with modelling a simple coffe maker.
Default setup + 3 rectangular lights, one to the left, one to the right and one above. Lights at 27% strength.
I would really like an exposure slider for the view so I could add more lights and adjust the exposure while it renders instead of having to adjust the intensity of all lights and let the renderer start over for each adjustment.
Oh, and have I mentioned that I miss the cycles renderer option ( ) and that I don’t like viewcapturetofile for production? It just doesn’t cut it as a good solution for producing images.
Yeah, I think that viewcapturetofile is quite cumbersome even for advanced users, it’s not intuitive at all. So imaging new users trying to save a render…
I complained about this over here as well.
what I wrote there might have been a bit harsh. I guess since the mcneel team decided to leave the production cycles renderer out of v6 and only bring it to the viewport, @nathanletwory had to find a spot in the ui where he could sneak it in. the big problem here is, that rhino’s ui needs to be redesigned from the ground up.
Does anyone know if it’s possible to grab a screen shot of the Raytraced viewport as is?
At least then you can use the viewport as the render window instead of having to resample everything and also not see the result, I an object selected and the highlight also got rendered…
viewcapturetofile and then use the viewport resolution and an iteration that is equal to or lower than the current one for the viewport.
Thanks @Holo did not know that!
now there we have it: a perfect example of how much the rhino UI fails.
@Toshiaki_Takano is probably an experienced user, but still, that was all but obvious for him. neither it was for me.