OSL shaders: part 2
Errors, problems, snags and other issues
This is a page which I intend to update as a I discover more hurdles in writing OSL shaders. Some of these are Redshift-specific, others to do with OSL in general. If you find a problem when writing a shader in OSL, refer here first in case it's a known issue with (possibly) a workaround.
Here is the list I've got so far.
1. Forget about (most) metadata
Using parameter metadata in a shader sounds so useful, but the Redshift implementation is patchy. The 'label' metadata works fine on parameters but should also work on the shader itself - but it doesn't. Worse, the'help' metadata, which is intended to display a help string to the user about what the parameter is for, doesn't work at all. Although shaders using it will compile, the user will never see the help string. This is really unfortunate and Redshift definitely should fix that.
Some metadata works fine - the 'widget' metadata works, and for float parameters you can use the 'min' and 'max' metadata (good) but the 'sensitivity' metadata, which should control the increment in the parameter value when you click the left and right arrows in the input widget, hasn't been implemented (bad).
2. Meaningful error messages
Or not. Some Redshift messages are quite useful; for simple syntax errors you will get a straightforward indication that there is such an error and where to find it. But for others, the message is pretty useless. What are you supposed to make of this:
%s
Could not compile shader
No indication of what's gone wrong. In other cases you will be told that the shader compiled successfully in the 'Messages' field, but in fact it doesn't work and in the status bar you're told that the shader could not be compiled. This seems to happen especially if you try to use a closure that isn't supported. Sometimes Redshift just crashes.
3. Editing a shader and trying to retest it
This is the worst feature of Redshift's OSL that I have found. You write a shader, probably using a separate text editor since the one in the OSL node is only really fit for two-line shaders. You save it to a file with the .osl extension, then load it into the node, where it fails with an error, or perhaps it doesn't work as you wanted it to. That's fine, happens all the time. What isn't fine is that you fix the shader, save the .osl file, then reload it into the OSL node, whereupon it fails with the same problem which you know you just fixed.
This is incredibly frustrating. There are several possible workarounds you can try, most of which don't work. To save you the heartache, here are the methods which won't fix this problem:
- delete the OSL node and create a new one, then reload the shader file into that
- delete the entire material then recreate it and reload the shader file into an OSL node
- close the C4D scene file and reopen it, then reload the shader
- empty the Redshift caches and delete baked textures
Here are the methods which do work:
- delete the OSL node, save the scene file, shut down Cinema, then restart it and reload the shader
- and the only practical solution: when you fix the shader file in your editor, save it with a different file name - so myShader.osl could become myShader_2.osl, then load the new file into the OSL node
The only sure way to avoid having to restart C4D constantly is the new name method. It would helps if you use a text editor which can save files with incremental file names, if you could find one.
Just as an aside, Cycles 4D (now no longer being developed) avoids this problem as it has a button to click which will recompile a loaded shader, which Redshift could surely also implement.
4. Beware nested comments
Nested comments will cause a compilation error in C++ and they will in OSL, too. What 'nested comments' mean is shown in this screenshot. The outer comment starts on line 19, then ends at line 33. Meanwhile, an inner comment starts at line 27 and ends at line 29.
The compiler takes the first '*/' at line 29 as being the end of the outer comment section, leaving the second '*/' at line 33 high and dry, which will cause a syntax error. It's not a bug or implementation problem, but it is something to watch for.
5. Debugging
Basically, if a shader doesn't work, debugging OSL consists of reading and re-reading your code to try to spot the error. There is no debugger in any OSL implementation as far as I know. Redshift is worse off than most though, because there seems to be no way to output anything to show what the shader is doing. For example, OSL contains functions such as printf(), error() and warning() - all of which are intended to send messages to some kind of console. These functions are not implemented in Redshift OSL, and if you try to use them, your code will not compile. There may be a reason why these functions are not implemented, but it makes shader debugging much harder than it should be.
Part 3: Converting a Renderman shader for use in Redshift-->
Page last updated July 11th 2025