If you are using regular Adaptive Sampling and turn *off* Affect Background when using a photo in the Environment slot, it renders fine (well, it renders too dark during the GI calc phase but then renders fine in the main AA phase).
If you do the same as above but use the Progressive Sampler, the background remains too dark during the AA phase.
Is there something I’m doing wrong here in terms of the Environment photo and, I presume, gamma? All gamma settings are at default max/vray, reinhard mapping, linear workflow off, clamp off, mode “color mapping only”, sub pixel mapping off.
Looks like a bug to me. Is there a work-around? I’d quite like to use the Progressive Sampler on this job but I really need the env. photo to be rendered unaffected so I can match it efficiently.
This is not a bug; the progressive sampler does not support the “affect background” option and V-Ray prints a warning about this. There are no plans to implement this right now.
I remember that issue - we shipped around that one by piping the background color into an output node and adjusting the output accordingly so we would get the same visible itnensity for testing purposes. We then switched it off for final rendering with the bucket renderer.
Can I ask what the reasoning is behind this? My understanding is that the idea was to make the PS basically identical to the AS, just have it act in a progressive way.
As usual, performance and memory concerns. The “affect background” option works after the final pixel values are computed; V-Ray keeps track of the background contribution to a pixel and before writing the pixel values, separates the pixel color into background and foreground in order to apply the correction to the foreground only, with some quirks if there is transparency involved, and then reassembles the pixel value. For the progressive sampler, these calculations would need to be performed for each pass and the additonal information needs to be kept in RAM all the time. This adds more processing and RAM requirements for each pixel, and complicates the code for the progressive sampler. It didn’t seem justified to do all that only in order to support that option.
Thanks for clarifying. We use it a lot, here, for various reasons, and finding the the PS is generally not best for our work-flow on most jobs, but it’s come in handy occasionally, while testing.
Turn Affect Background off, so we can use the original backplate in the render. Makes it much quicker to work when integrating cg elements into a backplate. I know you can do it with carefully mapped planes etc. but it all works perfectly in the regular Adaptive Sampler. It can also help to avoid fringing issues with transparent objects and fine details when comping back over the plate.
I’ve not tried that, actually! Will give it a go. The critical thing is that the BG in the final rendered image is exactly the same as the original backplate, so whichever approach works, I guess. Will try that one out.