overwrite TOPs output?
2736 8 0- dgirard
- Member
- 47 posts
- Joined: July 2014
- Offline
- protozoan
- Member
- 1607 posts
- Joined: March 2009
- Offline
- tamte
- Member
- 8449 posts
- Joined: July 2007
- Offline
sounds like this goes against what PDG is supposed to do
I'd say that if PDG knows better what workitems are dirty and therefore will potentially create different output, it should be the one making decisions on what to overwrite and what not, having outdated outputs being used can waste a lot of downstream time and resources computing wrong results
calling it Automatic is definitely confusing in modern PDG terminology, if anything Automatic should Write if dirty leave intact if not (which is probably the Write option)
Maybe making Write option default could be a safer option?
I'd say that if PDG knows better what workitems are dirty and therefore will potentially create different output, it should be the one making decisions on what to overwrite and what not, having outdated outputs being used can waste a lot of downstream time and resources computing wrong results
calling it Automatic is definitely confusing in modern PDG terminology, if anything Automatic should Write if dirty leave intact if not (which is probably the Write option)
Maybe making Write option default could be a safer option?
Edited by tamte - March 31, 2019 17:07:57
Tomas Slancik
FX Supervisor
Method Studios, NY
FX Supervisor
Method Studios, NY
- protozoan
- Member
- 1607 posts
- Joined: March 2009
- Offline
Tamte:
The problem is, that if you simply and solely use ROP fetches and the likes, it's “dumb”.
That means for example, if you change the camera, dirty the ROP and recook it, it won't, because it doesn't recognize that the ifds don't reflect the changed scene. They are there so they don't need to be recooked, even though they represent an older state.
And in that scenario, if you don't want to delete the current state from disk, write makes sense.
The problem is, that if you simply and solely use ROP fetches and the likes, it's “dumb”.
That means for example, if you change the camera, dirty the ROP and recook it, it won't, because it doesn't recognize that the ifds don't reflect the changed scene. They are there so they don't need to be recooked, even though they represent an older state.
And in that scenario, if you don't want to delete the current state from disk, write makes sense.
Martin Winkler
money man at Alarmstart Germany
money man at Alarmstart Germany
- tamte
- Member
- 8449 posts
- Joined: July 2007
- Offline
not sure I understand, I'll have to play with it more
in my logic it should be
- if my workitem depends on any workitem that is dirty I want my output to recook and compute new result, not keep the old one
- if I manually dirty the work item, I want it to do the same
- I understand that it's dumb in a way that it doesn't know if I change my scene outside of the TOPs, but in that case it's up to me to dirty the work item to force that
I don't see the scenario when I'd want a dirty work item to only pretend to cook but still keep the old result cause it found something on disk, at least not by default
I'd much rather have a way to manually mark workitems as clean if I want to force it not to recook (which could check if the outputs exist before it allows me to do that) than letting me believe I'm getting recook while in reality I'm not
am I missing something?
I mean is not a big deal as I can always keep it in Write, just saying that default Automatic is a bit confusing and sounds like a dangerous option
in my logic it should be
- if my workitem depends on any workitem that is dirty I want my output to recook and compute new result, not keep the old one
- if I manually dirty the work item, I want it to do the same
- I understand that it's dumb in a way that it doesn't know if I change my scene outside of the TOPs, but in that case it's up to me to dirty the work item to force that
I don't see the scenario when I'd want a dirty work item to only pretend to cook but still keep the old result cause it found something on disk, at least not by default
I'd much rather have a way to manually mark workitems as clean if I want to force it not to recook (which could check if the outputs exist before it allows me to do that) than letting me believe I'm getting recook while in reality I'm not
am I missing something?
I mean is not a big deal as I can always keep it in Write, just saying that default Automatic is a bit confusing and sounds like a dangerous option
Edited by tamte - March 31, 2019 17:31:02
Tomas Slancik
FX Supervisor
Method Studios, NY
FX Supervisor
Method Studios, NY
- protozoan
- Member
- 1607 posts
- Joined: March 2009
- Offline
- dgirard
- Member
- 47 posts
- Joined: July 2014
- Offline
- bonsak
- Member
- 459 posts
- Joined: Oct. 2011
- Offline
- tamte
- Member
- 8449 posts
- Joined: July 2007
- Offline
protozoanI'm just saying I don't see the scenario when I would want this to happen, the fact that it is happening is a problemtamte
I don't see the scenario when I'd want a dirty work item to only pretend to cook but still keep the old result cause it found something on disk, at least not by default
But that's exactly what happens now, and the exact problem the OP ran into
Edited by tamte - March 31, 2019 18:10:37
Tomas Slancik
FX Supervisor
Method Studios, NY
FX Supervisor
Method Studios, NY
-
- Quick Links