I presume this is because the new SSS Random walk includes “albedo inversion”
This comes with a new albedo inversion that gives different results than
the old one. For that reason there is now a Random Walk and Random Walk
(Fixed Radius) option. The latter is provided for backwards compatibility,
and uses the radius exactly as specified. The new one adjust the radius
based on albedo and IOR.
Source: https://developer.blender.org/rB7811c11472302948015b94137c8918f0292936d4
i hope they try to implement the burley back, i don’t like the result of the random walk for certain things, 
I have the same error for my addon. Add ‘CompositorNodeRLayers’ cause crash
My guess would be that it’s simply the random walk being correct and the burley approximation being wrong.
Burley’s model, like almost all of the BSSRDF models, works under the assumption of a semi-infinite flat object. This breaks down when you have thin surfaces where light from the backside scatters through, such as those spikes on a sphere or the spout of a teapot.
The effect of it shifting the color to the complement happens when your model is set to not absorb any light. Your scattering will then be dense and scatter back to where the light entered for some wavelengths, the other wavelengths will pass through the object largely undisturbed and come out at the other end. This effect can easily be reproduced if you use use true , very dense homogeneous volume shader on such an object in Cycles.
Not sure what’s changed in the latest builds, but it’s been a few days that all the new builds render just a black image. Is it just me?
I’m on Windows 10, with dual 1080ti.
The same thing is happening even with the latest blender-3.0.0-alpha+cycles-x.7811c1147230-windows.amd64-release
The last good release for me is
blender-3.0.0-alpha+cycles-x.29e48f2df560-windows.amd64-release
There was a cuda version issue on the windows bot that got corrected today, try the build from a few minutes ago (03848955463f) is that one any better?
I’m still looking at a way to handle self-intersections and non-manifold geometry better, which may help with your cases, but it’s unclear still.
This is likely due to a bug with Denoising Data, that should be fixed in the next build.
This should also be fixed in the next build.
One piece of Cycles-X feedback.
Maybe make the viewport update more often during the first few samples?
For example, when viewport rendering is enabled and you’re moving around or changing parameters, it updates often (aims for 60 fps?), which is good. However, once you stop moving, viewport updates are reduced to maybe once per second or two. I understand this is to increase performance. However I believe more frequent viewport updates for the initial few seconds is more important than sampling performance. And this is because when you stop moving around or changing parameters, you’re left with a 1 or 2 sample image. This 1 or 2 sample image is good for making large changes to parameters, but due to the low sample count producing a lot of noise, you have to wait for more samples to make decisions on small changes, and the wait of 1 to 2 seconds for the next viewport update to show up is annoying.
So maybe viewport update speed could be increased or maybe the update speed for the viewport can change? Update 1/8th a second for the first second, update 1/4th a second for the next second, and proceed until you reach the 1 or 2 seconds between updates.
Note: The issue I’m talking about is most noticeable of you set your viewport sample count to “0” (infinite) with viewport denoising (OptiX or OIDN) and with scenes that are semi-complex (I used a SSS shader to create the “semi-complex” scene). If the scene is two simple (hundreds of samples per second), the issue does not exist. If the scene is too complex (1 sample per second), the “issue” can be mistaken for the rendering performance of the scene.
Also, here’s a video demonstrating the issue.
Note: Some of the visual artifacts/changes seen in this video is caused by compression (I wanted to keep the video as small as possible to let it load quickly). But the issue can still be seen.
Edit: I see this might be planned. In /intern/cycles/integrator/render_scheduler.cpp at line 813 there is a TODO that would work around this (assuming I understand it correctly):
/* Avoid excessive denoising in viewport after reaching a certain amount of samples. */
/* TODO(sergey): Consider making time interval and sample configurable. */
delayed = (num_samples_finished >= 20 && (time_dt() - state_.last_display_update_time) < 1.0);
Adjusting the num_samples_finished >= 20 value to something higher helps reduce the issue for me with my test scenes. Just some information for people who compile Blender their self that may want to “fix” this issue.
There are also some values in that same file at line 634 that can be adjusted to configure viewport update speed. Adjusting some of these can also help with the issue.
if (num_rendered_samples < 4) {
return 0.1;
}
if (num_rendered_samples < 8) {
return 0.25;
}
if (num_rendered_samples < 16) {
return 0.5;
}
if (num_rendered_samples < 32) {
return 1.0;
}
return 2.0;
}
Here are the values I changed too. Not suitable for every scene or all hardware configurations, and I might continue to tweak it, but it works better for me in specific scenes.
delayed = (num_samples_finished >= 256 && (time_dt() - state_.last_display_update_time) < 1.0);
if (num_rendered_samples < 64) {
return 0.1;
}
if (num_rendered_samples < 128) {
return 0.25;
}
if (num_rendered_samples < 256) {
return 0.5;
}
if (num_rendered_samples < 512) {
return 1.0;
}
return 2.0;
}
Edit 2: I looked at the code some more. Some of things I said I want in Cycles-X is already in Cycles-X. But the default values don’t work well for specific scenes with my hardware.
And fixed it is. Thanks!!!
I have created a diff that changes the viewport update speed to change based on time rather than samples which helps work around the issue I talked about in my previous comment. https://developer.blender.org/D12265
Here are some videos to show it off:
Cycles-X:
My Patch (sorry if this one is slower to load, it’s uploaded to developer.blender.org rather than devtalk):
Also, in this video, the viewport updates slowing down after a few seconds can be more easily seen in the second demo scene. Note: The viewport updates slowing down is intended. It allows for faster rendering. The patch makes it so the viewport updates more often in the first few seconds which is important for artists making decisions on finer detail.
Nice demo. With patch applied cyclesx looks smoother. I wonder how this work with a real more complex scene, like one of the blender official demos
I’ll give it a try now. But it should be noted that this patch is only useful on semi complex scenes. As the scene gets heavier, or your device gets weaker, the current behavior might be preferred.
Actually, I might add that functionality to the patch.
Just realized the fixed radius is only default for the default cube material, not the default for newly created material. So it seems the user is expected to be using the raw one from now on? How do you actually work with the raw one then? Am I doing it correctly here multiplying the radius? Explaination on how to work with the raw one properly will be apprieciated.
Is this working for solving the initial sudden increase of noise right after stop moving the viewport? Nice, this is actually pretty obvious in some scenes. Also it is very visible in the Spectral Cycles X branch as well where all noises become colored. It will be very nice to have a smoother view when stop moving the viewport!
The patch does not fix this. The patch just allows the viewport to update more often during the first few seconds of rendering. So you’ll still have a lot of noise after you stop moving the camera, but if you have a scene that renders really quickly on your hardware, then a lot of that noise will appear to disappear quicker with my patch applied. (With normal Cycles-X you might (depends on the scene and your hardware) have to wait up to 2 seconds after you stop moving the camera for the noise to disappear. With my patch the image will get progressively better over those two seconds)
There is no change made to the sampling algorithm. It’s just a change to when the render is displayed.
I have added the functionality to the patch.
One thing I forgot to add. My patch does have one negative side effect that I know of. If a scene renders really quickly (E.G. anything faster than 4 samples in 0.1 seconds), then my patch will result in the viewport rendering fewer samples for the first 8 seconds. As the scene gets quicker to render (E.G. 32 samples in 0.1 seconds, then the number of samples lost will be worse). I’m not sure on the scalability of performance as you get faster or exactly how much of an impact this has (is it 10% slower or some other percentage?).
However, I believe the trade of a little bit of performance in the first 8 seconds is better than having to wait 2 seconds to see the first viewport update in scenes that render quickly.
Win 10
gtx 1070
without denoising
300 samples
Test scene (exterior) 1920*1080px
Cycles-X (5ce4 ) 89 sek
Cycles (master) 115 sek
Test scene (interior) 1000*1000px
Cycles-X (5ce4 ) 84 sek
Cycles (master) 156 sek
Any chance this BUG: Multiscatter GGX artefacts for rough glass be fixed before Cycles X goes into master?
https://developer.blender.org/T85259