Taylor Petrick

tpetrick

About Me

Expertise
Not Specified
Location
Canada
Website

Connect

My Tutorials

obj-image Quick Tips
Work Item Attributes

Recent Forum Posts

TOPS/ROPNET/OpenGL errors Dec. 3, 2020, 10:27 p.m.

That error log indicates that the OpenGL ROP itself is crashing while it's cooking. There are errors regarding an invalid OpenCL device that occur before that well, however I don't know if that's related.

Since you're cooking the work item as batches, all of the frames for each wedge are running in a single Houdini process. That means that if the process crashes, any subsequent frames that haven't finish will be marked as failed.

You may want to try limiting the number of concurrent work items for that particular node to see if it resolves the crash. Right now your graph is running all 4 OpenGL batches at the same time, however I noticed those jobs are each consuming 1GB of GPU memory. You can force PDG to only run on batch at time by setting the “Single” job parm through the scheduler options, or alternatively use the “Slots per Work Item” job parameter along with the “Total Slots” parameter on the scheduler itself. More details on setting per-node scheduler parameter be found here: https://www.sidefx.com/docs/houdini/tops/schedulers.html#jobparms [www.sidefx.com]

TOPS/ROPNET/OpenGL errors Dec. 2, 2020, 3:43 p.m.

The messages about cache file paths are not errors – they're warnings that indicate the cache file path does not match the file reported by the job. They won't cause the work items to fail to cook and only affect caching behavior.

If there are work item failures you can use Ctrl+Middle Mouse click on the failed item to see its output log. Any work item errors will be reported there. Your file works fine for me if I change the output path. What version of Houdini are you using, and on which platform?

TOPS/ROPNET/OpenGL errors Dec. 2, 2020, 10:44 a.m.

The output file path on your OpenGL ROP should be visc.`@wedgeindex`.`@visco`.$F4.pnginstead of visc.`@wedgeindex`.$visco.$F4.png. PDG will evaluate that parameter when create work items, in order to determine where the work items are going to write their output files for caching purposes. You need to use @visco to access that work item attribute.