C++ SDK Missing: Pattern Resolution API, getPOP(), appendPOP()

C++ SDK - Pattern Matching Support for Operator Parameters

Is there any way in the C++ SDK to access all operators resolved from a pattern parameter? Native operators like Render TOP support pattern matching (e.g., geo* resolves to geo1, geo2, geo3), but I can’t find any API to replicate this in custom operators.

Missing API:

Looking at CPlusPlus_Common.h, there’s no way to:

  1. Get the count of resolved operators from a pattern
  2. Iterate through all resolved matches

All getParX() methods return only a single operator.

Additional POP-Specific Gaps:

POPs are missing get/append methods that exist for every other operator family:

// These exist for SOP/TOP/CHOP/DAT/Object:
virtual const OP_SOPInput* getSOP(const char* path) const = 0;
virtual OP_ParAppendResult appendSOP(const OP_StringParameter &sp) = 0;

// These are missing for POPs:
virtual const OP_POPInput* getPOP(const char* path) const = 0;
virtual OP_ParAppendResult appendPOP(const OP_StringParameter &sp) = 0;

Without getPOP(path), even DAT workarounds don’t work since there’s no way to convert a path string to a POP input.

Without appendPOP(), you’re forced to use appendOP() which accepts any operator type instead of restricting to POPs only.

Questions:

  1. Am I missing something, or is pattern resolution not exposed to C++ plugins?
  2. Any workarounds besides creating multiple individual parameters or Python/DAT bridges?

Proposed API:

// Pattern resolution for all operator types:
virtual int32_t getParResolvedCount(const char* paramName) const = 0;
virtual const char* getParResolvedPath(const char* paramName, int32_t index) const = 0;

// Complete POP API parity:
virtual const OP_POPInput* getPOP(const char* path) const = 0;
virtual OP_ParAppendResult appendPOP(const OP_StringParameter &sp) = 0;

TD Version: 2025.32050

1 Like

+1 - I’m running into the same limitation.

I also need to feed geometry from POP networks into a custom CPlusPlus operator (ideally CPlusPlus TOP, CUDA mode), including not just point attributes but primitive/vertex topology (triangle indices) when the geometry changes dynamically.

Right now the only workable paths are:

  • POP → POP to TOP texture encoding/decoding, or

  • POP → SOP/CHOP/DAT conversions (often involving CPU readback / latency),

which adds complexity and overhead compared to the SOP/TOP/CHOP/DAT parity you already have in OP_Inputs.

Having an official appendPOP() + OP_Inputs::getPOP() (or equivalent) would make this workflow much cleaner. A CUDA/interop-friendly path would be ideal, but even CPU-access to POP points/prims/verts would already be a big step forward.

Thanks for considering this!

Hey @choy and @Artgrigorov1995 ,

Thanks for the suggestions. A workflow for multi OP parameter support is already on our list, and should be added soon.

The missing POP parameter features will be added soon as well.

Varad

1 Like