![]() |
Houdini Development Toolkit - Version 6.5Side Effects Software Inc. 2004 |
The User Interfaces of Parameter dialogs in houdini are specified in special text files which are located in appropriate sub-directories of $HFS/config/Dialogs. If they don't already exist, these files are automatically created by houdini, using the operator's list of parameter definitions (See "Class Hierarchy/Data Structures" and "Using Parameters" for details). If the UI files do exist, then they are simply read and then used to create the dialogs.
What this means is that the first time you run houdini with a new custom operator, a UI file will be generated for your custom operator. After that, you can edit the UI file using any text editor to customize the parameter dialogs.
The UI file uses the standard houdini UI specification format (See Customizing .ui files). The parameters are tied to the gadgets and controls using VALUEs with prefixes based on the name of the parameter and on the subcomponents of the parameter. Appended to the prefixes are the following suffixes (where applicable):
There is one more suffix, .menu, that is used to specify the gadget that is used to generate the menus that are used in the dialogs. The actual menu gadget and its contents are not customizable from the UI file, though some aspects of its appearance are customizable through the common gadget attributes like SIZE and LOOK.
NOTE: For each parameter, there are two sets of gadgets and VALUEs. One set contains the numerical value of the parameter, while the other contains the expression that defines the numerical value. The former can be a float, int, or string type VALUE, while the latter is almost always a string (unless it's used in a toggle or something). The VALUEs that are used to control the expression view have ".expr" appended to the names of the corresponding VALUEs in the non-expression view.
In general, you can tie as many gadgets as you wish to these VALUEs so long as the gadget can function with a VALUE of the given type and size.
For example, the "translate" parameter of a Geometry OBJ Operator would have a size of 3 (x, y, and z translate), and so you could use a VECTOR gadget (of size 3), or an RGBEDIT color editor (which would interpret the x, y, and z sub-components as r, g, and b) The VALUE for the whole parameter would be associated with the prefix "t", and the sub-components of the parameter would have the prefixes "tx", "ty", and "tz".
To use an RGBEDIT gadget you would have the following:
RGBEDIT VALUE(t.val) STRETCH(1,0);
You could also have a separate slider gadget for each of the sub-components:
{ LAYOUT(vertical) STRETCH(1, 0) SLIDERFIELD float "x:" VALUE(tx.val); SLIDERFIELD float "y:" VALUE(ty.val); SLIDERFIELD float "z:" VALUE(tz.val); }
It would take too long to try to document all possible customizations that are possible. Existing UI files are a good resource to use in figuring out what is possible. And the HDK mailing list should be another good resource.
The point SOP's dialog has been customized so that color-sliders are not used for the point color parameter, the many redundant labels are removed, and the dialog is in the "expression view", by default.
The label removal is the most trivial. For example, here's the original UI definition for the "doalpha" parameter. This parameter is the one controlled by the menu containing the options "Pass Through Alpha", "Add Alpha", and "Remove Alpha".
doalpha.gad = { LAYOUT(horizontal) STRETCH(1, 0) { LOOKTEXT(plain, "Point Alpha") SIZE(1.5, 0)} doalpha.menu VALUE(doalpha.menuval) LOOKTEXT(select, doalpha.menuval) STRETCH(1, 0); }
The text "Point Alpha" before the menu is redundant given the menu entries, so we removed it from the UI file by simply deleting the gadget containing the text.
doalpha.gad = { LAYOUT(horizontal) STRETCH(1, 0) doalpha.menu VALUE(doalpha.menuval) LOOKTEXT(select, doalpha.menuval) STRETCH(1, 0); }
The removal of the color-sliders is more involved, but illustrates the important point that all parameters are controlled by a VALUE called "<token name>.val". You can specify whatever gadgets you want for controlling the VALUE -- so long as the gadget understands VALUEs of the right size.
So in this example, the "diff" parameter is manipulated through the VALUE called "diff.val". And any gadget that works on a VALUE of size three (for the red, green, and blue subcomponents) can be used to edit the VALUE.
The default UI for color sliders is rather complex, consisting of two buttons controlling the type of color slider (RGB or HSV color model) and a "SWITCHER" containing the two color sliders. The switcher is controlled by a VALUE called "diff.switcher.val", which is in turn controlled by the two mode buttons above the switcher. The switcher displays one of its two children (RGB slider or HSV slider). Here is the default UI definition for the "diff" parameter:
diff.switcher = BUTTONSTRIP radio { LAYOUT(horizontal!) VALUE(diff.switcherval) LOOK(none) BUTTON push LOOKICON(HSV, bevel); BUTTON push LOOKICON(RGB, bevel); } SF_SIZES 0.15 0.15 3.5; diff.gad = { LAYOUT (vertical!) LOOK(plain) STRETCH(1, 0) { LAYOUT(horizontal!) MARGIN (0, 0) STRETCH(1,0) { STRETCH(1, 0) LOOKTEXT(plain, "Diffuse Color") } BUTTON push HELP("Colour List") VALUE(diff.plus) LOOKICON(DialogBox, bevel) SIZE(HEIGHT(diff.switcher), HEIGHT(diff.switcher)); diff.switcher; diff.chmenu; } SWITCHER { VALUE(diff.switcherval) STRETCH(1, 0) HSVEDIT VALUE(diff.val) STRETCH(1, 0); RGBEDIT VALUE(diff.val) STRETCH(1, 0); } } SF_SIZES 0 0.3 2;
Note: The SF_SIZES lines are changing the settings for the ratio of sizes between each slider's constituent parts (label, field, slider-bar) The color sliders require a 0.15:0.15:3.5 ratio, while the other sliders in the Dialog file require a 0:0.3:2 ratio.
Essentially though, as with all parameters, the "diff" parameter is being manipulated via the VALUE referenced by the name "diff.val". As you can see, both the HSVEDIT gadget and the RGBEDIT gadget are tied to this one VALUE. In customizing the UI for this parameter, we simply delete all the stuff that deals with the color sliders and replace them with a VECTORFIELD working on all three parts of the parameter:
diff.gad = { LAYOUT(horizontal!) STRETCH(1,0) VECTORFIELD(3) float VALUE(diff.val) STRETCH(1, 0); diff.chmenu; }
As for the Expression view being the default, we simply added at the end of the UI file:
switcherval := 1;
"switcherval" is the VALUE that controls the SWITCHER containing the Expression and Value views of the parameters. It has simply been set to 1 so that the Expression view is the default when the point SOP is first viewed.