Once you’re past the TouchDesigner beginner stage and you start to experiment with more operators and advanced techniques, a common issue that you may run into is your project’s lack of performance. Certain combinations of techniques, operators, and settings can cause major frame drops.
Learning how to optimize your projects for best performance is one of the key skills to learn as a TouchDesigner developer, and will only become more important as your projects get larger and more complex and when you start working in digital art.
In this post, we’ll cover basic TouchDesigner optimization strategies, looking at the built-in tools we have for assessing project performance and techniques for improving performance.
First Steps: Determining the Bottleneck
When starting the process of optimizing your project’s performance, the first step is to determine whether the bottleneck is coming from the CPU or GPU. We’ll take a look at two techniques that we can use to determine this.
Detecting CPU Bottlenecks with the Hog CHOP
The Hog CHOP is a useful built-in tool for finding if you have a CPU bottleneck. If you place a Hog CHOP into your project network and find that the frame rate goes down, you have a CPU bottleneck. On the other hand, if it doesn’t change, you likely have a GPU bottleneck.
Detecting GPU Bottlenecks by Reducing the Size of TOPs
To determine whether or not you have a GPU bottleneck, try turning down the resolution of your Render TOP or TOPs being composited to something very small (like 32×32) and see if the project’s frame rate changes. If it does change, you have a GPU bottleneck, and if not, you have a CPU bottleneck.
Finding the OPs Causing the Bottleneck
Now that you’ve figured out what kind of bottleneck your project has, the next step is to define what operators in the project’s network are causing the issue. TouchDesigner has a number of useful tools for doing so.
Operator Info Pop-Up
A simple, easy to access tool that you can use to get an idea of an operator’s performance impact is the Info pop-up. By middle mouse clicking on the OP in the network, a small pop-up appears which includes a variety of information about the operator. At the top is information relating to “cooking” (computing or calculating the operator’s output, see Derivative wiki for Cook), including how many times it has cooked, and how long the last cook took in milliseconds. If you don’t have a middle mouse button, it can also be accessed by clicking on the “i” icon in the upper left of the parameter dialog.
The Cook Time is how long it takes an operator to process in milliseconds. The Total Number of Cooks helps to see whether operator cooks once, every frame, or only when input data changes.
In the above examples, both operators are always cooking, which is why the Total Cooks statistic is so high for each. Another thing we can see is that the Displace TOP uses both the CPU and GPU, while the Noise CHOP only uses the CPU.
Performance Monitor
The Performance Monitor is a go-to tool for finding nodes with a high cook time (the higher the cook time, the more likely it is to impact performance) or for nodes that are unnecessarily cooking. Once triggered, the Performance Monitor shows a list of all cooks that occurred during one frame, in order, as well as the actual cook time for each item.
The results can be filtered by matching text, which comes in handy when used in very complex projects as the list can be very long.
Another useful feature of the Performance Monitor is the ability to choose a Frame Trigger in milliseconds. This allows you to filter out particular frames where the total frame time/cook time passes beyond a certain threshold.
An important thing to note: if the project is intended to run at 60 FPS it must be able to complete all operations within 1/60th of a second, or 16.666 ms. If the Total Frame Time surpasses ~16ms, you’re likely to see dropped frames or other issues. The goal is to keep the total frame at or below 16ms.
Probe
The Probe is another great built-in tool for getting a handle on what operators are impacting your performance. Unlike the Performance Monitor, it graphically showcases how the CPU (and GPU!) are consumed in real-time. In the probe window, a “map” of the project’s network is displayed, with shapes placed over top of each OP to illustrate their performance impact. Circles show CPU cook time, and diamonds show GPU time. A color based on the gauge at the left of the window will be assigned to each shape, giving an indication of the cook time.
In the example above, the Noise CHOP in the lower right of the graphic has a CPU cook time of about ~2ms. It’s easy to spot as the most performance-heavy operator of this network. However, note that the Probe itself (upper left corner) has a roughly 3.5ms cook time in this case! It’s recommended that you turn off or remove the Probe from your network when not in use, as it can impact your project’s performance.
Unlike the tools we’ve looked at so far, the Probe has to be added to the project from the palette (it’s located under the Tools category).
Strategies for Optimization in TouchDesigner
Now that we’ve looked at some tools for finding out which operators might be causing the problem, let’s have a look at some strategies for improving performance. Some are more general, and others specific to certain operators or operator families.
Turn Off Operator Viewers
When working in the Network Editor, turning off the Viewer for each OP can dramatically improve performance, especially when dealing with DATs that have a large amount of data being processed or CHOPs with a large number of samples. This won’t help when using the project in Perform mode, but can be very helpful as you’re developing the project.
Make Use of Perform Mode
For more seasoned user, this might be obvious, but for the beginners out there, Perform Mode is an optimized mode intended for live performance that only renders one specified Window COMP. This will allow for your projects to run much more efficiently, as TouchDesigner does not have to draw the user interface and network editor.
CHOPs: Reduce Cooks with CHOP Execute DAT
When working with multi-channel CHOPs, it’s easy to create additional cooking where you weren’t intending to. Take the example below: we have three CHOP channels, each linked up to the Red color parameter of three Constant TOPs. Of the three channels, only chan1 changes. But yet, as evidenced by the Info CHOPs on the right, every time that chan1 changes, all three Constant TOPs cook.
If we instead use a CHOP Execute DAT to make the parameter changes, we can see that the total cooks only increase for the TOPs that are impacted by the changing CHOP channels. The constant1 TOP cooks when the chan1 CHOP channel changes, while constant2 and constant3 do not.
SOPs: Transform at the Geo COMP
If possible, avoid using the Transform SOP and instead do transformations at the Geo COMP level. It’s not always possible to do so, but changes at the Geo COMP will be significantly more efficient, especially if the geometry in question has a lot of points.
Get Our 7 Core TouchDesigner Templates, FREE
We’re making our 7 core project file templates available – for free.
These templates shed light into the most useful and sometimes obtuse features of TouchDesigner.
They’re designed to be immediately applicable for the complete TouchDesigner beginner, while also providing inspiration for the advanced user.
In the above example, using the Transform SOP results in roughly ~2.1 ms of CPU cook time, whereas transforming via the Geo COMP results in just ~0.02 ms!
Use a Switch TOP instead of a Cross TOP
In many cases, you can achieve the same crossfade-style effect with the Switch TOP as you could with the Cross TOP, but with less performance impact. The reason? Both inputs to the Cross TOP will cook when its output is displayed, whereas the Switch TOP only cooks the operators that are currently being displayed. In the above example, the Switch and Cross TOPs are set up to only output the banana image from the moviefilein1 TOP. When we view the output of cross1, both inputs (transform1 and transform2 TOPs) start cooking. When we view the output of switch1, however, only transform1 cooks — saving us from unnecessary cooking!
Blur TOP: Filter Size Parameter
The Filter Size parameter is another setting to watch out for. In the above example, the blur1 TOP has its Filter Size parameter set to 63. blur2 uses a combination of the Pre-Shrink parameter and the Filter Size parameter to achieve a similar effect (Pre-Shrink: 4, Filter Size: 14). The difference? blur1 has a GPU Cook Time that is just about 5x larger than blur2! If possible, work with the Pre-Shrink and Filter Size parameters together to avoid potential performance pitfalls.
For further info on optimizing your TouchDesigner projects, check out the Derivative Wiki’s Optimize article. Ben Voigt of Derivative also recorded a great three part tutorial series covering TouchDesigner optimization with TDSW back in 2020:
1/3 TouchDesigner Vol.035 Cooking, Optimization, & SceneChanger
2/3 TouchDesigner Vol.035 Cooking, Optimization, & SceneChanger
3/3 TouchDesigner Vol.035 Cooking, Optimization, & SceneChanger
Both of these resources have been invaluable for putting this post together!
Wrap-Up
That’s a wrap! Optimization is a huge topic, but we hope that this has given you the basic foundation you need to start optimizing projects of your own. Now, as you start building new projects with the program, you can keep these tips and techniques in mind to ensure good performance from the start!
