Tweet
We are on an older nightly build from 12/13/10 We've just been too busy since then to change things much... but we are now seeing some oddities that for whatever reason haven't popped up before.
Most of our farm has hyperthreading turned off, since we were experiencing instability. A few machines have it turned on, for testing.
one of those machines are rendering frames slightly darker than other machines, but they are identical in build and vray version.
Not only are the beauty passes ever so slightly darker... but the multimattes are rendering below 1 in their respective channels. as in something like RGand B = .978
This causes BIG value differences in our comps where we use the multimattes to generate masks, so a nearly imperceptible difference in values accumulates to major flickering.
We have isolated it to generally happen on the hyperthreaded machines, but occasionally a machine that is not hyperthreaded has the problem as well... so I can't say it's the hyperthreading difference that is the cause of the problem... just that the hyperthreaded machines exhibit the problem far more consistently. Any idea?
For the time being, we are aware of the issue, and using colorcorrects and clamps on the multimatte passes to keep them reliable... but this is an annoying little bugger.
Andrew
Most of our farm has hyperthreading turned off, since we were experiencing instability. A few machines have it turned on, for testing.
one of those machines are rendering frames slightly darker than other machines, but they are identical in build and vray version.
Not only are the beauty passes ever so slightly darker... but the multimattes are rendering below 1 in their respective channels. as in something like RGand B = .978
This causes BIG value differences in our comps where we use the multimattes to generate masks, so a nearly imperceptible difference in values accumulates to major flickering.
We have isolated it to generally happen on the hyperthreaded machines, but occasionally a machine that is not hyperthreaded has the problem as well... so I can't say it's the hyperthreading difference that is the cause of the problem... just that the hyperthreaded machines exhibit the problem far more consistently. Any idea?
For the time being, we are aware of the issue, and using colorcorrects and clamps on the multimatte passes to keep them reliable... but this is an annoying little bugger.
Andrew
The problem was almost entirely related to one machine that was hyperthreaded where the others were not. The problem is, it was not entirely exclusive to that machine. A few frames were rendered by non-hyprethreaded, "other" machines. So we can't say it was isolated to a consistent machine.
Comment