Hi. I'm trying to drive the frame range inside a rop fetch TOP node with expressions, it seems that it's not possible yet?

My .hip setup is like this: I have a template mocap rig (subnet) that gets its animations from a chopnet. The chopnet loads a FBX file from disk (fbx node). There's also a topnet that would serve as batch processor for reading/modifying/exporting all animations inside a folder.

My pdg graph has only 2 nodes: file pattern > rop fetch, and I wanted the end frame of the rop fetch node to be set to the length of each animation(workitem), so my initial guess was reading the length of the chop fbx input node with chopl(“path/to/node”)

While this seems to work on the UI (when previewing different workitems), all the exported animations get the same frame range when I cook the rop fetch node.

I also tried to read the animation length from a geometry node, store it as detail attribute, and query that back inside pdg using geometry import, but that crashes houdini.

What is the proper way to do this ?

thanks

I'm running into what I think is exactly the same thing (unsurprisingly as I'm also trying to process mocap).

As fabriciochamon said, while the clicking through the work items the attribute gets evaluated correctly on the attribute create, however when if I look at value on the actual work item they all get set to same value. So the question seems to be how to bind the attribute to the individual work item correctly?

Attached an example file; perhaps there's a better way of approaching this, or I'm just plain doing something wrong

The workflow described in Jujoje's file is currently not possible. That would required the CHOP network to be reevaluated for each work item in the attribute create during the PDG cook. Doing so isn't always safe/possible since PDG graphs evaluate asyncronously and in parallel. In this specific case I think it would actually be fine to trigger evaluation of the CHOP network, though - I'll look into adding in an option to make that possible, but it'll have to be something that you manually opt-in to via a parm on the node.

It is possible to have dynamic, data-driven frame ranges on the ROP Fetch node itself. I've attached an example, but that's different than the attribute create issue.

Hi Taylor, thanks for looking into that. Not sure if we are talking the same here, but I think the problem is that the animation end frame is not known until we load the fbx file, so the “endFrame” attribute must be dynamically created. In tops, I tried using a geometry import node to query a sop geo that has a detail attribute created with chopl() expression, and although the value changes inside the sop attribute, it does not update in the workitem. I didn't have a look at jujoe's scene, but might be the same case?

Here's a simple scene attached. Inside the zip you have a .hip + 2 fbx mocap files. if you cook the filepattern node on the topnet you can select each workitem and see the animation playing(both animations are the same, I only changed end frames. So mocap_1.fbx ends at frame 90, mocap_2.fbx ends at 24). Now if you cook the geometry import node, you can see the workitems' “endFrame” value are always the same, while the attribute inside “read_animation_end_frame” geo container updates.

hope that makes sense, I'm just diving into pdg so bare with me.

Hi, sorry to bring this old topic back again.. months later and I'm still struggling with this. What is the proper way to have a dynamic frame range (different for each work item) inside a PDG graph ? The example usecase would be the same from intial post: say you have a bunch of mocap files inside a folder, I want to load/process(in chops)/export all of them, each one with its corresponding frame ranges. I can access the fbx animation ranges in any context through expressions, python and whatnot, but how to make pdg follow this range per workitem ? An example would be much appreciated!

thanks.

In 17.5 when using the ROP Fetch node, each work item is only associated with a single frame. If your ROP Fetch TOP node generates 100 frames of work, it'll create 100 work items. You can generate the frame range dynamically using an expression that refers to work item attributes in the `Range` parameter on the ROP Fetch, however each work item will still only be associated with one of the frames on that range. In 18.0 the ROP Fetch is also able to cook a whole frame range in a single work item, and the range can be set dynamically using an expression.

In the file you posted the expression on the ROP Fetch is fine for generating a dynamic frame range. The problem is that you're trying to use the Geometry Import to load a SOP network, which is in turn using PDG attributes (@filename in your CHOP network). This won't really work because PDG work items cook on background threads, and to make that work they would need to be able to force the SOP network to re-evaluate for each work item in the geometry import. You'll need to use a ROP Geometry Output first to load mocap and write out a .bgeo file, and then use a geometry import to load the attributes from those .bgeo. This is also partially addressed in 18.0 - you'll be able to use an Invoke TOP instead to do that all in-process instead of using a ROP Geometry Output which cooks out-of-process.

I've attached an updated version of your .hip file. Note that I've added a ROP Geometry named read_animation_end_frame which has an embedded SOP network that does the same thing as the SOP network you created with that same name. Also note that I had to make the Geometry Import (and therfore the FBX ROP Fetch) dynamic because the geometry import needs to access the ouptut files from the read_animation_end_frame node, which aren't available until those work items are cooked.

In 18.0 you can modify the ROP Fetch so it only has two work items that each cook the full frame range rather than using batching, and replace the ROP Geometry Output with an Invoke.

wonderful Taylor, thank you for the in depth explanation! I now understand that this is a case for storing data on disk as an intermediary step, at least for Houdini 17.5. works great with the rop geo+geo import combo.

Now regarding H18, I tried your second sugestion, as it seems more efficient (no temp files). The invoke node needs houdini native input geometry, so my file pattern node reading .fbx of course errors: “Error loading geometry bla\bla\bla.fbx” - makes sense. to workaround this I created a dummy geo node at obj level and imported that into pdg using geometry import (I don't need actual geo, but only an attribute placeholder for it to be fed into the invoke). Now on the invoke node I point to a compile block end sop and finally another geo import to extract the attributes from the result of that invoke node. Basically this:

PDG:
file pattern (read *.fbx) -> geom. import (dummy geometry) -> invoke -> geom. import (extract attribs from invoke geo output)

SOPS:
geometry container -> compile begin -> add (1 point) -> attribute create (reads frame range from fbx chop node using chopl()) -> compile end

Unfortunatelly I'm not getting the correct endFrame attribute per workitem, it always have the same number for all items, so probably this is the wrong approach? I'd again appreciate if you could elaborate a bit more on this, as it looks like a better and smarter way of doing this.

big thanks.

After looking at your .hip file again, I realized that the suggestion I made earlier regarding the Invoke node may not actually apply. Since you're using CHOPs to do the actual loading of the .fbx file, I don't think you can use the invoke. That portion of the network can't be put into the compiled block, so I think you'll need to stick with using the ROP Geometry approach.

As a general note though, inside of the compiled block you're not able to use the @attribute HScript syntax. This is a restriction on compiled blocks themselves and applies for both geometry and PDG attributes. You are able to use the pdgattribute and pdgattributes functions to access work item attributes from nodes within the block. Those functions, along with pdginput/pdgutput, are similar to use the @ shorthand: https://www.sidefx.com/docs/houdini/expressions/pdgattributes.html [www.sidefx.com]

I also realized that in the file I sent, the output file name on the ROP Geometry is potentially problematic. In order to get a unique file name per .fbx file, you'll probably want to set the output path to $HIP/geo/$OS.`@pdg_index`.bgeo.sc, instead of the default path using $F4.

allright, I ended up going for the ROP geo approach and it worked, so I'll stick to that for the moment. Thanks for all the clarification Taylor.