![]() |
Houdini Development Toolkit - Version 6.5Side Effects Software Inc. 2004 |
When Houdini reads a dialog script, it will automatically make a UI file and provide a graphical interface for editing a string. Houdini has "hooks" for a dialog script interface in several parts of the application. These are:
When adding a macro/shader to a dialog script, it is not necessary to replace the scripts installed in $HFS/houdini/config/Scripts. Since all scripts found in the Houdini search path are merged, you can simply install these scripts in any of the path directories (i.e. /usr/local/config/Scripts).
As well, there are special controls in the script for special features. For example, if the script is supposed to parse a RenderMan shader, there is a special keyword to use the RenderMan syntax. Other special features are the ability to group parameters into individual pages.
The general form of a dialog script is:
command { header parameter_list }The header definition is basically used to define what the command is at a global level. There are certain fields which can be specified at this point: Only the rman keyword doesn't take any options after it. All of the other keywords expect a string to follow. The help keyword expects a series of strings enclosed by a set of braces ({ and }). See below for an example.
HINT: When specifying strings, the script requires that the string be enclosed in double quotes (") if and only if there are spaces in the string. However, it doesn't hurt to put the double quotes for all strings.
HINT: The name usually specifies the name of the command. Theoretically, it should not contain any blanks. However, this is not a limitation though presets may not work correctly.
parm { field value }There are some fields which are mandatory for each parameter. These are: There are also optional fields which can be used to alter the parameter slightly. These are:
menu { value label value label value label }where the label will show up in the UI, while the value is what is actually used for the field.
default { value1 [value2...] }Where each value specified is for a different component of a vector. For example, if the size of the parameter was 3, you would probably want to specify three default values. If no default is specified in the parameter declaration, the parameter will default to 0 (or an empty string).
parm { name rolloff label "Spot Light Rolloff" type float option -r size 1 default { 1 } }This example shows an optional parameter which is a single float value. It defaults to 1.
parm { name scolor label "Specular Color" type color required size 3 default { 1 1 1 } }This example shows a required parameter which is a color. When the UI is built for this parameter, it will contain a set of RGB sliders for editing the parameter.
parm { name nproc label "Number of Processes" type string option -n menu { 1 "1 Process" 2 "2 Processes" 4 "4 Processes" } }This example shows how you can use a menu to cheat and specify an integer as a string. The menu will simply use the value (i.e. 1, 2, or 4) but present the user with a list of choices.
group { # First group of parameters/folder tab name string # Name in the tab label string parameter_list } group { # Second group of parameters/folder tab name string # Name in the tab label string parameter_list } ...It's possible to fit as many folders as you want in the dialog script (however, there may be formatting problems when the UI is displayed). It is also possible to nest groups, though in general, this is bad UI design since it hides paramters from the user.
It is also possible to mix parameters so that some are always displayed,
then the folder tab is a separate entity. For example:
command {
name folder
label "Folder Example"
help {
"A simple dialog script to show that the always parameter"
"is always visible even when the groups get switched."
"The groups appear below the \"always\" parameter."
}
parm {
name always
label "Always visible"
}
group {
name page1
label page1
parm {
name opt1
label "Option 1"
}
}
group {
name page2
label page2
parm {
name opt2
label "Option 2"
}
}
parm {
name always2
label "Shows up after the folder"
}
}
Examples
Many examples can be found by looking in $HFS/houdini/config/Scripts.
Testing Dialog Scripts
There is an application which is shipped with the development toolkit called
dsparse. This will parse a dialog script and allow you to experiment
with the layout and adding parameters.
Common Problems
When each dialog script first gets parsed, it creates a .ui file
(See Customizing UI). This file is created
in /usr/tmp/Dialogs/...
This specifies the UI layout for the dialog script. When this file is
created, the UI is locked for the script. Therefore, even if parameters
change, the UI displayed will be the same. Therefore, when testing, it
is almost mandatory that this UI file created is removed between each
test.