Varying colors in different buckets

[N-drju]

In order to render images, I am usually using the "crop area" option due to memory issues. There is a downside to that however...

In many cases I get varying colors, especially on clouds, on the borders of render buckets like so...

[attach=1]

Needless to say the image is not seamless as it should be in the end. Do you know how can I avoid that sort of problem? Maybe some clever workaround except from post-processing?

[Dune]

I'm not sure, but a GI cache file for the whole image might work. Or working with fill lights instead of GI (but then you miss the great GISD feature). I had the same in my museum wall, rendering 2 adjacent angles of 45º with GI(SD) yielded differences in sky. I had to resort to post.

[N-drju]

Ulco, but could you direct me to that post? Or do you mean the post that's in the "Museum Wall" thread? (Somewhere around page 4-6 I believe?  ) I read it but I don't think any solution was given there...

Or let me ask you this - how did you solve that problem? I saw the strip of the museum wall where you had that problem. After changing which setting(s) the image was seamless? Did you manage to pinpoint what solved the issue? I'd like to avoid PS post-processing...

[Dune]

No, I couldn't solve it in TG, but for me that wasn't too bad, as it was only a part of the sky that needed some adjustment. So I did that in post. I don't have another possible TG solution other than what I mentioned just now.

[N-drju]

A little update on the issue:

Just confirmed that the cache file indeed does work. However I found out as well that the cloud quality is to blame if you are doing crop region. Apparently, the higher cloud quality the more likely it is for the bucket seams to be visible. I'll experiment with these values yet.

Strange, I know but results speak for themselves. I cranked cloud quality to 1 just like Oshyan suggests in rendering tips thread and it worked just fine with clouds still looking very nice and bearable render time. No seams visible. So far so good. Gonna post results NLT Thursday.

[Dune]

Glad it worked out ok, curious to see your work...

[Matt]

A little update on the issue:

Just confirmed that the cache file indeed does work. However I found out as well that the cloud quality is to blame if you are doing crop region. Apparently, the higher cloud quality the more likely it is for the bucket seams to be visible. I'll experiment with these values yet.

The cloud layer's acceleration cache uses a fixed amount of memory. Higher detail causes the cache's memory to be filled up in a smaller area of the image, and then values are recalculated which may be different from the values previously cached for the same locations. With lower detail, the cache can be used for larger areas of the image, providing consistency over larger areas.

Ideally the values would be the same each time they are recalculated and stored in the acceleration cache, but this does not happen.

EDIT: I'm not sure why I'm talking about the acceleration cache here. The problem in your image is probably caused by GI.

Matt

[Dune]

So it's best to make the cache file with low detail and AA settings, and then set it to high settings and use the cache file? That's what I thought anyway.

[N-drju]

Won't that have any adverse effects on a final image (say det=0.7 / AA=5) if I create cache file with much lower values (det=0.3 / AA=2 for example)? You say that shouldn't make any difference Matt?

Actually I believe there are no problems with consistency of the image no matter what settings were used to create a cache file. I made mine with detail and AA being somewhere in the middle.

[Dune]

Matt should acknowledge whether I'm right, but I think the GI is a 'soft' thing anyway, so it won't make a huge difference or non at all.

[Matt]

So it's best to make the cache file with low detail and AA settings, and then set it to high settings and use the cache file? That's what I thought anyway.

I was talking about the acceleration cache in the cloud layer. This has nothing to do with GI or GI cache files. I have edited my post above to clarify.

Matt

[Matt]

I don't know why I was talking about the acceleration cache. It looks to me like it's a GI problem, as you thought.

As you suggested, IMO generating a GI cache file for the whole image and then reusing that cache file should solve the problem.

Matt

[Matt]

Won't that have any adverse effects on a final image (say det=0.7 / AA=5) if I create cache file with much lower values (det=0.3 / AA=2 for example)? You say that shouldn't make any difference Matt?

Actually I believe there are no problems with consistency of the image no matter what settings were used to create a cache file. I made mine with detail and AA being somewhere in the middle.

Matt should acknowledge whether I'm right, but I think the GI is a 'soft' thing anyway, so it won't make a huge difference or non at all.

You can use GI cache files that were generated at a different level of detail and/or image resolution. AA has no effect on GI cache file generation. But in this case I don't see any reason why you'd want to. Just generate the cache with the same settings you plan to render the final image at. My talk about acceleration caches wasn't relevant to the problem you had, as far as I can tell.

Matt

[N-drju]

No, no, you see I make a cache file with lower settings just for the reason that when I do it at higher AA & det the image crashes and I get errors like in this thread:

http://www.planetside.co.uk/forums/index.php/topic,17719.0.html

So as far as GI cache file is concerned I just want to complete it in the easiest manner possible. I'm afraid that the GI cache file will not work if it is calculated through a "damaged" image. Or will it?