ROP Fetch external hip files? (╯°□°)╯︵ ┻━┻

   2475   8   0
User Avatar
Member
339 posts
Joined: June 2013
Offline
I was using a Python Script (Out-Of-Process mode) to execute some ROPs in an external scene file but... that does not synchronize well with the rest of the dependency graph, so, I'm trying ROP Fetch now. Is there a nice example of using _ROP Fetch_ with external hip files?

I've setup a hip string file with the path to the hip I want to use but get an error like the one in the image:
AttributeError: 'NoneType' object has no attribute 'path'

Scene File attached.
Reproduction. Generate and cook the TOP /obj/topnet1/ropfetch1
A) Item name selector is changed and the scene is saved to a copy. Each scene when opened only shows the corresponding item. This is working.
B) ROP Fetch: Render each scene's opengl ROP. This is failing.


I don't know what the nodes is expecting apparently the hip attribute and the rop path in the parameter are not enough.
Edited by probiner - Dec. 9, 2021 10:57:50

Attachments:
ExternalROP.hiplc (187.6 KB)

User Avatar
Staff
586 posts
Joined: May 2014
Offline
The "hip" attribute needs to be a file-type attribute, not a string attribute. Your Python Script is setting it as a string attribute, which is preventing the ROP Fetch itself from loading it properly when it goes to cook. The best way to do this is to store your custom file path string in a different attribute, and then reference it in by enabling the "External HIP File" parm on the ROP Fetch. For example, by setting that parm to @custom_hip, or whatever you've named your custom path attribute. That way the ROP Fetch a) configures the attribute properly and also b) expects to cook an external .hip file, instead of the current one.
Edited by tpetrick - Dec. 9, 2021 10:58:52
User Avatar
Member
339 posts
Joined: June 2013
Offline
tpetrick
he "hip" attribute needs to be a file-type attribute, not a string attribute.
Ah, the docs [www.sidefx.com] do say string. I did try to set hip as a file as well but when inspecting the ROP Fetch log, the current scene file is still the loaded and hip attribute update also reflects that.


The usage of the `@path_to_hip`did work correctly. Thanks. But I guess I'm now curious about "the correct way" with File Attribute file/hip way.

I've attached an updated scene file.

I'm probably missing on some concepts of TOPs to be able to be creative with them. Let me know if you recall a place that breaks them down and demonstrates them in a succinct way beyond the docs. And by the way, since docs [www.sidefx.com] don't mention, what is the color code in the Work Item Info Window(Blue, Purple, Green, Yellow)? Attribute subtypes?

Thank you again for the help in this dive-in!
Cheers
Edited by probiner - Dec. 9, 2021 13:16:29

Attachments:
ExternalROP.hiplc (197.9 KB)

User Avatar
Staff
586 posts
Joined: May 2014
Offline
The Attribute Create approach in your new file will not work because "External HIP File" is still disabled on the ROP Fetch. When that toggle is off, the ROP Fetch will explicitly set the "hip" attribute to the path to the current scene file. It doesn't matter if you set it to a custom file path before hand -- the ROP Fetch will overwrite it because the parms on that node indicate that it should create work items that use the current file. The reason that wasn't happening in the first file is that there was a type mismatch, and the ROP Fetch implementation doesn't force the attribute type to update.

Green attributes are integers, yellow are floats, and magenta are strings. Anything that shows up in blue with an underline is a clickable link, like in a web browser. File attributes are string attributes that store additional meta data like a data type tag (such as a "file/hip"), the mod time/size of the file, and support path localization using PDG's path mapping so they load properly on different platforms.
Edited by tpetrick - Dec. 9, 2021 13:28:30
User Avatar
Member
339 posts
Joined: June 2013
Offline
tpetrick
The Attribute Create approach in your new file will not work because "External HIP File" is still disabled on the ROP Fetch. When that toggle is off, the ROP Fetch will explicitly set the "hip" attribute to the path to the current scene file. It doesn't matter if you set it to a custom file path before hand -- the ROP Fetch will overwrite it because the parms on that node indicate that it should create work items that use the current file. The reason that wasn't happening in the first file is that there was a type mismatch, and the ROP Fetch implementation doesn't force the attribute type to update.

Maybe I'm misreading the docs. When it says "top attributes" I considered that I could override them. Or the docs are just stating the output attributes?
Like in some SOP I was indeed expecting the presence of the file attribute hip to override the UI options or the necessity to mention it. Does this override happen at all?. I did try to turn the "External HIP File" option on. But now it complains that the field cannot be empty. When I put `@hip` there, all works.


tpetrick
Green attributes are integers, yellow are floats, and magenta are strings. Anything that shows up in blue with an underline is a clickable link, like in a web browser. File attributes are string attributes that store additional meta data like a data type tag (such as a "file/hip"), the mod time/size of the file, and support path localization using PDG's path mapping so they load properly on different platforms.

Thank you for the thorough breakdown.

Cheers
User Avatar
Staff
586 posts
Joined: May 2014
Offline
The attributes in the docs specify what attributes the node will set on work items that it creates. Generally speaking, nodes will always overwrite those attributes with values based on their parm configuration. The exception are nodes like Attribute Create or Environment Edit, which have parameter that you can set to controls what happens when a type conflict occurs or when an attribute already exists.
Edited by tpetrick - Dec. 9, 2021 14:36:58
User Avatar
Member
339 posts
Joined: June 2013
Offline
tpetrick
The attributes in the docs specify what attributes the node will set on work items that it creates. Generally speaking, nodes will always overwrite those attributes with values based on their parm configuration. The exception are nodes like Attribute Create or Environment Edit, which have parameter that you can set to controls what happens when a type conflict occurs or when an attribute already exists.

Gotcha, so my expectations lead me astray! One last noe for today. Is it advised against Fetching a Merge ROP? I do keep getting a warning about an inexsisting output Unable to find output parm for /obj/ropnet1/ogl_merge. I guess I could have as ROP Fetch per input on the Merge ROP and then merge myself the outs directly in TOP? I was just wondering if I'm trading off having an overhead (loading more houdini processes?) in order to have a more top friendly behavior (outputs of each ogl render being passed to TOPs).

Thanks again
Edited by probiner - Dec. 9, 2021 15:16:39

Attachments:
ExternalROP.hiplc (251.1 KB)

User Avatar
Staff
586 posts
Joined: May 2014
Offline
The ROP Fetch node looks for parms on the ROP that define output files so that it can report those files back to PDG. When a node doesn't have any output parms that often indicates an issue with the set up, hence the warning.

The Merge ROP doesn't have any output file parms so the PDG job warns you about potentially cooking an invalid ROP. The ROP Fetch supports cooking all leaf ROPs in a given network, so one option that may work for you is to remove the Merge and point the ROP Fetch at the network instead.
User Avatar
Member
339 posts
Joined: June 2013
Offline
tpetrick
The ROP Fetch node looks for parms on the ROP that define output files so that it can report those files back to PDG. When a node doesn't have any output parms that often indicates an issue with the set up, hence the warning.

The Merge ROP doesn't have any output file parms so the PDG job warns you about potentially cooking an invalid ROP. The ROP Fetch supports cooking all leaf ROPs in a given network, so one option that may work for you is to remove the Merge and point the ROP Fetch at the network instead.

Ah! I did try to insert a list of ROPs like one would with SOPs on an Object Merge, but that didn't work. Referencing the parent ROP does work. Thanks!

This concludes much of my table flipping

Cheers
Edited by probiner - Dec. 10, 2021 15:03:36
  • Quick Links