On the development of rendering solutions in Rhino

(split of from other topic)

Would you care to elaborate how Cycles (Raytraced) is a waste of time? I strive for a perfect integration, ease of use, outstanding quality. I’d like to know where I go wrong so I can do better.


I’m not sure if you will Nathan, I’ve spend a lot of time explaining to you what needs to be shipped in a product, and what competing products are doing, but you guys don’t seem to get it. Or continue to play dumb. At this pint I don’t even know honestly.

I think what you got so wrong is that you are confusing building a rendering engine with providing a rendering solution to users. Just like in a car, an engine is a very important piece, but it will take you nowhere if you don’t design the entire car. And that car will be bought by no one unless it’s reliable, fun, easy, intuitive and an overall positive experience.

Going with the car metaphor I used an old car model asset I had laying around. And in just under 10 minutes I got from a file with no materials, lighting or any other rendering setup, other than parts split by layers with names that remind me what materials to assign, to this in Keyshot:

This is why it’s so fast to setup a scene:

Look at how fast it gives me result on a 4K monitor:

Only thinks I changes for thsi renderings above is setting up the backdrop to white, and playing with a bunch of environments until I got one that I likes. All very fast and responsive and allowing me to make appearance decision without disruption. I recorded it here:

Now let me show you the Cycles experience to see the contrast…

Started with same file imported into V6’s default template for large objects/millimeters.

The first time I set the viewport to raytraced all I got is a pure white rectangle. nothing ever showed up. I set it back to shaded mode, tries again and it started generating a preview very very slowly. So I needed to go back to shaded mode so my computer is responsive again to go and assign material. But this is what I find in the material tab:

So after going into the + sign in the materials tab journey I came up with this:

…I’m skipping the in-between and take you straight to the 4 minutes result:

You can see one bad material, and a very noisy rendering. Rotating the camera is futile because the viewport doesn’t even update. Here’s what happens:

Minimizing the viewport and restoring it now shows me a rendering of nothing. You can see it here:

You might have noticed that I only applied 1 material in Cycles, instead of the 41 in Keyshot. Well, I don’t see the point of even trying more materials when I have to go hunting blindly into windows, folders, the library continues to be absolutely pathetic and this is what it like to go and try to find one and assign it:

That took 1 min:41 seconds. It even selected a wheel and I was confused because I thought it was highlighted and I was waiting to unselect itself. it never did. I have to click away to unselect it, so maybe it’s more like 1min:20 sec

Undoing a material assignment also takes a long time, which you would have to do a lot in this case since most materials are not suitable. You do the math of how long it would take to assign 41 materials, and how shitty the experience would be. It’s just programmed torture.

Let me show you how it’s like assigning a tire material in Keyshot:

The same limitations of material library and assignment UI exists for choosing and previewing environments, backdrop options, and render quality settings. It’s all really bad, and I don’t think you guys at McNeel even grasp how bad this whole experience is, and probably you never will, given the track record in the 18 years that I have been using Rhino and 23 years using other products too.

So in summary: total waste of time.

And I wasted a beautiful Saturday afternoon just to show you, but unless you see someone in person using all these other products right next to yours, you will never know what you don’t know. I hope this is a start to get you out of a mental model and the current internal expectation at McNeel of what’s an acceptable product. Because this isn’t it.



I might summarize Gusto’s detailed example thesis as follows:

The simpler you can make it to get decent renders fast, without dicking around, the better.

It certainly can, and probable should, have an accessible ‘geek’ mode too based on pedigree, etc., but great value could be added via a Cycles/Rhino ‘idiot’ mode, if you see a way to massage your Cycles implementation towards such. ‘Idiot’ mode leverages significant predefined baselines to ensure a decent render from the get go.

Why? Not just for the obvious newbie. (To get him/her up, running, hooked and wanting more. ) Rather, because pros can and will leverage ‘idiot’ mode too. Why, as Gusto and I proffer? Because we just want to see what we are working on, in decent and accurate photorealism, as quickly as possible during design development, without wasting too much time with esoteric rendering BS.

Later, when we need to make a presentation, or if providing renders for sales materials, yea, we might tweak and dork longer looking for the perfect highlights, etc., etc., until just right…

‘Idiot mode’ is essentially the magic in Keyshot - decent product renderings with ease, and really fast, and super renderings with a some skill and extra effort. As I assume you well know, Luxion has patents. Still, within what Cycles is capable of (which is impressive too), and within your team’s capability, we suggest a focus on rapid usability/acceptable initial quality as the value add. If the geeks don’t like your invisible hand, let em turn it off and geek-out in the basement…

My advice (and easy for me to say since I don’t write the code) is simply study Keyshot and use it as one ‘idiot’ model for your Cycles/Rhino project, in terms massaging Cycles towards as much initial render simplicity as possible, without too much user intervention to get something decent, knowing that a skilled render junkie can get under the hood and dork out to their hearts content, when desired or necessary.

Nathan - don’t let Gusto discourage you too much. He means well (right Gusto?)…more like a metaphorical chastity belt on the adolescent. The project is exciting and has potential if target market usability value can be added/extracted.

And G-Junk, I applaud the effort. Did not have the stamina.

my 2-cents…I could be wrong…





So, Easter’s done.


Thank you for taking the time to write up your thoughts about Cycles. Clearly there is much to be done still (I wouldn’t call it done, either). 4k I haven’t even thought about, as I don’t have such equipment here, but I can certainly ensure that I regularly render with only two CPU threads, which should help me pinpoint problems.

Anyway, one of the goals @andy has set is to make sure that there are as few buttons to push as possible to get good renders out. That means that if we get into a situation where lots of button presses are needed, access to lower level stuff, we have failed. Such situations are to be considered bugs and should be reported. As you have done.

Note though that Keyshot is running separately from Rhino, not in Rhino itself. I’m not here to make many excuses, but I do have to jump through a lot of hoops to get rendering done. That said, we still should be able to get a good experience done. And I’m sure we’ll work on it.

The render looks indeed quite noisy - I think that upstream work might be very useful for this. There is currently an experimental branch with a denoiser that should quite dramatically lower the amount of samples needed for good results. As said that is quite experimental still, but it is not out of the question for it to land eventually in Rhino.

I wholeheartedly agree with the bad experience, and I do hope I get to the point that I am able to work on these tools as well. For now I’m still neck deep in integration, whether you like it or not. I come from a Blender background, and being almost 24/7 at the computer I do understand the need for awesome workflow.

From my PoV this isn’t wasted time. You’re absolutely right that we need user input, and that is also why we have the WIP process. Without it I wouldn’t be able to get the valuable input from you, and many other users.

Anyway, going back to the issues you raised, addressing them as well as I can.


Cycles is currently better on the GPU than on the CPU, but here are some issues that have already been logged to help improve this, also for users with machine that don’t have powerful GPUs. This will drill into quite technical stuff as well, so feel free to skip the explanations if they don’t make you drool with anticipation.

  • RH-38468: have Cycles (initially at least) render at a % of the real viewport size, automatically scaling up. There is already a progressive rendering facility in Cycles, but it could be improved to allow for better control. This control would be automatic, but geeks/advanced users would have eventually better control over that. Rendering at % will have a quite significant speed improvement on low-power, high resolution machines (4k or higher).

  • RH-38467 automatic integrator setting degradation for initial passes. Cutting down on the bounces a ray goes through to color a pixel will speed up the initial passes.

  • RH-34055 ensure the very first pass is also blazingly fast

  • RH-33756 improve environment change reaction. Currently making changes to environments, specifically orientation of the texture in the world is slow.

  • RH-33781 good and fluid fallback when host isn’t fast. Automagically use great OpenGL view while Cycles does its thing in the background. Viewport manipulations, or any scene manipulation for that matter), shouldn’t put Rhino into a state where nothing seems to be happening.

  • RH-30807 performance control. I guess the title says it all. We need to ensure that the results Cycles puts into the viewport are achieved fast, and I’ll be working hard towards getting that done.

There is supposed to be socalled locking, i.e. wireframes don’t update until Raytraced has first pass done. It looks like I might have broken that lately (RH-38962). Obviously this should be still fast, so see the issue on fluid fallback.


It indeed is by default quite hard to see render content. Especially if you use the Import from… dialogs in material editor and environment editor. I have created some YT items to track work on these:

  • RH-38594 ensure import selection dialog shows thumbnails.
  • RH-38595 make Libraries panel better.

Now, the Libraries panel is probably one that should be by default docked in the right-side panels, instead of the Material Editor. But it still needs quite a bit of love to be properly useful.

So, the material editor sucks for setting up a scene quickly with that what you want, and I agree with that. I think that the Libraries panel should be among the default panels instead of the material editor. For that I added a new YT issue:

  • RH-38596 consider making Libraries tab default to show

The libraries panel works better than the material editor or the render settings panel, or environments panel. It shows thumbnails, and drag&drop works


So making the Libraries tab the default place for users to go to would be already a step in the right direction. The Material editor panel, Render Settings panel and Environments panel would be for the (advanced) user who wants to tweak selected render content.

While making screenshots I found bugs and issues:
* RH-38957 only first environment drop works - fixed over the weekend. Shame on me for not testing against latest code.
* RH-38958 drag&drop materials doesn’t always deselect object after material application already fixed.

  • RH-38961 better navigation in Libraries tab

This is what we strife for. Anything falling short of that should be reported as bugs.

No, I don’t know, and I don’t want to know. I’ll leave that for those who think they need to know.

Don’t worry. I’m not discouraged. I’m only glad this is voiced - any frustration worn visibly on the sleeve only makes it easier for me to point to in YT items, discussions, etc. I also applaud the effort. No time wasted there.

I do hope that users (like @gustojunk, but anyone here, really) see that I am very serious about making an awesome integration of Cycles, including improving any tool around that already in Rhino to make the whole rendering experience fantastic. Essentially just a make awesome button for anybody to use.

While working on that I’m also working on ensuring third party developers can also make awesome integration of their render solutions, so that every user can get what they want.

As always, still craploads to do, so I end with a link to all open Cycles issues, currently known. If you find more issues, don’t be afraid of the developer, but tell them. (I have tried telepathy since 1998 when I started teaching Dutch to Finnish people - haven’t succeeded yet).


p.s. one might think I just wasted several hours responding, I don’t think I did.
p.s.II. It was Easter, I spent it with my family, away from keyboard. But I have been thinking about this thread since @gustojunk’s long message (and read it over several times on the phone :wink: )


Hi Nathan,
my main concern with Raytraced mode is that it takes too long to initiate on complex files.
And if I save the file with Raytraced on then it takes extra time to open the file. So could it disable Raytraced in the saved file and set it to Rendered instead?

Here are other important wishes for me:
Exposure control
A slider on the status bar, so when adding 4 new light sources I can adjust the camera and not all the other lights and the environment in the scene.
Light fall off
Rhino ignores lights fall off and that is a pain in the butt when one want’s realistic looking renders where the lights are in the scene and not only on the outside of the scene. Important for architects and other large scale designers.
Set the resolution to 1/2 and 1/4 of pixle density, so it is possible to use Raytraced in maximized view on a 4K machine and/or a laptop.
Fast startup
As stated above.
Previews of materials and environments
Rhino supports some pretty good stuff with in the material

Setting the number of iterations on the status bar is ignored.

And finally, I presume you saw this during the easter, it’s pretty amazing and makes the future look bright for cycles:

I hear you, it indeed can take a long time. Many of the issues on my list have to do with performance increase, including start up. Much of the time currently goes into texture processing, but mesh processing can probably also improved quite a bit.

I don’t know yet, but I created a YouTrack item for this.

Shouldn’t be hard to add, would probably go in viewport specific settings: RH-38985

That you’ll probably have to hash out with @andy. I’d prefer lights with light falloff too, and I’d probably go for having Cycles specific lights that do that, leaving the current render lights as they are. I’ve created a YouTrack item for this.

This I already linked to in my reply to @gustojunk, this is the YouTrack item.

This will always be important, and as said, many of my YouTrack items are related to this.

With the Cycles For Rhino plug-in you already should be able to preview materials with the Cycles engine.

Indeed, naughty me. On it.

I sure did. The denoiser stuff is what I eluded at in my reply to @gustojunk. And I keep updating our fork of Cycles with upstream Cycles changes to ensure we get the latest and greatest available.


1 Like

I don’t think it,s a good idea to have Cycles specific lights. What’s nice about a well-integrated render engine is the use of native components, that can be used in any render engine. The lights could have a Cycles-specific setting though, a checkbox that is shown on their properties panel when Cycles is the active renderer.

1 Like

This may be a good way to show this to a user indeed. I have reworded the YouTrack item. (Add lights with fall-off -> Allow lights to have fall-off).

1 Like

Fixed, will be in next WIP.

1 Like

Hi @nathanletwory , sorry for late reply, I’ve been busy too these days. I’m glad you have found my feedback useful and that you are motivated to influence the culture at McNeel to make a good rendering solution. You seem to have the energy, passion and experience to actually pull it off! There’s a lot of work to do, as you already know. I think your biggest challenge will not be coding, but the internal self-appointed experts that have a very strong point of view on what a built-in rendering solution should be, but you already know that too.

I won’t go into a detail reply, since the bug-tracking just ain’t my thing. but I wanted to p0int out three things you should keep in mind.

The first 2 are about a simple hierarchy that you shoudl always use, it applies to any industry, product or service where the goal is massive success: “Users First, Developers Second, Hardware Last”. This is very close to the core values of McNeel but the practical applications of it, when it comes to rendering, seem to have been overlooked.

  1. If I move my mouse, Rhino should know it, and you (developer) should know that if a progressive rendering is happening and I’m circling around my mouse pointer probably I’m antsy, rushed, bored and most likely at any millisecond (notice I said millisecond, not second, or decade for that matter) I might right-click to start spinning mi viewport or start zooming, etc. At that precise millisecond you shoudl give me realtime navigation back. Depending on the combination of the second class item (developer) and the third class item (hardware) you should be able to give me whatever quality, frame-rate, sampling, viemode, or whatever nerd fact you can, but never, ever, ever, ever you should not let me spin my viewport instantly, and in realtime.

  2. Also based on the same philosophy when I do my work, the computer cannot tell me that I can’t because it’s taking over the entire Rhino session to run a progressive rendering. What does the Developer expect me to do while she/he decided to take over my hardware? Stare? This is totally against the “Users First, Developers Second, Hardware Last”. You both, #2, and #3 act as if you are both more important that me, the user. That’s absolutely nonsense. This is why the Keyshot menu item in Rhino’s UI ‘Keyshot>Render’ or ‘Keyshot>update’ gets it so right, and it’s actually pure genius. It goes off on a different window (its an app, I get it, but don’t get technical on me, humans don’t care), even on a different monitor if you have more than one, and does its things while I still can keep working (modeling, or doing whatever else) on Rhino, instead of staring at your progressive rendering. No user’s client wants to pay for that, and life is too short for a user wanting to also wait for that. So you need to figure out a way to spit out a ‘floating stray window’ that does not block me from keep working while a rendering cooks away. This is of course an option, because there will be times where I want exactly the opposite: any changes I make in the model are continuously updated on the ray trace window (current behavior).

  3. https://www.newegg.com/Product/Product.aspx?Item=N82E16824260238

I’ll leave you with a good article I read recently form one of my favorite designers, it’s very on-topic to what I see happening here:



1 Like

As you’ll see later in this reply, I actually think it is instrumental - it is a form of communication. But that is OK. You’re busy (aren’t we all?), so not all links can be followed (:

Sure, and that is how we work mostly. We also think that it should be possible to have this rendering stuff all implemented in such a way that a user doesn’t have to think much. Obviously we aren’t there yet.

But perhaps you might be able to understand that getting there is an evolutionary process. In a perfect world where Rhino already were perfect, all hardware we started out with were perfect, all operating systems were perfect, all drivers were perfect my initial Proof of Concept implementation for @andy back in 2013 would’ve been also just that - perfect. But none of the parts involved are perfect, so it will be an on-going struggle to get there. The same is true for anything, really. The world isn’t perfect, we all - you, me, anybody else - are working on improving it, be it door knobs or software.

I fully understand, and I can’t repeat it enough: we’re working on it. We believe we can get this to work without even a genius menu like that (ergo eventually out-doing that genius menu). Unfortunately you’ll have to probably either use the Raytraced mode in a smaller viewport, tweak settings for now, or just not use it and every now and then see if I have succeeded any better in the future. This is how I do it with Microsoft Windows Update.

I get super annoyed by the automagic updates Microsoft wants to force on me with Windows 10. That’s why I completely disabled the update service, and will run it at when I am ready for it. Only 12 hours of active time? That’s crap. I have my software running 24/7 and I am not going to be told when I can’t and cannot be active. I’ll turn it on when I find it does the things I want it to do in the way I want it to do. (And yes, I have sent in several items of feedback regarding this matter, read on… :slight_smile: ).

The article by Mr. Cooper is an interesting read, and no doubt there are valid points. But did Mr. Cooper also tell his findings directly to the creators of the software? If not, then writing a ranting blog-post is a futile exercise in wasting energy. Nowhere in his blog-post does he tell he tried hard to communicate the flaw he identified. Ensuring creators can improve their product the design process needs communication. Fortunately we have that here in the form of this Discourse forum. A place where I as a creator can solicit feedback from you the user. Assuming that someone will search for random blog-posts to find feedback about the software they created is just utterly stupid. Lucky me I got linked to it (and lucky for you I took the time to read it :wink: ).

On point three, I think users should investigate and think for themselves as well when acquiring peripherals. No one in their right mind is going to expect a moped to go as fast with four persons (4k screen) crammed on it as with only the one on it (regular Full HD). (I know you said humans don’t care, but they should still be reasonable).

Anyway, thanks again for your write up.

Back to improving the world, bit by bit.



I have been working on better UX with the viewport when using Raytraced. Current result is:

This should give much better responsiveness in the viewport, especially so for less powerful machines and those with large resolution requirements (4k screens). Still not fully finished, but hopefully giving a much nicer feel.


Yes, that looks like a great idea!

yeah that looks lovely, I’ll take if for a spin when it makes it in the WIP build. This week?

It is already in, BUT do wait for the fixed installer. Faulty .cubin files cause Raytraced to crash on Nvidia cards when switching to it. ( See crash topic Rhino WIP (6.0.17122.11501, 17/05/02) crash switching to Raytraced with CUDA, and how to FIX )

Yup, I can verify the crash on my laptop with a 750m card.

Did the fix with the .cubin files from the 7z-file help?

My 2 cents
These days pretty much every single rendering engine is good and has a lot of potential.
Here is a sample render done in cycles from houdini website

1 Like

I tried replacing them but it didn’t help, so I downloaded the latest build from the net and then they were there and it works.

It is still very slow on my 750m laptop, can you test with this file?
One issue is that it changes to rendered mode and that too is slow on this card.

It’s a simple file and you can use it freely as you like. (headhpones are built by me)

HEADPHONES.3dm (703.5 KB)

(If I run Neon in V5 on the same file and turn on Skylight then it is still superfast and smooth.)