Hello Ken,
no worries and thanks a lot for caring to answer!
1. This likely due to the overhead of spinning up a hython session. The ROP geometry is running out of process, whereas the geometry import node can depending on its setting, be running in process.
Understood. It would nice to have a toggle to set the Rop Geometry to work in-process, for those situations when you don't really need multi-threading, but only a fast output to disk of few workitems.
2. This is either a bug or due to the fact that PDG node does not exist until TOPs graph gets cooked in some way to generate it. If you do Tasks -> Generate Static Workitems, and try again - does it still happen? If so, it's a bug and please upload a scene. If not, then it's due the the previously mentioned artifact - PDG is kept separate from TOPs so it can be detached in the future from Houdini and deployed completely independently.
Yes, even when only generated, It still shows the behavior: a series of weird chars 0bZ 0bZ @dZ and then the aforementioned error code. I attached the scene
3. Yes, those functions require the unique ID of the workitem. Index is not enough because it is not unique.
Now I realize that @pdg_index is different than work_item.index! And It makes perfectly sense. So we have 3 types of indexing in TOPs.
Now, given a topnode name and a @pdg_index it should be possible to retrieve the unique ID. But how?
As I'm building a hda Sop wrapper around a topnet, my goal is to be able to use an integer parameter to display a specific pdg_index of a specific topnode (using the function setSelectedWorkItem(idx)).
It's like a remote control, because the user won't be able to dive inside the topnet to manually select the workitem dot on the topnode.
Even better, it would be handy to have a new type of parameter with the ‘dotted UI’ similar to the topnet nodes. I guess for now one could simply use a chain of unlabelled parameter toggles, that would spawn in accordance to the amount of workitems of the topnode of choice.
6. Only the invoke and geometry import can access the raw geometry at the moment.
What I meant is: when I select the topnet at sop level, I expected to see the raw geometry information displayed in the geometry spreadsheet. So I could append some sop nodes to the output connector of the the topnet network. Now it's only possible when the topnet save files to disk.
I tried to use the invoke top node, but with the ‘write geometry’ unchecked it won't output any geometry at sop level.
Also, what is the purpose of the output node inside TOPs?
It doesn't work like in a normal subnetwork: If I add a second output node, no second outputs connectors would be spawned on the topnet node.
It would be nice to have multiple outputs from a topnet. In case of topnet with separate branches that I want to output at Sop level, I can only use the force-recook button and manually set the render flag to the branch I want to see at sop level. If I need to see both branches, I should split them in two different topnets.
8. You can find it documented here: https://www.sidefx.com/docs/houdini/tops/pdg/PartitionHolder.html?origin_team=T045BRUUR [www.sidefx.com]
Oh thanks, I couldn't find it when I searched through the main page. I think it's not indexed in the menu
9. Likely a bug, we'll look into it further. Let us know if this is urgent, we'll try to look at it sooner in that case.
Not super urgent, but would be great if you could just check the
.hip file [
www.sidefx.com] and confirm that it's a bug and nothing due to my inexperience with PDG that could easily be fixed by applying the correct workflow.
Anyway, this issue, along with issue 1) and issue 6) are somehow correlated in my scenario.
My goal is: output at Sop level some points with per-point pdg attributes created inside the topnet. It's very light task, no geo manipulation, only pdg attributes handling and assigning to geo.
Super ideal for me would be being able to do 6): read at Sop level the Raw Geometry from the topnet output, without wasting time in writing it first to disk and then re-import it.
Since it's not possible, I tried to use the Rop Geometry Output, and here it comes issue 1), the slowness of out-process writing to disk.
So I tried to use the faster in-process GeometryImport saving capabilities, but issue 9) will make the geoimport node write pdg attributes with fixed values on points.
As of now I can only use Rop Geometry Output, which is a no go.
In my scenario the user of my Digital Asset needs to play with some parameters of the hda, every parameter change would trigger a fast in-process cooking in the topnet, whose output (points with specific attribute values) is to be visualized in the Viewport. This workflow needs some fast feedback from the topnet as the user changes parameters.
I guess it's wiser to try to port all the attributes creation task at SOP level, and I will use TOPs for the very last part when the actual render happens.
Thanks again!