Hi,

I'm getting allot of black pixel artifacts in Karma renders. What is the correct way to deal with this?

Here is a test with the new Random Walk SSS shader. HDRi from HDRiHaven.

Either switch to uniform sampling, or set variance to 0 (for interactive renders). Variance sampling is still broken, or at least is completely unacceptable in image quality.

I somewhat disagree with the notion that pixel samples can be non-uniform, it always leads to artifacts. VRay with adaptive dmc always has weird holes in the dark areas because the adaptive sampling didn't use enough samples. Karma is even worse, where the holes are always pure black pixels on any shaded areas.

Thanks jsmack. I will give it a go.

Yep, that worked. Thanks again.

Just for the record: I wasn't involved in the creation of those artifacts!

Looks good - is that using the new random-walk SSS?
And yes, we're looking forward (anxious) for a fix to the variance issue too.

Yes, that is the new Random Walk.
It is a bit over saturated, because I was too lazy to convert the textures(Aces),
but it works…if Karma does not crash on me every two minutes.

Yup, that's looking very good Werner.

Thanks DaJuice.

Here is a quick re render with OCIO transform working in the latest build.
The random walk SSS seams to retain details much better. I am a very happy man.

This is what Multiscatter SSS looks like for comparison.

What's the rendertime different between Random Walk SSS and Multi SSS?

Daryl Dunlap
What's the rendertime different between Random Walk SSS and Multi SSS?

They are both equally slow to clean up, but Random Walk SSS does make it worth it.

I did not check render times as I fired them off before I went to bed.

With uniform sampling, I think everything takes about the same amount of time. Did you notice that the albedo of the random walk sss seemed low? It also seemed like the mfp was much lower in appearance than with the old diffusion based sss. The resulting color seemed pretty far removed from the color parameter, as well as the sss color seeming to have a very different effect than with the other models. Is this just the nature of the algorithm?

Do you have scale applied to the object? Currently there seems to be a bug with random walk where it can behave erratically with scaling which might account for larger differences (this will be addressed shortly).

dlee
Do you have scale applied to the object? Currently there seems to be a bug with random walk where it can behave erratically with scaling which might account for larger differences (this will be addressed shortly).

I do, in fact. The shell was modeled in mm or something so I scaled it down by 0.01.

The fix is in the upcoming daily build. It should behave better now!

Good the hear. Thanks.

The head I rendered was scaled down 0.01 as well, but would it have made a difference if the object was scaled in Obj level instead of in Solaris?

Scene Import would've preserved the transforms, so I assume your renders were affected as well.

Anyone seeing crashes with husk renders containing the random walk? When I render with 256 samples, they go for several minutes and then it exits as if it's done, but no image is output. I assume it crashed because the time elapsed is too low for it to have reached 256 samples. It doesn't seem to have trouble with 16 samples, or interactively. If I render at a low enough resolution it will output, but anything such as 960x540 or above does not.

https://www.dropbox.com/s/y1xfqdef5i1pt8g/random_sss.zip?dl=0 [www.dropbox.com]

Yes, I'm getting allot more crashes with Build 392. No image output.