View Full Version : RFM, RSL: Good GUI for shaders

01 January 2012, 02:24 PM
In RenderMan for Maya, when you open a shader file in corresponding RenderMan node, there's an ugly list of shader variables in Attribute Editor.

Is there a way to:
Give a nice names for variables (label them) so that they display in more human-readable manner? For example, "Diffuse Intensity" instead of ugly "Kd" or "diff_int".
Group parameters like it's usually done in Attribute editor? Plain list of all the attributes is simply impossible to navigate if you have a complex shader. It would be better if all the attributes that relate to diffuse color go to "Diffuse" group (with "Diffuse texture" subgroup if needed), reflection attributes go to "Reflection" group etc.
Edit slider limits for float variables? By default, all the sliders represent amount from 0 to 100 which is usually far from what we want ([0-1] range).
Use other widgets for our variables? Like dropdowns or simple on/off checkboxes for floats, or "filepath" fields (which has an interface button to simply navigate a file) for strings.
Hide some parameters or give them another default value depending on the value of some another parameter? For example, we have float parameter "useTexture". If it's value is "true" (anything but 0), than some additional parameters are displayed (like "textureFile", "scaleU", "scaleV"). If it's 0, then none of these is displayed.

01 January 2012, 04:34 AM
the renderman shader node is horrible. What i do (im sure there are easier ways)

-Write a new shader node in the maya python api
- write a rsl conversion for it, eg the same way renderman studio converts maya's lamberts

Then, it's just like a normal maya shader. It integrates into the hypershader, you can write a nice AE for it, even whip up a decent open gl preview.

It's just time consuming, if i still used renderman studio, i would write a python script to automate all this.

01 January 2012, 11:28 AM
Thank you for making it clear. It's good to at least know the reason why I can't get what I want from shader.

Looks like I have to accept this horrible GUI as kind of limitation of RFM.
Using maya nodes is good idea but it doesn't allow to export custom AOVs. And these AOVs is the only reason why I'm writing my own shader instead of using maya shader which rendermen understands and converts perfectly.

01 January 2012, 06:02 PM
If you are directly writing .sl shaders then you can create a .slim template ( for the shader which contains all the gui description.

Simplest way to do this would be use Malcolm Kesson's excellent "Cutter (" tool. It automatically generates a slim template file ( when you compile your shader. The template file contains all the necessary labels, declarations and description blocks. You can go ahead and edit that template file to suit your requirements.

One can also use certain specific keywords besides the parameters in a sl file within Cutter to generate the custom slim template automatically. This is described in the section called Cutter and UI hints in the chapter above.


01 January 2012, 09:09 PM
That's great news!
Thanks a lot.

01 January 2012, 10:37 AM
You can also write the .slim templates by hand. I typically cut and paste from previous templates in order to create new ones.

As an example, say you had a shader called "" which had four variables called 'mychannel', 'mycolour', 'doSomething' and 'myvalue' you'd create a plain text file called "mysurface.slim" and enter the following text. Most of it should be fairly obvious as to what it does.

//header stuff
slim 1 appearance toslim {
instance surface "mysurface" "mysurface" {
description {}
eval [slimShaderMacro surface]

//declare a float parameter as a drop-down menu
parameter float mychannel {
label "Colour Channel"
default 0
description {choose a colour channel}
subtype selector
range {
{Red} 0
{Green} 1
{Blue} 2
//Declare a color variable as a colour parameter
parameter color myColour {
label "My Colour"
description "This is my colour"
default {1 1 1}
//declare a float variable as a tick box parameter. off = zero, on = one
parameter float doSomething {
label "Do Something Cool"
description {Turning this on will increase render times}
subtype switch
default 1
//declare a float variable and set it's min, max and step values using the range flag.
parameter float myvalue {
label "My Float Value"
default 0.5
range { 0 1 0.1 }


You can also use collections to group attributes. You can also specify either string or texture as subtypes for parameters - the difference between the two is that texture gives you a browse file button next to the string field, where string just gives a string field. There is currently a bug in Renderman for Maya where you can't specify a collection as closed/collapsed by default (you can still collapse them in Maya).

collection void diffuse {
state open
label {Diffuse}
parameter string diffTex {
label "Diffuse Texture"
default {}
subtype texture


In 3delight you can use pragma annotations within the .sl file to help create useful user interfaces within Maya.

01 January 2012, 11:32 AM
Thanks earlyworm.
I thought the same: "Cutter is good, but it's better to write something by hand". Using Notepad++, of course.
So now I need to learn TCL which is used in slim templates.
Just didn't think it's worth mentioning in my previous post.

Examples are very good. But I'm still going to learn templates writing from official slim docs. I think, it's just the better way to learn anything about prgramming.

01 January 2012, 01:35 PM
You don't need to know much Tcl to write Slim templates - it does have some odd quirks such as statements in comments can result in syntax errors. Creating an associated Slim file is the simplest way to go.

At the last place I worked which used RenderMan Studio we replaced the Pixar attribute editor code completely with our own. However that does make upgrading a lot more tricky.

01 January 2012, 03:05 PM
I'm not learning TCL itself, only what's provided in slim docs about it (in "Writing templates" section).
I've got another question. As I understand, after I have created my .slim template file I need to do several complicated steps to make slim read it. Something about setting environment variables, creating .ini files and editing them.
Is there a simpler way to make RFM use GUI enhancements from my template file? Like placing them both (.sl and .slim) in the same directory and adding a couple of lines into .sl file.

01 January 2012, 06:10 PM
Is there a simpler way to make RFM use GUI enhancements from my template file? Like placing them both (.sl and .slim) in the same directory and adding a couple of lines into .sl file.

Thats how it should be working by default without needing to load it into slim or tweak any ini files. Have you provided the same name to both the .sl and .slim files? Did you try clicking the reload buttom on the renderman shader node?

Its fine to write the slim templates by hand initially to learn it but once in production it could get tedious quickly and you might prefer copy pasting chunks from existing templates like earlyworm suggested or use an editor to generate it for you (check out that site in any case for some good renderman reference).

@Simon : did the customization also handle spline graphs and ramps from slim? The usual method of externalizing only the knot values is highly non-intuitive for artists and I've been wondering if there is a way to display the whole graph in the renderman shader node's attribute editor.

01 January 2012, 07:32 PM
Thats how it should be working by default without needing to load it into slim or tweak any ini files. Have you provided the same name to both the .sl and .slim files? Did you try clicking the reload buttom on the renderman shader node?
I tried to do as it's done in official docs, where header should be like this:
slim 1 extensions myName {
extensions myCompany myFunctionsPrefix {
template surface myShaderName {
Just did with a header provided by earlyworm and it works!

Now I've got 2 questions left:
For some reason only 1st word for collection label is displayed in Attribute Editor. E.g. if i have the following code:
collection void qwerty {
label {Test Group}
... some parameters here ...
Then only "Test" is displayed as group label in AE.
The same thing if I use double quotes instead of curly braces in "label" line. Am I doing something wrong or it's kinda bug in RFM?
How can I make some parameters (or even collections) become hidden/disabled (grayed out) depending on the value of some other parameter? The same example: I have "useTexture" float parameter and if it's value is 1 then additional parameters are displayed (textureFile, scaleU, scaleV, blur...).

P.S.: I always follow one simple rule: if someone helped me with something very important then I have to share results with others. Thanks to all your guys help I've started to write my universal RSL ( shader (
How do you think, is it good idea to share it or nobody needs it?

01 January 2012, 11:18 AM
Slim templates typically serve two purposes... a) they provide a more user-friendly UI for shaders within Maya and b) they provide additional functionality (nodes) within Slim itself (that's typically where tcl and rsl functionality mentioned in the docs comes into play).

As to your questions..

1. Try using camel case (and see if Maya interprets it accordingly) or failing that use underscores or dashes. ie. "testGroup", "TestGroup", "Test_Group" or Test-Group".

2. While it would be nice to enable/disable attributes or set values based on other controls I don't think it's currently possible without some sort of DIY method. Best place to ask is the Pixar Renderman forums, there might be some obscure command or method for doing such things.

Making sure your shader is well documented goes a long way, so making sure users know that if they turn off a particular control (ie... doReflections) or set the gain to a certain value (ie... if reflectionGain is 0) then it's not going to do any reflection calculations.

01 January 2012, 11:49 AM
You can do dynamic UIs in Slim in a Slim template using callbacks (I can't remember exactly what they are called) or by doing your own custom Tcl/Tk (which I would not recommend!).

However that won't translate over to Maya - using custom AttributeAE scripts with a custom node like Nick suggested would be the easiest way, but that gives you other restrictions.

@Sachin - There was a way to do splines, but it was very custom. The obvious way to do this would be to use resizeable arrays, but as you probably know any sort of array support in Slim is pretty rubbish. You can actually use the precode block in a DynamicFunction to insert a resizeable array, but as this is treated as blind data by Slim it doesn't check for name clashes and the shader won't compile. Also there is no way to assign an array in Maya as a primitive variable (and it would need to be on the geometry rather than the shader).

There are 2 alternatives which do work. You can use named RIB user attributes and reference them by name, or essentially have a mini language for splines which is passed as a string and then interpreted and returned as arrays by a shadeop DSO. Both of these work, but you need to handle the UI and getting data into the RIB file yourself.

Also note that the path to the sl file in the Slim file is important so that it can find it. Keeping them in the same directory is the easiest approach, but isn't required.

Note that it is 18 months since I have used RenderMan Studio so I am going by memory and some of this may have been fixed since then (although I wouldn't be surprised if they are still problems).

01 January 2012, 04:47 PM
to earlyworm
1. sorry, didn't understand you. What is "camel case"? I already named categories in MEL-procedure-like style. E.g. "TestGroup" and "Test_Group". Both work, but I thought it's temporal solution.
2. Thank you for making it clear.

About shader and it's documentation... I think, detailed description (for popup at hover) is already good documentation. But, of course, I attach a full docs for anything I publish.
BtW, is there kind of centralized RenderMan shaders library? The only thing I can find myself is this ( incredibly old site. (and this is also one of the reasons why I decided to write a shader myself)

01 January 2012, 06:05 PM
Camel case is when you join words together and use capitalization to visually SeperateEachWordAndMakeThemReadable - it's a workaround when you can't use spaces (or even other special case characters such as dashes or underscores).

In some cases Maya automatically recognizes when you've used camel case and separates the word for you in the UI (primarily in the UI).

Not sure about any other central resources for Renderman shaders.

01 January 2012, 07:31 PM
I was checking out some templates at work today and a label like {Diffuse Shading} seems to work fine for its collection at my end. Not sure why your {Test Group} doesn't work. Camel cases, like earlyworm suggested, should help if nothing works (I've seen maya automagically display my xml templates for maya assets with the correct space in between).

@Simon : Thanks for some great tips there! Its hard to find this kind of stuff either in the docs or the support forums. I have been told about the custom dso option before but never realized it would be such an extensive process to implement. I guess its complicated enough to merit that. I'll investigate further so thanks again! Btw, your site seems to have gone quiet for quite some time now?

01 January 2012, 12:52 PM
Have you tried not having a label at all and using:

collection void {Test Group} {

Sachin - yeah I really should get around to updating the website. I think this is the longest gap so far!

01 January 2012, 02:34 PM
Just tried that... Nope, it doesn't work. The same thing: group has only 1st word in AE.

Doesn't matter. At least I have grouping with readable names (you say, it's called camel case? :) ).
Having spaces in group names was just a try to make GUI even better. Dashes, underscores and "camel case" - it's fairly enough.

What's more important now is this problem ( which suddenly appeared from nowhere.

CGTalk Moderation
01 January 2012, 02:34 PM
This thread has been automatically closed as it remained inactive for 12 months. If you wish to continue the discussion, please create a new thread in the appropriate forum.