TouchDesigner has organized geometry, data, and image processing into the same handful of operator families — SOPs, CHOPs, TOPs, DATs — for well over a decade. That list just grew for the first time in more than ten years, with the addition of POPs: Point Operators, a GPU-native family built specifically for points, polygons, point clouds, particles, and line strips.
Watch: What Are POPs? The New TouchDesigner Operator Family (YouTube)
Why a new family instead of just faster SOPs
SOPs — TouchDesigner’s existing geometry operators — run on the CPU. That’s been a hard ceiling for a long time: complex particle systems, dense point clouds, and heavy procedural geometry work all eventually hit a wall that no amount of optimization inside the CPU-bound SOP family could fix. POPs sidestep that ceiling entirely by running as highly parallelized compute shaders directly on the GPU, borrowing the procedural logic that makes SOPs approachable while inheriting the performance characteristics of CHOPs and TOPs. Derivative is positioning it as a genuine step change rather than an incremental update — the kind of addition that reshapes what’s practical to attempt in real time, not just what runs a bit faster.
What they actually handle
POPs work with points and primitives — triangles, quads, lines — the same conceptual building blocks as SOPs, but built for scale: point clouds and particle systems that would bog down a CPU-based pipeline. They can import FBX, OBJ, and Alembic files directly, and a File Out POP supports exporting geometry and point sequences to formats including .obj, .exr, .ply, .e57, and — notably — .spz, a compressed Gaussian splat format. Given how quickly Gaussian splats have become the default representation for photorealistic captured geometry across the industry this year, native export support in a tool as widely used as TouchDesigner is a meaningful interoperability point, not a niche feature.
POPs also render alongside existing geometry: they work with a Geometry COMP and Render TOP the same way SOPs do, and the two families can be mixed in a single render pass — so adopting POPs doesn’t mean rebuilding an existing project’s geometry pipeline from scratch.
Where this leaves SOPs
Derivative isn’t deprecating SOPs — the two families are explicitly designed to coexist, with POPs aimed at the workloads that actually need GPU-scale parallelism. For most existing projects, that means POPs are worth reaching for specifically when a particle system or point-cloud operation starts to strain, rather than a wholesale replacement for how geometry gets built.