New Sky Texture

Hey @nacioss I’m in the process of rendering out your sky at “every possible angle” to try and find other instances where the multi-importance sampler fails.

So far I’m 240,000 “simulations” in (out of 3,240,000 that I plan to test) and I’ve found probably over 100 instances where the multi-importance sampler fails. If you would like, I could collect a list of the sun elevations and rotations to help you or the cycles developers diagnose the issue.

The reality is there’s either something wrong with the implementation of the sky or the importance sampler as discussed earlier. If it’s the importance sampler, then I believe your sky implementation won’t be accepted unless the default value for the importance sampler is changed or the importance sampler is redesigned.

Technical details:

  1. “Every possible sun locations” means I’m testing every sun location between the rotation 0 and 360 degrees and between the elevations 0 and 90 degrees at 0.1 degree increments.
  2. My multi-importance sampling number is set to the default 1024 as that’s what caused issue in the other scene. I have a feeling other values (E.G. 1000) may experience the same issue of the sampler “just failing” but they may not be at the same sun angles. I would have to run some tests to confirm this feeling.
  3. The sun size is set to 5 degrees to eliminate the sun being too small as a issue.
  4. Blender version: 2.90 branch: new-sky-texture, commit date: 2020-05-30 20:17, hash: rB681838e1c94d

Here’s a screenshot of the folder with all the images in showing a place where the importance sampler fails frequently:

13 Likes

My guess is that it is most likely to be related to the importance sampling bug mentioned above and that once it is resolved, we hopefully shouldn’t see this issue anymore. That being said, it seems like a useful test regardless.

3 Likes

Hi.
Rendered with CPU or GPU? Do you get the same results with any of them?

Render with CPU (Ryzen 9 3900X). However, I do get different results with GPU (GTX 1050Ti with CUDA) - No issues.

@nacioss something to add to the discussion. May be something wrong with the build. Or it’s due to the difference between the “Smart interpolation” used by GPU and CPU as described here: https://developer.blender.org/T69745#941095

As @smilebags pointed out.

1 Like

Well, I think that when @nacioss submit the diff to be reviewed there will be more chance that Cycles developers will take a look at this to try to figure out where the problem is coming from.

2 Likes

I should really get going for the night (it’s late where I am). If anyone wants to keep playing around. Or if @nacioss want’s a file. Here’s one that covers the area that has the most issues. The area is 540,000 frames long, but if you bump the MIS resolution up to 4096, you should start to see issues in the first 4 frames.

2 Likes

One way to rule out the sky code is to do the same thing with a generated environment material where there’s just a black sky and a white circle of the same radius in the same locations. If the issue still shows up it clearly isn’t the environment code.

1 Like

Funny thing, you can render the sky as black just by setting Air, Dust and Ozone parameters to 0 :slight_smile: , then someone could render an equirectangular EXR image

1 Like

According to https://developer.blender.org/T69745 this will produce less than ideal results because the equirectangular image is sampled different depending on it’s filtering method. And previous posts in this thread show that the sampling is different between the equirectangular image and an environment generated by the sky texture node.

I’ll give @smilebags test a go with a generated texture in the morning unless someone else does it before me.

Another thing to test is whether a silly number of render samples (64k or something) starts to resolve to a similar result as the clean images. If so, that’s pointing towards MIS as well.

The hard limit in standard Blender is 8192. I will give that a quick test.

8192 still produces issues. It actually seems much worse.

Edit: Wrong test. Tiredness.

Do not worry :wink:. Thanks for your tests.

1 Like

I’m up to 100,000 samples. It seems to be converging to the “expected” result, but requires a long time. I will leave it over night and report back with results in the morning.

So now I have:

  1. Post an image of a really high sample count image with the bad sampling.
  2. Run a test with a generated sky texture simulating just the sun to eliminate the new sky node as the cause.
  3. Post some extra things for @nacioss that we’ve discussed in a private chat, but I think we’ve already sorted most of that stuff out.

Unless someone else tests these things before me.

1 Like

They sound like good tests, more and more seems to be pointing to faulty MIS.

Wow! I’m interested in the distribution of those failed renders. Will implementing the Riemann Hypothesis solve the bug? :nerd_face:

Sadly with our current attempts at solving the Riemann Hypothesis, I’m scared that we may not have the math available in time for Blender 2.90.0 release.

(Note: I understand it’s a joke and that there’s basically no chance the Riemann Hypothesis could be the fix.)

1 Like

Okay, so I’ve run some tests here are my findings.


Render a frame with “bad sampling” to a really high sample count to see if it converges to the expected result.

Here at ~6,300,000 samples, it converges to something close to the expected result. The “bad sampling frame” seems to be missing diffuse and/or glossy indirect lighting. May be a artifact caused by something else.

“Bad sampling” on the left. “Good sampling” on the right. All settings are the exact same between the two with the exception of the sun rotation which was shifted 0.1 degrees to produce the difference in sampling.
Comparison


Test a range of MIS resolutions.

I have tested with resolutions 1023, 1024, 2048, and 4096. This was a test requested by @nacioss last night in a private chat.

Note: Results are talking about patterns I noticed over 40,000 frames.

1023: Flickers in brightness (due to MIS missing parts the sun?) and has “Bad sampling frames”.
1024: Flickers and has “Bad sampling frames”.
2048: Flickering is heavily reduced. Has “Bad sampling frames”.
4096: Flickering is reduced even further (basically impossible to notice). Has “Bad sampling frames”.

It also seems that as the MIS resolution increases, the frequency of “Bad frames” increases.


Test just the sun from the new sky node

Changing the air, dust, and ozone parameters to 0 will reduce the new sky node to just render the sun.

With these settings, the same issues occur. Even increasing the sun size to something like 20 degrees still shows issues with “bad frames” appearing in the same places.


Test just the sky, disable the sun disk

There appears to be no issues when the sun is disabled. Seems the issue branches from the sun. @nacioss has run some tests and talked to me in a private chat explaining that the sun values of brightness are the same at all these different sun angles and that the math in the node probably isn’t failing. This lines up with the test at the top of the post (“bad sampling” frames will converge to similar results as “good sampling” frames).


As for other tests like creating my own world texture that replicates the sun in this node. I will look into it.

One thing I haven’t asked is this: Is anyone else experiencing this issue? I’ve noticed it on two computers, but that’s two out of billions.

It also may be down to the Blender build. I will test with the build provided by LazyDodo for Linux and will also attempt to compile my own build.

I also haven’t tested to see if I can reproduce this issue on CUDA. I’ve done spot checks and they seem fine, but that’s not enough to rule out the possibility.

4 Likes

It’s a huge task you are doing thanks for testing.

This looks like a big clue to start from. Now I’m wondering if this bug can show up also with HDR environment maps, those with proper EV sun.

ha ha! nice one

Just to announce it publically. I will stop my extensive testing of the sky node. I will continue to play around with the build, but I’ll stop testing this “failed sampling” bug.

We’ve almost certainly narrowed it down to the multi-importance sampler and not the sky node. And if it is something to do with the sky node, then hopefully a fresh pair of eyes when the developers look over the patch can help pin point the issue. I’m sadly unable to help on this part simply down to the fact I’m not particularly familiar with the programming language used here.

And if the issue is the multi-importance sampler, which I believe it is, then me posting about the issues here isn’t going to do much. Fixing the multi-importance sampler is outside the scope of the patch @nacioss is making. Fixing it may be a prerequisite to getting this patch added, but fixing it is not supposed to be part of this patch.

9 Likes