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.