Hi all,
First time using PDG here. I've been fumbling around trying to get this to work, but with time pressures being what they are I'd really appreciate any insight.
See attached image in which I'm using a filepattern to get files from disk, those are then read in the python ‘Initalize’ SOP, in which a detail attribute is set to the number of animation frames. I somehow need to get those number of frames back to PDG so that it can set the FEND environment variable or a PDG attribute that I can use inside my ROP network.
Setting Environment Variable from Detail Attribute?
6457 17 2
-
- Anti-Distinctlyminty
- Member
- 271 posts
- Joined: 3月 2012
- Offline
-
- Anti-Distinctlyminty
- Member
- 271 posts
- Joined: 3月 2012
- Offline
-
- tpetrick
- スタッフ
- 600 posts
- Joined: 5月 2014
- Offline
Your Geometry Import set up looks correct. Can you try moving your TOP network outside of the SOP network, e.g. putting your TOP Network into /obj instead of /obj/geo1? When used within a SOP network, the TOP net actually becomes part of the SOP cook so it could be that there's a bug with the geometry import + exporting attributes in that case.
-
- Anti-Distinctlyminty
- Member
- 271 posts
- Joined: 3月 2012
- Offline
That seems to help. I don't get a freeze any more.
When I import attributes from the geometry import TOP, can I just refer to them via the @attribute syntax in the ROP Fetch? (and the MDD Point Cache Driver I have in my ropnet?)
I can't seem to get the MDD Point Cache Driver's to pick up the correct frame range (I assume this is the problem, as it's erroring out currently, but only after significant writing).
When I import attributes from the geometry import TOP, can I just refer to them via the @attribute syntax in the ROP Fetch? (and the MDD Point Cache Driver I have in my ropnet?)
I can't seem to get the MDD Point Cache Driver's to pick up the correct frame range (I assume this is the problem, as it's erroring out currently, but only after significant writing).
Edited by Anti-Distinctlyminty - 2019年8月9日 12:01:59
-
- tpetrick
- スタッフ
- 600 posts
- Joined: 5月 2014
- Offline
Yep, you should be able to refer to the attributes in expressions on the ROP Fetch. In your case, you should be able to set the ROP Fetch's start frame to 1 and end frame to @frames. The ROP Fetch will cook the target ROP (your MDD Point Cache) with whatever frame range you specify on the ROP Fetch itself.
Edited by tpetrick - 2019年8月9日 12:16:56
-
- nymus
- Member
- 33 posts
- Joined: 6月 2019
- Offline
-
- Anti-Distinctlyminty
- Member
- 271 posts
- Joined: 3月 2012
- Offline
-
- Anti-Distinctlyminty
- Member
- 271 posts
- Joined: 3月 2012
- Offline
Ok, I've refined this down to the attached hip file.
The python node /obj/geo1/Initalize is set to read in some data from a csv file, that you will find in $HIP/csv.
In /obj/topnet1 there is a setup that reads files from that directory, localizes that path, then tried to read in the detail attribute ‘frames’ from the aforementioned pyhon node /obj/geo1/Initalize.
Now, this node just errors, saying: SOP Node source type can only be used when generating static work items when it's set to automatic. When I set it to static generation, as is the case with the hip file, it just freezes Houdini. See the attached gif.
The python node /obj/geo1/Initalize is set to read in some data from a csv file, that you will find in $HIP/csv.
In /obj/topnet1 there is a setup that reads files from that directory, localizes that path, then tried to read in the detail attribute ‘frames’ from the aforementioned pyhon node /obj/geo1/Initalize.
Now, this node just errors, saying: SOP Node source type can only be used when generating static work items when it's set to automatic. When I set it to static generation, as is the case with the hip file, it just freezes Houdini. See the attached gif.
-
- chrispriscott
- Member
- 4 posts
- Joined: 5月 2010
- Offline
I've also come across the same issue with Houdini freezing in TOPS and narrowed it down to the attached scene and an interaction with the Python SOP.
In the attached scene I’ve got a simple wedge that changes the sub divs on a box at SOP Level and a Geometry Import TOP node that should read the results of this. However, everytime I run the TOPs network with the local scheduler Houdini hangs and I have to force kill it.
The Python SOP has only the default code but something here looks to be causing the issue as when I bypass the Python SOP the TOPS networks cooks successfully. It also works if I toggle off ‘Evaluate with Work item attributes’ but in our use case we need this on. Removing all the default code from the Python SOP also seems to fix the issue (but has obvious limitations).
I've logged the bug with Support (ID# 98564) but no workaround or ETA for a fix yet. @tpetric - Are you able to provide an update at all?
In the attached scene I’ve got a simple wedge that changes the sub divs on a box at SOP Level and a Geometry Import TOP node that should read the results of this. However, everytime I run the TOPs network with the local scheduler Houdini hangs and I have to force kill it.
The Python SOP has only the default code but something here looks to be causing the issue as when I bypass the Python SOP the TOPS networks cooks successfully. It also works if I toggle off ‘Evaluate with Work item attributes’ but in our use case we need this on. Removing all the default code from the Python SOP also seems to fix the issue (but has obvious limitations).
I've logged the bug with Support (ID# 98564) but no workaround or ETA for a fix yet. @tpetric - Are you able to provide an update at all?
-
- tpetrick
- スタッフ
- 600 posts
- Joined: 5月 2014
- Offline
A couple of things:
- You don't need to manually localize the path. On your Python SOP, you can use `pdginput(0, “”, 1)` as your expression instead, since the File Pattern reports the globbed files as outputs. The arguments to that function are the input file index, the file type tag to filter by, and a flag that indicates if the file should be localized or not.
- The error message is correct - we're currently only able to import geometry from SOPs if the node is generating work items statically. This is because importing from SOPs may require the SOP node to be cooked, and dynamic items are created in parallel/off the main thread.
- I was able to repro your issue and I'll look into getting a fix for it today. In the mean time, you can use a ROP Geometry instead to cook the target geometry out-of-process. It'll be a bit slower, but it avoids the deadlock that's happening between the TOP node and cooking the Python SOP. I've attached an example file with the suggested changes.
-
- tpetrick
- スタッフ
- 600 posts
- Joined: 5月 2014
- Offline
-
- chrispriscott
- Member
- 4 posts
- Joined: 5月 2010
- Offline
-
- Anti-Distinctlyminty
- Member
- 271 posts
- Joined: 3月 2012
- Offline
-
- Anti-Distinctlyminty
- Member
- 271 posts
- Joined: 3月 2012
- Offline
-
- Anti-Distinctlyminty
- Member
- 271 posts
- Joined: 3月 2012
- Offline
Just coming back to this and trying to wrap my head around things and I noticed that the documentation is a little wonky. Current version of the docs for pdginput [www.sidefx.com] state that we have three arguments;
index, tagand localize. But in the detailed explanation of those arguments it lists; name, indexand localize
-
- Anti-Distinctlyminty
- Member
- 271 posts
- Joined: 3月 2012
- Offline
Soooo, I'm not entirely clear on the workflow here…(I appreciate that I may be jumping in the at the deep end here)
In the supplied TOPs_GeoImport_Fixed.hip is it essential to write the geo to disk? I know that memory shouldn't really be an issue, so I am just using a File Pattern TOP and Geometry Import TOP, and in /obj/geo1/Initalize the file path is set to
So, my main questions are…
In the supplied TOPs_GeoImport_Fixed.hip is it essential to write the geo to disk? I know that memory shouldn't really be an issue, so I am just using a File Pattern TOP and Geometry Import TOP, and in /obj/geo1/Initalize the file path is set to
`pdginput(@index, "", 1)`. So, my main questions are…
- Does this setup doing anything dangerously stupid?
- Is
pdginputa function that somehow knows what files a particular TOP node has input/output depending on when the expression is called in the evaluation chain?
Edited by Anti-Distinctlyminty - 2019年9月16日 10:23:46
-
- tpetrick
- スタッフ
- 600 posts
- Joined: 5月 2014
- Offline
The pdginput function is a long form version of the @pdg_input attribute accessor. Both work in the same way, but the function allows you pass additional arguments not possible for the @accessor. Both will expand to an input file from the upstream work item.
In general, the @accessors and pdg HScript functions are evaluated per-work item. For example, if you have a Generic Generator node with a Count of 10, and a Frame parameter of @pdg_index*2 + 1, that expression will be evaluated for each of the 10 work items produced by the node. Each time @pdg_index will be different, since the “active” item for the evaluation will changed. The generic generator in that case effectively does:
The same is true for pretty much all nodes and usage of the @ operator to access data. Evaluations of expressions on node parameters happen per-work item, and any work item data accesses apply to the work item being evaluated against.
@pdg_input provides direct access to the input files to the particular work item, shown as “Inputs” in the middle mouse button menu for that work item. E.g. @pdg_input.2 accesses the second file in the list. It's often useful to filter by the file tag, though. For example pdginput(0, “file/geo”, 0) accesses the first input file with the “file/geo” tag assigned to it. The third argument to that function, “localize”, is if you want to force PDG to return a local path to the file instead of a more generic path like __PDG_DIR_/geo/out.bgeo.sc. The generic paths are mostly used for farm support, since paths on different farm machines or between the farm/local machine can be different, and a common path format is needed.
In general, the @accessors and pdg HScript functions are evaluated per-work item. For example, if you have a Generic Generator node with a Count of 10, and a Frame parameter of @pdg_index*2 + 1, that expression will be evaluated for each of the 10 work items produced by the node. Each time @pdg_index will be different, since the “active” item for the evaluation will changed. The generic generator in that case effectively does:
for i in xrange(0,10): item = new_work_item() item.makeActive() frame = self['frame'].evaluate() item.setFrame(frame);
The same is true for pretty much all nodes and usage of the @ operator to access data. Evaluations of expressions on node parameters happen per-work item, and any work item data accesses apply to the work item being evaluated against.
@pdg_input provides direct access to the input files to the particular work item, shown as “Inputs” in the middle mouse button menu for that work item. E.g. @pdg_input.2 accesses the second file in the list. It's often useful to filter by the file tag, though. For example pdginput(0, “file/geo”, 0) accesses the first input file with the “file/geo” tag assigned to it. The third argument to that function, “localize”, is if you want to force PDG to return a local path to the file instead of a more generic path like __PDG_DIR_/geo/out.bgeo.sc. The generic paths are mostly used for farm support, since paths on different farm machines or between the farm/local machine can be different, and a common path format is needed.
-
- tpetrick
- スタッフ
- 600 posts
- Joined: 5月 2014
- Offline
With regard to your question about your file, that should be fine. When the “Evaluate Work Item Attributes” toggle is set, it basically means that the active work item should be set each time the geometry tries to pull in geometry. This will cause the `pdginput` function to evaluate against that item in your Python SOP. Note that index argument to `pdginput` isn't the work item index, but the index within the input file list. I think in your case you can just use 0, since each work item produced by the File Pattern will only have one file, so each geometry import item will only have a single input file.
-
- Quick Links