uiS[cript]Py: Quick 1st Example

NOTE there seems to be a quirk where wordpress is mutating certain symbols so to use example properly for now, please copy and paste to a text editor, and replace the single quote with.. Yes, what appears to be the same single quote on your keyboard… if you run into this issue. When I have it patched, this note will no longer ne here. Thanks.

Here is a quick example to get everyone started. Its not particularly meaningful but shows basic usage. The manual is in HTML with the download and is fairly complete. If its in there and promoted to the uispy namespace, for the most part its been working. Methods have docstrings and if using the built-in houdini Py Shell, you will see them as normal in the nice little popup.

import uiScriptPy as uispy

# basic container is needed in this case a row
myrow = uispy.ColunnUiScriptContainer(‘myrow’)

# a simple float tuple
myfloat = uispy.FloatUiScriptGadget(‘myfloat’, ‘My Float’, 3)

# Top of dialog
mywin = uispy.DialogUiScriptWindow(‘mywin’, ‘My Win’)

# set the float to the row

# set the container to the dialog

# create a basic interger and set range on slider
myint = uispy.IntUiScriptGadget(‘myint’, ‘My Int’)

# append slide to the row container

# color widget with alpha
mycolor = uispy.ColorUiScriptGadget(‘mycolor’, ‘My Color’, has_alpha=True)

# a password string field
mypassword = uispy.StringUiScriptGadget(‘password’, ‘Password’)

# a lablel with a little styling
mylabel = uispy.LabelUiScriptGadget(‘mylabel’, ‘My Label’)

# basic column container
mycol = uispy.ColunnUiScriptContainer(‘mycol’)

# add color, password, and label to column

# a collapser is uncommon but useful to conserve space
# create collapsed initally, and containing column of widgets  
mycollapser = uispy.CollapserUiScriptContainer(‘mycollapser’, ‘My Collapser’, (mycol,), collapsed=True)

# set the row and collapser to the window
mywin.setUiScriptGadgets((myrow, mycollapser))

# create the dialog from the script
d = mywin.createHouDialog()

# now we can retrieve a gadget from the dialog
#  this can be thought of similar to a parameter object
#  for the parameter pane via parmTemplates
myfloat_gadget = d.uispy_gadgetTuple(‘myfloat’)

# query the raw values

# use extended method provided to destroy dialog cleanly


uiS[cript]Py: Announcement. uispy download available


I have decided to make available a python wrapper for Houdini’s uiscript. It has been the result of needs I have had and was largely ripped from another defunct project. It should be considered alpha. I am aware of a couple efforts to do this, however I think uispy is fairly robust and useful.

Hopefully this will also provide an exploratory opportunity to document its clean-up here on  eyevex.com bit by bit in the New year (assuming compatibility with h16 for now). At that time some examples, tutorials and explanations will be coming, until then feel free to download and poke around.

It is acknowledged, that a few things are broken or missing, some the scripts are a bit hacky, there are places for improvement, and a bit that is completely wrong, but working. This is alpha, which mean it has only been used my myself and really only on a specific setup, in my case that’s Linux 64, kubuntu. Earlier versions were tested win win7, but have not been in sometime. Its development also means it lack some safety checks and sometimes you may be allowed to use values that wont properly build the dialog. This will be an area of improvement as the module is cleaned up.

Why do this at all…. There’s a few reasons to… and a few reasons not to. As uiS[cript]py uses only standard python and built-in Houdini libs, it provides a clean and safe way to create simple dialogs beyond the basic tree, multiline and lists in HOMs hou.ui While currently pySide and pyQt provide ways to build large robust interfaces, often a simple native dialog without worrying about qt deps or learning large libs is needed, and this fills that space. For those familiar with parmameterTemples in HOM, the naming of methods and usage closely mirrors that workflow. UI Script is also used for Cpp plugs as a quick way to build interfaces, in the future this may provide an easy way to design uis visually and dump the script.

This is a more advanced topic and not all basics wont be gone over, hopefully all interested will get something from it, but in the end the inner workings will likely most interesting to Pipeline/dept/show Tds. Example usages will probably be of broader interest and for reader that just wants to get to using it.

happy CG’ing. (|;-D>

eyevexTools HOM redundant functions depreciation

This space has gotten a bit stagnant and as for a multitude of reasons several post never made it to publish, however I am moving forward with a larger series on uiS[cript]Py. Most of eyevextools is working although need to be tested in recent versions. However, a lot of the much needed functionality we explored here has since appeared in the HOM module. This is great, but has made much of EVT redundant. In the near future I will be depreciating these parts. Posts and downloads will remain available for those that want to follow along but depreciated features wont be maintained.


Looking Through: part 6 — Whats Included

This series of posts looked very closely at Camera and Light node types and how to write a function that does its best to determine likely matches to the viewport transform matrix in order to determine what object node is being looked through.

The functions described are now included in ui.py 0.2.0 and ui.py is now included in eyevexTools 0.4.0 with the usual comments and doc strings. As an extra convieniance the following function were added, simply calling viewportObjects() with various flags set….

  • viewportLights() – additionally flags off all camera types
  • viewportCameras() – additioanlly flags off all light types
  • viewportStereoCameras() – only stereocam and stereocamrig are flagged on
  • viewportStereoCameraRigs() – only stereocamrig is flagged on
  • viewportMonoCameras() – only camera is flagged on

Hopefully after reading this series a custom function could be easily built similar to viewportObjects() by calling viewportObjectsOfType() for your own custom camera or light types as well.

I would also like to thank James Fisher Lighting Guru for verifying some lighting practice info for these posts.

….Thats about wraps this up. As usual, if you have questions, feedback, or bugs found drop me a message.

Looking Through: part 5 — Narrowing

The base function constructed in the first part of this series of posts takes a tuple — node_types to pull the instances and perform the matching. The last two sections went in detail on the types that will be searched for and why the defaults can be expected to be flagged on or off to avoid the most false positive results and remain the most useful. Below the new function and args are introduced…

def viewportObjects(


 If the last two sections were looked at these args and defaults should be of no surprise. The one exception is the last arg, ignore_ipr_cam, which will be explained in a moment.

Each arg’s flag is tested and the type append to a list, that eventually gets used as an arg for the base function. ie…

# check for light if flagged
if light:node_types.append(‘light’)

After all the flagged on types are appended…

# look for matches
viewport_objects = list(viewportObjectsOfType(node_types))

There is a hidden camera node /obj/ipr_camera which will match the viewport transform. If you need to see it to believe it, go to the network editor, press CTRL+L and paste /obj/ipr_camera into the address bar and you will be inside the ipr cam node. Whenever we flag on cam as a type we are looking for, it will give us a false positive result, so we need to remove this from the results. As it is of a desired type, the easiest was it to check the name against ‘ipr_camera’.

# remove ipr_cam if flagged
for obj in viewport_objects:

if obj.name() == ‘ipr_camera’:


Lastly when there a results, they are returned as a tuple.

if len(viewport_objects) > 0:

result = tuple(viewport_objects)

return result

And thats about it! It should now be clear on how to construct a usable function that return a light/cam matching the viewport transform matrix. The last section will look at what included in the download module and what is incorporated into eyevexTools.

Looking Through: part 4 — Cameras

In the last post the many represented lights were looked at in terms of their actual operator type and relationship to transforms and the viewport. This post will look a cameras in a similar fashion. The camera type selection is much slimmer and consists of …

  • camera of type cam
  •  stereo camera of type stereocamrig
  • stereo camera template of type stereocam

**NOTE** The names as per the GUI compared with the node type can be a little confusing. Similar to Light being of type hlight and light templates being of type light, the stereo camera is of type stereocamrig and NOT stereocam which is the type for the template.

stereocamrig includes a stereocam inside that is the same transform as the rig. Likewise, the center camera inside is transformed via stereocam and also has the same transform. Unlike three_point_light, only the top level of the Stereo Camera appears in the viewport pull down menu. However, the cameras internal to the asset can be looked through via dragging them onto the viewport. This makes the results somewhat ambiguous as any of the center cam, stereocam, and stereocamrig will all return as matches. When calling the narrowed version of viewportObjectsOfType() the appropriate flags will need to be set depending on if the result being looked for is a sterocamrig or individual cam. As an alternate method, all can be left on an the result sifted through.

Next the narrowed function will be constructed to return cameras and lights with the argument default logically set a described in this and the Lights section.

Looking Through: part 3 — Lights

There are several lights that appear both on the shelf and via the TAB menu. However, when you look closer, you will immediately notice alot of these are just setting parms differently on the same node types.

  • Caustic Light,Indirect Light, and GI Light are all of type indirectlight
  • Ambient Light is of type ambient
  • Environment Light is of type envlight (so is half of Portal Light and Skylight – explanation below)
  • Light Template is of type light
  • Light, Point, Spot, Area, and Distant are of type hlight ( half of Sky Light is an light too)

Below the various light are examined closer and in terms of how they affect viewport matching…

H12 Shelf Lights

H12 Shelf Lights

light template (light)
Light templates are basic stripped down version of light and according to the docs intended for building up a new light type without having to strip down a light (hlight type) instance.

three_point_light is a great included HDA for a 3-point setup with all the widgets for control. The key, fill, rim and bounce light inside the three_point_light setup are all Light instances and type hlight. Each light in the setup will therefore match properly. However, looking through a three_point_light, is the same as looking through its key light. This is important to note as scripts that use this function should take into account that this difference cannot be discerned.

indirect and ambient lights
Since we are comparing the transform of the light to that of the viewport, we are going to want to check against lights that have controls to position it. indirectlight and ambient types lack these controls. This is logical, as they are indirect, having the ability to absolutely position them via viewport widgets or parms would benefit little. Likewise, it would not make much sense to look through them in the first place as doing so in practice is usually to aim the light and to view what the light ‘sees’. However, as you are permitted to look through indirectlight, we will build in the ability to match them for completeness, although this will be flagged off by default.

Environment lights only have rotation parms. In the case of a hemisphere this may be particularly useful as well as  ” to orient directional illumination.” But, quick use of these unrotated will result in all coming up positive matches, as their transforms will all be identical and in practice it is less than useful to aim the light by looking through them, although the ability is present. Therefore they are flagged off by default and not considered although they can be flagged on.

About Portal and Skylight
Portal Light and Sky Light are special cases of envlight that drop two top level nodes.

Skylight drops a envlight named “skylight” and also an hlight named “sunlight” — the reason for this setup is not %100 clear, but it is what it is, so it needs to be dealt with it the scripts. There’s a viewer widget attached to the hlight that allows the translation of the sun, but not rotation. The rotation comes from the envlights Sky Environment Tab –> Sun Tab –> Rotate Parms. Changing these results in visible changes to the sun widget on the accompanying node. However, selecting the envlight node shows the viewer widget for rotation, but as per normal rotates the envlight dome a previously mentioned. Yikes! Fortunately when left unrotated, false positives are avoided on the dome by leaving envlights flagged off.  The rotation of the map will still be taken into account via the channel linking to the “sunlight” hlight node, which to be useful would need to be translated away from the origin,and the combo of these two things should produce a unique transform. As, hlights are considered by default, and “sunlight” is still of type hlight there should be usable results by testing against this nodes transform matrix.

Portal Light as provided by the shelf and TAB menus is basically a shortcut to create an envlight with the portal geometry per-assigned. The geometry then restricts the envlight so that it only passes through the assigned object. We can flag on to consider envlights, but the transform that actually is restricting is that of the objects assigned which is arbitrary, so can’t be considered, and additionally can not be looked through Considering envlight will also consider those used for portal light and may not produce the result expected as the envlight it self, as mentioned is at the origin and not useful to look through.

Hopefully this section provided a good overview of the relationship between the lights as depicted via the shelf/TAB menu and their actual type, as well as the default arg flags as will be used in the narrowed function calling the more general viewportObjectsOfType() to be explained in an upcoming post.

Next, a closer look at cameras and their relationship to the viewport.