Cloud v3 seam between render tiles?

Started by Arnold, March 22, 2018, 04:28:44 AM

Previous topic - Next topic

Arnold

I'm rendering 16k panoramic views using TG4. To keep RAM usage under control I render the scene part by part using tiles. It has 2 cloud layers v3.
Here is part of the render between 2 tiles:


As you can see, there's a sort of seam in the clouds. It looks like the lighting in the clouds v3 is not correctly matching on both sides of the tiles.
GI is ok though.

Is it a bug? What is causing this, and is there anything I can do to prevent it?

WAS

#1
It seems like scene lighting. Even the slightest change in camera pitch can change scattering/refraction/lighting settings I am sure. It only seems natural, like a camera.

pokoy

This is probably due to voxel or GI caching which is interpolated in screen space I suppose. I'm not sure if you can render the cache to disk with clouds v3, though.
An obvious solution without saving the cache would be to render both tiles with an additional overlap so you can overlay both of them and mask that area with a gradient.

Arnold

Quote from: pokoy on March 23, 2018, 05:39:29 AMThis is probably due to voxel or GI caching which is interpolated in screen space I suppose.
Yeah, I was thinking maybe it's because the clouds' voxels don't exist outside the rendered view for some technical reason, making the lighting "incorrect" in the clouds v3 on the borders of the image.

Quote from: pokoy on March 23, 2018, 05:39:29 AMAn obvious solution without saving the cache would be to render both tiles with an additional overlap so you can overlay both of them and mask that area with a gradient.
That's an idea. This would complexify my current workflow but it would probably work. I hope I won't have to do that.

Quote from: WASasquatch on March 22, 2018, 03:55:07 PM
It seems like scene lighting. Even the slightest change in camera pitch can change scattering/refraction/lighting settings I am sure. It only seems natural, like a camera.
True, but tiles must be seamless, given that I correctly take care of GI. Unless there's something I'm missing with clouds v3.


I just found the "Transition dist. (voxels)" parameter under the optimisation tab of clouds v3 (and v2 too). The wiki doesn't say anything about it, so perhaps it's what I'm looking for, I'll do some testing and report back.

WAS

Curious question, are you using atmospheric bloom, or bloom?

Arnold

No post-pro effects. And the clouds have "acceleration cache: none", so the most precise render possible.

Oshyan

The v3 clouds do not yet work with the GI cache, so to get seamless v3 cloud renders in tiles you sometimes have to increase GI settings for greater overall accuracy. This is GI for the clouds specifically, it's in the Cloud GI tab in GI settings of your Render node.

- Oshyan

Arnold

#7
Thank you Oshyan for your answer.

So if I increase the GI in clouds from "Still / medium" (the default value, used in my above render) to "Still / very high", would that fix the issue, or at least make it practically invisible?

How much longer would that make the render time?

Also what are the other settings for?
"Cloud GI max ray depth" and "voxel scattering quality"

Oshyan

Yes, increasing that setting would fix it, but I can't say what specific setting you would need as it depends on many other details in your cloud and scene configuration. For the same reason I can't really say how much it would impact render time. I suggest if you need to know then you do some tests of smaller crop regions to get some benchmark times with different settings.

Cloud GI Max Ray Depth shouldn't need to be changed, it controls how many additional rays beyond the primary are calculated, so it can make things more accurate, but in practice it has a limited effect in most cases.

Voxel scatter quality has an effect on cloud v3 shading quality, i.e. noise. In most cases it also does not need to be changed.

- Oshyan

Arnold

Ok thank you very much for the information Oshyan.
I will apply it.

Arnold

Ok issue fixed.

First so I changed only the clouds GI to "Still / very high", it was better but still visible:


Then I increased GI from 3 to 5, and the seam is totally gone now:


That's great! I can now keep on rendering :D

Oshyan

Excellent, glad you were able to resolve it. :)

- Oshyan

WAS

I have a similar issue with stars made out of clouds. The stars along the borders of render between tiles are cut off creating half stars or partial lines. I tried Still Very High, with ray of 8, and upping GI to 5 but still get seams.

Oshyan

This is likely because your "stars" are such small points that their sampling is essentially random, which is probably similar to what Denis is encountering. It's hard to say if very high settings would fix it, but even if they would, render times would skyrocket. So it's better to try to increase the "star" size until they are *just* the size of (or slightly larger than) a pixel. That will get you better sampling.

You can probably test whether too-small-star-size is the issue by rendering a crop region 2-3 times and if the "stars" are in different positions every time, then that's likely to be due to them being too small to sample effectively.

- Oshyan

Kadri

#14

I had the same problem ones in Terragen and other software. Not sure if there are better ways.
For me using randomly instanced basic polygon sphere objects were the fastest and easiest solution for stars then.