Hello!

When using the copytopoints lop, if there are parameter values written into the /HoudiniLayerInfo of the Protype's stage (via Store Parameter Values lop for example), those won't go through to the newly created stage with the instancer.

Is this intended? Would it make sense to have that data travel into the new stage's own /HoudiniLayerInfo?

Thanks!

SESI #158865, submitted as: Bug#141731

If anyone encounters this issue, a workaround is to create a simple python script using loputils module's functions fetchParameterValues() (pointing to the prototype's stage node) and storeParameterValues() (pointing to the output instancer's stage node) to copy the data over.
The only way I know to access to info about this module is through $HFS/houdini/python3.9libs/loputils.py, as it is explained in the USD survival guide (https://lucascheller.github.io/VFX-UsdSurvivalGuide/dcc/houdini/faq/overview.html#where-are-houdinis-internal-lop-utils-stored).

With access to the body of the function, a nice optimization is to copy both functions over instead of importing loputils, and adding a stage input variable to both functions. This way if one wants to loop over all the parameters in /HoudiniLayerInfo, one can create the input .stage() and the output .editableStage() once outside the loop, and feed those to the functions in the loop, instead of creating .stage() and editableStage() each iteration (as the default loputils functions force you).

Hope this helps!

As discussed in my talk about optimizing LOP performance from the recent Horizon Hive (https://www.sidefx.com/houdini-hive/hive-horizon-2024/), you should collect all data you might need from the current node's parameters and all input (or other node's) stages before you ever call editableStage or editableLayer. So I would say the correct solution is to use two separate loops. The first one fetching all the values from the HoudiniLayerInfo on the prototype's stage, and stashing the values into some python data structure. Then do a second loop that adds each of the values to the HoudiniLayerInfo on the output's editableStage.

Calling both `instage = input.stage()` and `outstage = output.editableStage()` before either reading or writing anything can have two possible really bad outcomes. If you call stage() first, then calling editableStage() second may actually _change stage_ if the input and output share a common underlying USD stage. If you call editableStage() first, you may get the dreaded "tried to lock a stage that was already locked" message, which is basically a guarantee that your network will run slowly.

Calling stage(), reading the data, calling editableStage(), and finally writing the data avoids any possibility of either of these problems. You can still use the "unrolled" code from inside loputils if you want to avoid calling stage() and editableStage() multiple times, which will be at least a little bit faster, especially if you have a lot of data items to copy over.

If you call stage() first, then calling editableStage() second may actually _change stage_ if the input and output share a common underlying USD stage.

In this scenario, if both stages aren't shared, couldn't the issue be dodged? Like for example in this scenario where the input stage is the Prototype's and the output stage is the Instancer's, and the primitive being read and written was /HoudiniLayerInfo which is independent in each of those stages.
I was aware of the behaviour you mention but perhaps I had presupposed this.

Thanks for your clarification!

Sure! There are scenarios in which all of the potential pitfalls I mention are avoided, and no penalty is paid for doing things "wrong". And if you have some way to guarantee the absence of the scenarios that lead to these issues, then you can ignore my dire warnings. But I've learned to never underestimate a user's ability to work around my rock solid guarantees of "safety", so I try to program with a heaping spoonful of paranoia.

It makes sense. To be honest, for the amount of data that /HoudiniLayerInfo usually holds there is no real drawback on doing things "right": read first, then write.
However, when dealing with a big enough amount of data, doing things "right" comes at the cost of worse time and space complexity (we are looping twice and storing as many parameters as needed to later access them again when writing). Therefore, having workarounds that go against the advised but dodge the potential errors that are usually expected can be beneficial in some scenarios, and might not be so wrong.