In this case, the customer reported that the Filter node didn’t seem to work consistently. In the scene I examined, it seemed to be a problem with the construction stack: for some reason, the ICE tree operator wasn’t being pulled (evaluated). Here’s a quick walkthrough of the investigation 😉

I looked a little deeper into this case, using GetConnectionStackInfo, and I found that somehow the ICETree operator was below the cluster ops:

// INFO : Objects that read from the primitive:
// matchstick.polymsh.secondaryshapemarker
// matchstick.polymsh.animationmarker
// matchstick.polymsh.shapemarker
// matchstick.polymsh.modelingmarker
// matchstick.polymsh.cls.pnt.clslist.Point.AddToClsOp
// matchstick.polymsh.cls.pnt.default_Point.SetClsFromICEOp
// matchstick.polymsh.Init_ICETree

If I created another ICETree op and moved it below (after) the original ICETree op, then the ICETree operator would have access to the cluster:

ApplyOp("ICETree", "matchstick.polymsh", siNode, null, null, 0);
MoveOperatorAfter("matchstick.polymsh", "matchstick.polymsh.Init_ICETree", "matchstick.polymsh.ICETree");
DeleteObj("matchstick.polymsh.ICETree");

// INFO : Objects that read from the Sphere primitive:
// matchstick.polymsh.secondaryshapemarker
// matchstick.polymsh.animationmarker
// matchstick.polymsh.shapemarker
// matchstick.polymsh.modelingmarker
// matchstick.polymsh.Init_ICETree
// matchstick.polymsh.cls.pnt.clslist.Point.AddToClsOp
// matchstick.polymsh.cls.pnt.default_Point.SetClsFromICEOp