Unlike the SOP and ROP Geometry nodes, the TOP Geometry node doesn't seem to have a Pre/Post-Render script function on the mode. Is that done on purpose, and is that something that will be incorporated later on? It is something that would be nice to have.

TOPs currently makes use of the pre/post callbacks itself, which is why they're not exposed on the TOP nodes. This is something we intend to fix, though.

There is also a Python Script TOP node which generates work items that run user-defined Python code. If you wire a ROP Geometry TOP into a Python Script TOP, the script node will create one work item for each item in the ROP Geometry TOP. You can use this to run post frame logic, for example.

Okay thanks, I was thinking I could do that in python.

This is a little unrelated,but how does TOPs determines the number of jobs to run concurrently? I have lots of jobs able to run, and its picking about 3-6 to run at the same time, though I know it could be running more because the dependencies are open. Is it based on CPU usage or something along those lines?

Tyler Britton2
This is a little unrelated,but how does TOPs determines the number of jobs to run concurrently? I have lots of jobs able to run, and its picking about 3-6 to run at the same time, though I know it could be running more because the dependencies are open. Is it based on CPU usage or something along those lines?

Hi, I answered this here: https://www.sidefx.com/forum/topic/61771/ [www.sidefx.com]

It looks like you can only reliably create post dependent functions using the script top. Any pre script function should only cook if the main work item is going to cook. Is there a way to trigger pre script work items only in the event that downstream items are going to cook?

When can we expect to see the pre/post callbacks functionality for TOP?

Our pipeline requires files to be deleted before writing, therefore we're trying to look for a clean way to delete the expected result data of a ROP Fetch on a per-frame basis and ideally right before writing, which would have been easy with the “Pre-frame Script” back with ROP nodes.

In the meantime, we've been unsuccessful in trying to come up with a robust temporary solution:

• We've tried using standard TOP nodes to remove the files, however can't seem to get a dependency graph that can achieve the pre-frame behavior.
  
• We've tried using the Event Handler to add a callback when work item state goes from waiting -> scheduled. However, this doesn't seem reliable enough especially once we start dealing with batched work items.
  
• We're thinking of recreating our own ROP Fetch to reimplement the onPrepareTask callback, however given how complicated the ROP Fetch node is, it will require a lot of dev time to recreate ROP Fetch solely for this purpose. Thus we're reluctant to go down this route.
  

It feels like the cleanest way would be to have a hook to onPrepareTask to allow for the pre-frame logic?

Thanks,

Wayne W.

My approach to this currently is to replace code in the onscheduled call back, or also the onpresubmit method (which can be patched in the localscheduler).

onscheduled is the right place since we only want to do those operations if the work item will cook.

This is also the best place to handle asset creation and auto versioning, setting up paths etc, since we only want to do that when an item will cook, but before it executes.

Thinking out aloud, you might also append another script command and alter the actual work item command to execute your initial python script for cleanup/deletion before the main payload runs too. I would do this if the pre frame operation is slow and can run in parallel. you may wish for it to run on the same worker.

If its a fast operation, and must be sequential, or must run before submission, then I would prefer running out during the onscheduled callback.

The onscheduled callback is also the only appropriate place to set parms in your hou session as well (like versions).

Also keep in mind that if files exist at the result location, no cooking will occur at all, unless items upstream cook. so you would probably have to make sure that you will cleanup the target location first, or use the delete outputs from disk in the menu, or increment a version to force a cook.

Just a heads up that in latest 18.0 build, the pre/post frame hooks will work as expected even for ROP Fetch nodes set to batch mode. The PDG job script that cooks the ROP now ensures that any custom scripts are preserved, rather than blindly overwriting them with the pre/post hook that PDG uses for controlling batches. The scripts are evaluated during the regular ROP cooking process, so they run as part of the out of process/farm job, not in the Houdini session that's cooking the TOP network.

The various script hook parms have also been promoted to a tab on the parms interfaces of the ROP Geometry, ROP Mantra, ROP Composite, etc.

Awesome @tpetrick !

That's really excellent news! Thanks for making these changes.