ViewCaptureToFile won't render Cycles materials defined with nodes in Grasshopper


I have defined a basic Cycles material using nodes in Grasshopper, and it is showing correctly in the Raytraced viewport.

However, once I launch the ViewCaptureToFile command the material looses the reference to the Grasshopper shader graph and reverts back to the default pink material (see attached picture).

Cycles materials created directly within the Rhino panels work correctly.

I’m using the latest version of Rhino 6 and the same problem happens in the current WIP version.

Interestingly, if I import the geometry into Grasshopper and connect it to a Custom Preview node that references that material, the ViewCaptureToFile command works correctly - which at least is a workaround.

By the way, I tried to mess around with the XML definition of the material to see if the problem was there, however as soon as I change anything in the text field both Rhino 6 and Rhino WIP crash.

Am I missing something?

I’m attaching a simple file that shows the problem.

Thank you!


testGHCycles_01.3dm (138.4 KB) (4.4 KB)

I see this here too. Logged as RH-49499.

Another workaround is waiting for the vp to converge as much as you want, then to use number of passes in the capture dialog that is less than what in the vp already has been achieved. If same size as vp is set then you should get whatever is in the vp.

1 Like

Hi Nathan,

Thank you very much for the very quick reply and for the additional info.

Actually I ran into another related problem:

I need to render the Raytraced viewport from Grasshopper using the Animate function applied to a slider, but the Raytraced viewport does not work (see below image).

The other display modes work just fine, but my original idea was to use Cycles to batch render a Grasshopper animation, without having to bake all the geometry.

The same problem happens in Rhino WIP as well.

I have attached a 3dm/gh pair of files for reference.

Is this the supposed behavior? Is there another way render the Raytraced mode from GH? I guess I should try with a script that manually launch the ViewCaptureToFile command from GH, but wanted to check if there is a ready-to-use solution before I spend time on it.

Thanks again,


GH_Animate_Cycles_Problem.3dm (143.1 KB) (5.4 KB)

I don’t know of a ready-to-use solution, nor have I ever used animated sliders to do stuff.

In the relatively near future Bongo and Grasshopper will play nicely together, where you can set Bongo keyframes on Grasshopper components (sliders, colors, and such).

1 Like

Well, that would be a nice thing to have for sure.

But regarding my post, is that the supposed behavior or is it sort of bug? I mean, shouldn’t the Animate function already included in Grasshopper be able to save the raytraced viewport like it does for the other display modes?

Thanks again,


Raytraced needs time to converge to a solution. I don’t know how the animate function is implemented. If it is using the ViewCapture* commands then it could use the Number Of Passes option to set how many passes are needed. If it does this all programmatically outside of the ViewCapture* commands it needs to be adapted to use the ViewCapture classes that are available.

@DavidRutten can you shed some light on this?

Thank you Nathan, this makes sense, as a matter of fact the Animate dialog in Grasshopper doesn’t include any control for setting up the samples/passes.

It would be nice to have it working, however in the meantime I solved the problem by adding a Python component that launches the -ViewCaptureToFile command and it seems to be working perfectly.

All the best,


YES!!! I have been wishing for this. Thank you. Do you know yet if that also means that we can use Cycles and other render plugins to render out the GH frames like we currently can for bongo animations?

How do you do that?

Do you mind sharing the code if possible?