OP_POPInput identification fields not populated by getParPOP()

Bugs
1

OP_Inputs::getParPOP() returns a valid OP_POPInput* but all identification fields are uninitialized:

const OP_POPInput* popInput = inputs->getParPOP();

// All return null/zero despite valid connection:
popInput->opPath; // null
popInput->opId; // 0
popInput->totalCooks; // 0
popInput->customOP; // nullptr

Data access methods work correctly - getNumAttributes() returns proper counts, confirming the POP connection is valid. Only the identification fields are unpopulated.

OP_CustomOPInstance

The customOP field should provide access to Custom Operator POP instances:

if (popInput->customOP) { // Always nullptr
POP_CPlusPlusBase* instance = popInput->customOP->instance;
const char* opType = popInput->customOP->opType;
}

This prevents accessing Custom Operator POP classes directly from other operators.

Request

Populate OP_POPInput::opId, opPath, totalCooks, and customOP when the parameter references a valid POP, and populate OP_CustomOPInstance<POP_CPlusPlusBase> with valid instance, opType, and version fields when the referenced POP is a Custom Operator.

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

3

While investigating the above issue, I discovered a related problem: OP_NodeInfo for POP operators contains garbage data

// In POP’s getInfoDATEntries():
entries->values[1]->setString(m_nodeInfo->opPath ? m_nodeInfo->opPath : “(null)”);

Expected: Valid operator path (e.g., /project1/mypop1)
Actual: Unrelated garbage string from memory

This occurs whether reading during execute() or getInfoDATEntries() - both return the same garbage value.

POPs appear to have systemic identification issues:

  1. OP_POPInput from getParPOP() has null/zero fields
  2. OP_NodeInfo passed to POP constructor contains garbage
5

Hey @choy

Thanks for reporting these. I am able to reproduce the issue with OP_POPInput not being filled. Have logged it in for someone to have a look soon.

I am unable to reproduce the issue with OP_NodeInfo containing garbage data, It seems to have the correct data in the case I’m looking at. Can you share a reproducible case for us to look at.

Thanks,

Varad

1 Like
6

The issue with getParPOP/getInputPOP() not having all of the information filled in will be fixed in the builds 2025.32204+. Thanks for the report

1 Like
7

Hey @varad @malcolm - Thanks for looking into this…

Bug: OP_NodeInfo - opPath and opId contain incorrect data for POP operators after project save/reload.

To reproduce, modify the SDK CudaPOP example to output OP_NodeInfo members in getInfoDATEntries():

case 0:
entries->values[0]->setString(“opPath”);
entries->values[1]->setString(myNodeInfo->opPath ? myNodeInfo->opPath : “(null)”);
break;
case 1:
entries->values[0]->setString(“opId”);
snprintf(tempBuffer, sizeof(tempBuffer), “%u”, myNodeInfo->opId);
entries->values[1]->setString(tempBuffer);
break;

  1. Create a Cudasample POP with geometry input
  2. Attach Info DAT → shows valid data (e.g., opPath=“/Cudasample1”, opId=47092)
  3. Save project, close TD, reopen
  4. Info DAT now shows wrong data (e.g., opPath=“lib”, opId=9345)

After the first reload, values stay consistent (always “lib”/9345).

8

Hey @choy ,

Thanks for the case, I’m able to reproduce. This has been logged for someone to look at.

Varad

1 Like