Regions render with different brightness

[Alex_M]

There's this long-standing problem with region renders having different brightness from the rest of the rendered image. Is there anything I can do to avoid this? I often find myself rendering a much larger portion of the image than I need to and sometimes even the whole image altogether.

[fixeighted]

Oddly enough I have literally just posted this same thing, not realising that it has clearly been happening for a while.
In my situation I can relate it to the autoexposure settings. See my thread and maybe check on your side to concur or otherwise

[Alex_M]

Yea, as I mentioned it's been a long-standing problem. However, I don't use auto exposure so it's not that.

[^Lele^]

I think the workaround is to not use the LC.

[fixeighted]

Thanks for the suggestion. So the light cache is the culprit. Most certainly solves both this issue and that of the render mask selected item causing a similar problem.
However it does raise the issue of render times, as the BF/LC is quicker.

I just did a test whereby I saved the cache and had it switch to that, making the problem go away. However not immediately, as the saved cache was a different brightness to that of the image it created (*sigh), meaning I needed to rerender the frame with that adjusted brightness in order for the region to work as expected. So not really a workable solution

With both this and the similar render mask thing being easily reproducible, can this not be considered a bug needing investigation at some point do you think?

[Alex_M]

Yea, Brute Force renders a lot slower than Light Cache. Not an alternative really.

[fixeighted]

For me it's a real headache, as is the render select, as my clients, are literally always changing bits after they approve things, so to be able to rely on rendering a specific object or an area
with which to patch the render is crucial, or it means redoing the whole thing. What's worse is that I'm pretty sure it used to work just fine.
Maybe tomorrow, when peeps are back at work (lucky enough to work a regular week unlike me), this will be seen and hopefully answered by the clever chaps who know what's what

[^Lele^]

Yea, Brute Force renders a lot slower than Light Cache. Not an alternative really.

Then there is no other alternative currently. You'll have to wait for a fix.

[^Lele^]

I'm pretty sure it used to work just fine.

That i remember, it's always been the case, with the LC (in screen space, per frame, of course.).

[fixeighted]

Hmm...I just trawled through a load of stuff and have a ton of region patches going back years, so seems to suggest it was working at some point.
Can't check the max files due to version change but the patches do show that it used the cache, so now I'm confused.
It'd be great if someone at Chaos had an old version to try it out on, just to eliminate that line of enquiry I guess.

[^Lele^]

Hmm...I just trawled through a load of stuff and have a ton of region patches going back years, so seems to suggest it was working at some point.
Can't check the max files due to version change but the patches do show that it used the cache, so now I'm confused.
It'd be great if someone at Chaos had an old version to try it out on, just to eliminate that line of enquiry I guess.

If it's a precalculated one, or in world space, it may.
The LC *always* produced slightly different results in crop mode, as it's its mode of operationwhen run per frame in screen space.
I have direct production memories of this from v-ray 1.47, and can't recall it ever being a closely held secret.
Since then a few more tricks have been implemented which may have made the difference a bit more noticeable in specific cases (Adaptive lights and dome, Premultiplied LC, and so on).
It's trivial, if one's approach is to rerender crops, to render a full-screen LC, save it, and rerender the crop.
Still going to take a lot less than rendering the full screen anew.
Fair warning: one may have to turn off a few of the adaptive processes (read above) which depend on the LC in that case, but given the goal is to render exactly identical crops, instead of outright performance, this may well be of help.
The fix's however been promised, i believe, and it will come at some point.

[fixeighted]

Yeah I am tempted to think that simply my setup at the time allowed me do this with no problem, as I fully agree with your comments.

However, just to emphasise my happiness this morning, Yavor actually solved both this issue and my render mask headache and responded in the post I made.
I tested this out and all regions now render with zero perceivable difference, so I hope this is also the case for Alex

[^Lele^]

Yeah I am tempted to think that simply my setup at the time allowed me do this with no problem, as I fully agree with your comments.

However, just to emphasise my happiness this morning, Yavor actually solved both this issue and my render mask headache and responded in the post I made.
I tested this out and all regions now render with zero perceivable difference, so I hope this is also the case for Alex

This issue and yours were slightly different: this will happen even if the exposure and WB are fixed, i'm afraid.

[fixeighted]

Oh...umm....out of interest, how can I test this so I know what to avoid?

[^Lele^]

With auto-exposure off, try rendering any scene as whole image, and then repeat for a smaller crop, you'll see the differences.
They can range from minute to important, alas they don't quite allow for a slot-in of the crop.
Which a BF/BF solution would, for example.