The python SOP has a new option since 19.5 "Maintain State". The docs [www.sidefx.com] say:
SideFX When enabled, the underlying Python interpreter will not be cleared between cooks. This may give some performance gains, but can also lead to unexpected behaviour. It is generally recommended to leave this disabled.
I have now a setup in which I just want to maintain a few variables. In pre-19.5 I used a SOP solver for this. Just storing about 5 detail attributes.
Has anyone encountered this "unexpected behaviour"? And how does it manifest?
OTOH, there are these guys around
setUserData(name, value)
setCachedUserData(name, value)
setDataBlock(key, block, blocktype)
Are they the prefered Method to keep data/information between cooks? Which one gets used in "real life" out there ?
GOgraphR Has anyone encountered this "unexpected behaviour"? And how does it manifest?
it's very dangerous, simply variables will remember values so next time the node is run it may use incorrect value if the code doesn't make sure those variables are always initialized properly in all codepaths
While I didn't run into this I recall hearing that this was the default behavior pre 19.5 and therefore you could run into such issues, but since 19.5 you have to explicitly turn it on in case you want it or used to abuse this previously, so rather than it being a new feature it's a way to turn it off (default) to avoid issues
try:LastRun=PreviousRun# On first run previous is unknown, so it raises "Name Error". # The second time PreviousRun is already set, so the except part is skipped...except:PreviousRun=1do_Some_Setup()# Just to explain intentset_initial_detail_Attrib()compute_new_Attrib()set_updated_Attrib()
And then I would just access this detail attribute. So I hope there is no danger getting into trouble.
GOgraphR So I hope there is no danger getting into trouble.
The danger I was talking about is not erroring out on uninitialized variable as that can be easily remedied
The danger is in the persistence of the state itself
As such node may become unreliable, since depending on how many times it's cooked it may provide different result unless you implement more safeguards for that
Like if you are using it instead of the solver you'd have to make sure it will not advance when cooked more times within the same substeps and that it makes sure every substep follows previous one in a correct sequence (to avoid wrong values in case you decide to scrub or jump on timeline) and maybe implement internal caching etc. Not worth using over solver in my opinion, but of course it's up to you, maybe you have some use case in mind that doesn't pose such risks or maybe consistency is not as important in your case but rather some interactive feedback or something so then it can be potentially useful
Ok, I see what you meant. And no, its just to set some variables, that do not mind beeing "overcooked". I noticed, that when I advance one frame the python SOP cooks sometimes more than just once... But that's OK, for me and now at least. I have "safeguards" for that case, although the remaining network doesn't care.
What I do is getting the "real World" time and use it to render the rendertime in the scene.
Idea is kind of a "timelapse" on my Desk and a Wall clock that jumps every frame... First run sets attribute s@StartTime @startEpoc, and then s@NowTime @NowEpoc @diffEpoc
so I can have a desk clock display the time, the image was rendered... (I don't think I'll get an Academy award for that :-( )
