Keep Coding: Intro Tips for Houdini
So lately I have been working with Python and VEX alot.It turns out, writing code is super easy! Learning how it works, and trying to fix the error messages is the harder part. So here is a step by step workflow to better diagnose your coding workflow. This article is built for people starting to work with VEX and Python inside of Houdini. Such as absolute beginners who have no idea where to start.
This won’t include everything you need to know about code in Houdini, but this might help you get started.
There is also some advice at the beginning for those willing to make the jump from SOPs to code. Enjoy!
Stick to SOPs? Or get Vex’d With VEX?
Why use VEX when Sidefx is building all these amazing SOPs? Well sometimes the best way to customize something is through VEX. VEX and python also get pretty unavoidable in the later years of your Houdini/FX career. It can be much faster to write 3 lines of code vs playing with a SOP for an hour to get something right.
SOPs are great for quickly generating presets, generating attributes quickly, and now they are leaning towards simulations. Sidefx is truly doing a great job of streamlining simulation tools, but sometimes there isn’t a preset for everything. VEX is commonly compared to C/C++ code. It is a general purpose language for writing custom shaders and nodes.
Mastering VEX is also a great way to start learning about what is going on under the hood of the software. Most of the SOPs and other nodes in the software, you can unlock, and dive inside. A lot of nodes are built with a series of VOPs, VEX, and other nodes. But really at the base of it all, someone had to code them to exist. For Example, with VEX you can call noise libraries to create noise patterns. These noise commands in VEX are used to help create the Attribute Noise SOP.
VEX is also a gateway drug into other coding languages such as Hscript and Python. (Yes, a drug, change my mind. Once you start coding you can never go back.) Many coding languages overlap in how they handle variables, and statements. So learning one always helps you in more than one way.
VEX on average runs faster than SOPs as well. Because VEX code is localized to a single operator, and has a very direct methodology listed, it is a bit more efficient. Along with the fact that you are also scripting something for a specific context.
Now after that whole spiel, here are some tips for VEX.
Looking for Problems in VEX:
When something goes wrong in my code, I find that the best way to find the issues is doing a general scan of the script for one problem at a time. I usually do this in steps.
Step #1: Look for bracketing issues. Sometimes if you are dealing with multiple if statements, large amounts of code, or for each loop, you can forget to add an extra bracket. So in the first read through of your code, look for missing brackets.
Step #2: Semi colons. In VEX, semicolons are used at the end of every statement. If they are missing, the code won’t work. In this step, look for any missing semicolons.
Step #3: If or for statements. Sometimes, I find that I’ve accidentally typed for instead of if. This in turn changes the purpose of the if statement. Double check that you haven’t done this.
Step #4: Dealing with large amounts of code? Use multiple wrangles. Sometimes breaking apart your code, and using separate wrangles can help you stay organized. For example, if you could use one wrangle to set up your variables and attributes to call. Then another wrangle to process them. Then if there are any issues setting up your variables, then you’ll be able to catch them earlier and isolate them.
Step #5: Floats or integers? Which one should you use? When you define something as a float it gives something more presion. This is because floats allow you to give your value an extra decimal place. So if you are creating a slider in VEX, you need to decide if your slider should display whole numbers, or ones that can be processed as a fraction.
Step #6: Notes. Leave notes for yourself. You can do this by using the // symbol. Notes are useful because they allow you to label certain sections of code. Or even remind you of errors that you encountered. Notes are also great if you know that you won’t be working in that file for a long time. They will remind you of exactly what you were working on and where to restart.
Step #7: Space things out. Adding extra spaces can help you break up your code and organize it better. So keeping this in mind while scripting will greatly help you.
Step #8: Look for misspelled attributes. It is quite common to misspell something in your code. Double check and make sure you are referencing the correct attributes. As well as spelling them correctly.
VEX and Python
So as I’ve mentioned, VEX and Python are similar. So you might encounter similar issues when working with each of them. For example, both scripting languages will error out if your attributes are misspelled, or are defined incorrectly. They can also have similar errors when it comes to referencing nodes and parameters incorrectly.
Python in Houdini doesn’t require a semicolon after every statement. However it does require a colon in some places. These are usually placed after an if statement, with statements, and definitions. So remembering this when switching between the two is important.
In VEX, you can easily reference another parameter in the scene by copy and pasting a relative reference into a wrangle. You can’t really do the same in Python. You have to directly reference the parameter name directly.
Wrangles in Houdini are now capable of working with python and VEX. However there are the Python SOPs you can work with as well. Working with the Python SOPs are super useful as they have presets that you can use. The current presets are for:
Move points up
Apply Subdivide SOP Verb
Run a generator Box SOP Verb
The regular wrangles also have several presets as well. These presets are dependent on which type of wrangle you are using. Per wrangle these are:
- Color from Bounding Box
- Random Point Color
- Color Based on Threshold
- Point Group on Threshold
- Fetch Second Input Cd Attribute
- Fetch Second Input Attribute by id/name
- Nearest Point Distance
- Grow Hairs
- Get Neighboring Points into Attribute
- Average Neighboring Points
- Pass Through
- Create Points where Positive
- Same as attribute wrangle
Same as attribute wrangle
- Create Points where Positive
- Same as attribute wrangle
Rig Attribute Wrangle:
- Same as attribute wrangle
Sidefx is trying to make VEX easier to understand. As well as a tool that can be used by beginners more. Hence the presets. Python on the other hand….
Well python and Houdini work hand in hand as well. When you are working in a Python Shell or node, you can use both Hscript variables and python ones.
When you use python in the software, there are several places where you can implement it. One being a Python node. This SOP/node allows you to create customizations to your build with python. The Python Shell allows you to test commands in the window. As well as preview any python outputs. Then there is the python source editor. This allows you to store things associated with that file. Such as functions, classes, and objects. This editor can also be referred to as the session module. Houdini always keeps a Python module associated with the scene file. This is it.
If you are working in a python SOP, you need to consider using the external Python Editor. This is one of the best python tools to use in Houdini. It allows you to maximize your screen when you are coding, and you can also choose which type of program to use as your external editor. This can be the default window in Houdini, notepad, or other documentation applications. When you are finished scripting, you can hit save or accept. Then your code is ready to go in Houdini.
Looking for Problems: Python
Python is pretty similar to VEX. However, you’ll most likely be using it in combination with HDAs, shelf tools, and json files. However, the formatting is quite different, and there are several issues you can run into that are not found in VEX. So here is a step by step method you can use to diagnose your code better.
Step #1: Spacing. Formatting matters with python! If you haven’t spaced everything out correctly, your code won’t work. Make sure your if statements and other statements are listed correctly per line.
Step #2: Colons. As previously stated colons are sometimes used in specific places in python. If they don’t exist, good luck getting your code to run. Double check to see if they are being used in the right place.
Step #3: Using the print statement. You can test to see if a script is working if you tell python to print something in the python shell. I generally space these print commands out over the series of the code. So if something doesn’t print, then you know which section doesn’t work.
Step #4: Referencing. If you are referencing a parameter on an HDA, or on a node, you need to reference the name of the parameter that is listed in the parameter window in the Edit Operator Type Properties. Otherwise, calling these parameters will be a challenge.
Step #5: Kwargs. This is a super important command. This creates a reference to the current node. If it is not used, then your callback scripts won’t work, neither will some definitions, and other pieces of python script.
Other Python Tips and Tricks
With python as we’ve mentioned, you can call Hscript variables. One way you can do this is with the lvar("name")/(hou.lvar() command. Lvar will call for the Hscript “local” variable, and allow you to access it. However this only works for local variables.
In Hscript there are two types of variables. Global and local. Global variables are variables that are available to all scripts and to any programs started by Houdini. Local variables are variables that are only found in the script being run. For example, a custom variable that you have created.
To call global variables use hou.expandString().
Local variables are arguably harder to call and work with in Python than global variables. For example, if you wish to reference a parameter expression on SOP, you’ll be calling a local variable. These parameters can change over time, and you need to make sure python understands that these values are changing. You’ll need to use the pwd().curPoint() or pwd().curPrim() commands to call point or primitive objects.
The hou.pwd() function is one of the more important functions in python. This returns the node containing the expression. It’s also a shortcut for writing hou.node("."). This function also works with hou.ch(), ch, hou.evalParm(), hou.parm(). These functions are relative to hou.pwd(). This is because hou.pwd() returns the node you are working in, and the other functions call the various parameters and data from inside the node.
Let’s focus on hou.evalParm(). This function works in tandem with hou.pwd(). It can return an integer, float, or string. But it is special in the sense that it allows you to perform relative parameter references from inside a node. However, it does not work with Mplay.
Now let’s talk about the Python source editor some more. I love this editor because it allows you to store information per file and session of Houdini. As well as save and load the information when needed. In order to create data for a session in a file, you’ll need to use the hou.session.YourNameHere expression. This will create a session for your file. From there you can create callbacks, or print expressions.
Python also gets along incredibly well with HDAs. In each digital asset you create and store information in Python. Each asset has a python module from which you can script. You can find this module on the Extra files tab of the type properties window.
Depending on what level of the scene your HDA is located on, you can call it with this command in the python module: nodetype = kwargs["type"]. You can also reference python functions in the python module of the HDA if you have python commands in the parameters of your HDA. For example, you could do this with the hou.node("..").hdaModule().foo() command.
HScript: Your Mom’s OG
Hscript is Houdini’s first scripting language. It is referred to as the legacy scripting language of the software. It has compatibility with older files and scripts. So it allows you to open up versions of files from older software builds, while still keeping them in the best working state possible. This language follows C shell expansions.
It’s not really recommended you script in Hscript. Rather in Python or VEX instead. Hscript is still used under the hood to hold everything together, but Python and VEX will get you places. Hscript helps control the display flags on your nodes, dump nodes as scripts, modify operators and parameters on nodes. All of these functions can also be done in Python.
One thing that I still enjoy with Hscript is that it also has the ability to call depreciated nodes. These are nodes that are no longer accessible in the interface of the software. You make them reappear in the interface, for example with this expression: opunhide Sop fluidsource . This will call the older version of the fluid source node. Of course if you are calling a DOP, VOP, CHOP, or other network folder type, you’ll need to exchange Sop for the name of the new folder type.
When working with this language you can also Recall a previous command on the command line by using your arrow keys. As well as repeat the last commands with: “!!”.
Hscript also allows you to create aliases of commonly used commands. For example, if you are frequently listing the same objects that exist in the scene, you can use “alias objs” as a way to call the objects.
Hscript also allows you to call host system commands, and also allows you to refer to different viewports of the interface.