Taylor Petrick


About Me

Not Specified


My Tutorials

obj-image Intermediate
PDG Partitioner Nodes
obj-image Quick Tips
Work Item Attributes

Recent Forum Posts

Create wedge numbers based on upstream wedge item April 30, 2021, 11:53 a.m.

You should use a Geometry Import to fetch the geometry you want, instead of the npoint expression function. That node will store the number of points in the geometry to a work item attribute, which you can then reference in the wedge count parameter. On the Geometry Import there's a toggle to enable "Evaluate with Work Item Attributes" -- you'll also want to enable that, since that's what tells the node to recook the source geometry for each input work item, instead of just cooking it once.

Adding a new wedge April 6, 2021, 5:43 p.m.

If the Cache Mode parameter on the ROP Fetch TOP node is set to Automatic, the work items will pick up existing cache files on disk assuming they haven't been invalidated for other reasons (such as upstream work items writing out new outputs). Work items that cook from cache are marked as cooked immediately, and won't actually be scheduled for cooking.

ERROR: when batching is enabled April 6, 2021, 5:39 p.m.

In order for batch work items to cook properly, they need to be able to set a pre-frame and post-frame script hook on the ROP that's being cooked. This is because PDG needs to know about each frame that finishes for status/output file reporting, and needs to be able to set the active work item for the process before a frame begins so that @attributes evaluate properly. Consequently, batching can only be used if the ROP Fetch node is pointed to a ROP that has pre/post frame script parms on it. This isn't an issue for unbatched frames because each worker process corresponds to a single work item.

If possible, you should point your ROP Fetch to the node inside of the ROP network that you're actually trying to cook. If you need batching because the work item is a simulation, you can also use the "Cook Frames as Single Work Item" toggle. That will cook the full frame range in one Houdini process, but doesn't require the pre/post frame hooks because the entire frame range is cooked as a single work item instead of as a batch. It does mean that all frames of work will be done in that single work item, though, without fine grained progress updates.

I can take a look on our end to see if we can work around the limitation so it can at least cook, but without having access to a post-frame hook the ROP Fetch worker script won't be able to report per-frame progress.