Although it’s been nearly a year since POPs made their way to the Official TouchDesigner builds, there’s still a lot to learn and explore with the latest operator family. Though there are some similarities between POPs and their predecessor, SOPs, the new family brought with it many new features and improved workflows which continue to be expanded. In this post, we’ll compare TouchDesigner POPs and SOPs, covering some of their similarities and many differences, including improved performance, updated point cloud workflows, and more.
Before we begin, a bit of context from Derivative on the POP family:
POPs are a replacement and re-think of TouchDesigner’s historically first operator family, SOPs (1989), with many new features and benefits. Like SOPs, POPs are a procedural family of operators that create and affect points, and primitives like triangles, quads and lines.
As we’ll see in this post, in general POPs give a significant performance boost compared to SOPs, as they are GPU-based, along with a better, more modern workflow.
POPs vs SOPs: Similarities
Rendering
Both SOPs and POPs use the same technique for rendering: add a Geometry COMP, Camera COMP, and Render TOP (at minimum). SOPs and POPs can be rendered in the same Render TOP, as shown above.
Geometry COMP Shortcut
Just like with SOPs, you can right-click on a POP and select a Geometry COMP to create a In and Out POP within a Geometry COMP. It’s a handy shortcut to have as you’re experimenting with geometry!
Instancing
POPs can be used for Geometry Instancing, allowing the use of POP attributes within the Instancing parameter pages. POP geometry itself can be instanced, too. The example below shows five instances of a Sphere POP being generated, using the points of a Line POP for the position of each instance.
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.
POPs vs SOPs: Differences
Performance
Probably the biggest area of difference between POPs and SOPs is in their performance. SOPs, a carry over from the Houdini days, are CPU-based, and thus have significant performance limitations when it comes to realtime manipulation of geometry. Take the above example, which includes a Sphere SOP set up to generate 100,002 points. This in itself isn’t a problem, but once the Noise SOP is added, which manipulates the position of each point in the sphere, we start to see trouble. On my machine, the framerate dropped to 15 fps, which you can see in the Perform CHOP in the image. Not an ideal outcome for realtime performance!
However, set up the exact same network with POPs, and you’ll see a world of difference. TouchDesigner has no problem manipulating the point positions of a Sphere POP with 100,002 and keeping a steady 60 FPS the whole time.
Below, you can see the difference in CPU and GPU cook times for the Noise SOP and Noise POP at 100,002 points. Notice how high of a cook time this amount of points causes with the Noise SOP. This is why the frame rate drops so significantly!
Particles
To further illustrate differences in performance between SOPs and POPs, let’s now take a look at particles. In both examples, the particle data is used for instancing point geometry, which is then rendered with the Point Sprite MAT. The Particle SOP example above, with 150,003 points, is only able to achieve ~25 FPS, while the Particle POP-based example below is able to maintain 60 FPS with 1,000,000 points. That’s a big difference!
Besides the performance differences, the Particle operators for each family are another place to note differences. Even though the SOP and POP families both have a Particle OP, the feature sets are very different.
The Particle SOP has built-in features for applying external forces like gravity and wind, the ability to set up collisions and bouncing off of other objects, along with surface attractors. External forces, objects to be used as collision surfaces or surface attractors are all connected to the Particle SOP’s inputs.
Although the Particle Source, Collision, Force, and Surface Attractor inputs to the Particle SOP allow for creative exploration with particle systems, they are ultimately limited by the performance restrictions of SOPs. Along with that, certain techniques that are easy to accomplish in POPs may be much more difficult or impossible to accomplish in SOPs. For example, adding a random force to each particle is simple to achieve in POPs, but would be much more difficult to achieve in SOPs.
The Particle POP, on the other hand, takes a slightly different approach. Rather than having various inputs for defining position, forces, collisions, and surface attractors, it uses POP attributes to define particle behavior. The particle system is much more open and easily customizable due to the addition of a feedback-type loop, which allows the insertion of various POPs into the simulation to modify the attributes of the particles. For example, a Force Radial POP can be inserted within the loop to apply forces to the particles. But because this system is all attribute-based, it’s just as easy to insert a Noise POP instead and use that to apply forces to each particle. There’s a lot of room for exploration! And because it is GPU-based, it can handle millions of points.
All that being said, the takeaway here is that just because you might see an operator with the same name in both the SOP and POP family, the feature set will very likely not be the same. Typically, POPs have expanded significantly on the features of their SOP counterparts, or bear little resemblance to them.
SOPs and their Equivalent POPs
With those differences in mind, here is handy table that Derivative put together that provides some suggestions for POPs to use in place of some SOPs, which can be handy if you’re already familiar with SOPs. Note that in a lot of cases the POPs listed will have more features than their SOP counterpart, so it’s worth reading the documentation for more info.
| SOP | function | POP |
|---|---|---|
| Add SOP | for creating points only | Point POP |
| Facet SOP | for creating normals | Normal POP |
| Point SOP | simple math on points | Math POP, Math Mix POP |
| Limit SOP | channel to points | CHOP to POP |
| Limit SOP | creating geometry | mostly Copy POP |
| Texture SOP | coordinates for textures | Normalize POP, Texture Map POP, Projection POP, Line Metrics POP |
| Trace SOP | outline from image | Trace POP |
| Vertex SOP | vertex attributes | Math Mix POP, Attribute POP, several others |
| Attribute Create SOP | create normals and tangents | Normal POP |
| Attribute SOP | delete and rename attributes | Attribute POP |
| create new attribute | many: Attribute POP, Math POP, Math Mix POP, Math Combine POP, Limit POP, ReRange POP | |
| attribute math like Math CHOP | Math POP, Math Mix POP | |
| rerange like Math CHOP | ReRange POP, Math POP, Math Combine POP | |
| functions like Function CHOP | Math Mix POP, Math Combine POP | |
| Deform SOP | bone-driven deformation | Skin Deform POP |
Point Clouds
For our last stop, we’re going to take a look at differences in Point Cloud workflows between SOPs and POPs. Before the introduction of POPs, working with Point Clouds relied on the Point File In TOP and Point File Select TOP. These operators would allow 3D point data to be loaded into TOPs, which could then be used as instancing data for SOP geometry (in the example above, instances of a single SOP point are generated from the point data).
The problem with this approach was that while the point data can include a large number of channels, only four could be placed into the red, green, blue and alpha channels of the Point File In/Point File Select TOP texture at a time. So if you wanted to import XYZ position and RGB color data (as in the example above), you’d need a Point File In TOP and a Point File Select TOP to load the data. Any additional data would require more Point File Select TOPs.
Now, with the Point File In POP, this whole process has been significantly streamlined. The Point File In POP can load all available point data into POP attributes. In the above example, it automatically loaded XYZ point positions, Normals, and Color attributes. The geometry can then be rendered directly, or used as instancing data.
Another cool feature of the new operator is the ability to load Gaussian Splat files, which opens up another area of exploration for 3D scenes/rendering. When the file shown above is rendered, it looks like the image below.
Wrap Up
That’s a wrap! As usual, this is only the tip of the iceberg when it comes to the differences between the SOP and POP operator families. But that being said, we hope this has given you a better understanding of the basic differences between the two families. For more information, check out Derivative’s Learning About POPs documentation page, which has a section called “POPs vs SOPs” dedicated to the topic: https://docs.derivative.ca/Learning_About_POPs
