Hi;
mtucker
If you can submit a hip file that demonstrates the bug you are seeing with the python LOP that would be much appreciated. I feel like a python LOP would be a perfet fit for this situation, and I'm not aware of any bugs that would prevent this (I use them to set attributes like this all the time).
Heard on the request for an example hip; you asked for that in this thread as well, when I was first noticing this behavior:
https://www.sidefx.com/forum/topic/86174/ [
www.sidefx.com]
In that case, I did try to winnow my scene down to a reasonably-sized example, but was unable to isolate the bug. It makes me feel marginally paranoid, but I am nevertheless still experiencing it in my full scene file. All of which is to say: getting an example will take me some time, and I keep getting distracted by other problems. On my list though. (as a side note: is there a "package file" tool anywhere, akin to how Adobe programs let you "package" things like inDesign or Premiere setups by consolidating all dependencies into one folder that's easy to zip up and hand to someone else? A big time sink for me constructing debug cases is having to go through my file checking for dependencies, remedying them, etc.)
In any case, in that thread I was led to believe that my use of Python to try to do what I'm trying to do wasn't the ideal use case for Python LOPs. I tried actually making my Python LOP modify the stage (rather than just setting parameters on itself), hoping that would bypass the cook bug I'm seeing, but that didn't work.
Stepping back: the thing I am trying to do could be construed as "pre-prep": I am making a virtual light meter, because I would like my scene to work using absolute units w.r.t. lighting. So, I have an IBL, I measure it, I configure my camera with some shutter/fstop/ISO speeds. I do not need to do this per-frame, I need to do it as a preprocess, the way you might do on-set before you start shooting, not 'while the shot is happening' (conceptually speaking).
In trying to understand how to optimally do this, it's been suggested at various points (by various people) to do it as an HDA, to do it in the source editor, to do it in a Python LOP. I've tried all of these, they all have pros and cons. It's possible I shouldn't be trying to do it in TOPS at all, it's just another experiment in a long series of experiments I'm doing trying to figure out how best to solve this.
mtucker
I suspect you can also make this work in TOPs too, but it would probably be a very different approach from what you're attempting there. You'd probably use python and TOPs to create a brand new layer that just contains the camera opinion, rather than trying to edit the LOP stage directly (which is not allowed). I can't guide any further than this because I don't know what you want to do with this LOP stage (save it to disk? Render it? Perform some other processing?)
Ok, this is helpful to consider, thanks. I *think* what I want to do with this hypothetical LOP stage is fold it back into my 'main' stage at the point at which I am setting this attribute, then continue on my way authoring my renderable setup in LOPs. I don't need to export it as a separate thing, and I'm not - at the point I'm running this code - yet ready to render it. So maybe the jargon I should use is "flatten it" to the main stage?
At the moment I'm hacking around this by:
- Using a Python LOP in Solaris to create the non-standard USD attributes in which I'm interested (e.g. "iso")
- Adding a "edit properties" lop, and creating parameters to modify my newly-created attributes
- In TOPs, I have a Python node that sets the parameters on this Edit Properties LOP.
The Edit Properties then does the work of managing the stage itself; it's indirect and maybe not maximally elegant but seems to work, and doesn't seem to trigger the authoring of unwanted time samples, nor does it require me to jiggle the timeline in order to evaluate/trigger the code.