Sep 2 2015

which device do you use?@Sergey Sharybin (sergey), I got a similar problem "in a rare case, where I tested on dual GTX Titan X, CUDA 7 SDK, 1 of the Titans is always rendering black image, the other is fine (this is ONLY in experimental model)

Aug 24 2015

hey @Brecht Van Lommel (brecht) , any image about how this happens? "how the ray bounces under a strong normal/bump, and what makes it black (low pdf, etc...", what is the possible work around "other than real geometry displacement"

Aug 7 2015

hmm, I see where the problem lies now, it is not about usability "caustic bounce for sure got its uses like overriding caustic colors for some shaders" , but here to use such a feature, it needs to be addressed through a light state only!! "as it starts from the light, then specular/glossy" , so for PT integrator it won't work, for BDPT integrator it can work only for light states "not camera states".

light path node is considered the best node in Cycles :D "this is what makes user have fun when creating complex shader setup"
and probably give a hint that it won't give the same result with different integrators.

you can test it after implementing BDPT, with a very high sample count "50k", using light path node, PT won't equal BDPT "considering no point lights as they are impossible without event estimations for PT"

For the light path you don't know you have a caustic until you hit the diffuse BSDF, and for the camera path you don't know you have a caustic until you hit the specular BSDF. So that would work different depending on the light path, and for correct results the shader should give the exact same result regardless if they are executed on a light or camera path.

it will be a converter function node, so the user decides what he needs here.
this also will help a lot with image denoising implementation "as the image denoising algorithm depends mainly on input textures & output colors"
so with this, it will help give more denoising directives "shadows, caustics, glossiness,...".

hmm, right now adding it like this is giving wrong results as you can see from the images, the best option I guess is making it a color multiplier "not Closure", so it can act like a dirt texture. "and this would open a new level to Cycles, where you have Closures that can act like textures"

I see now why you did it with a + "a terrible error" , it is made similar to how the emission is calculated "connecting to light with a +"
with lights/objects emission, you just see if you are in shadow or not, if not occluded, you get the value, other wise it is black.

Jul 27 2015

so to finalize the code, I have to change a little in buffers "as described earlier, so buffer will be a little larger by a margin of pixels depending on filter size", this also will give a benefit later "when implementing image denoising algorithm from paper (1)", as it has to access/write to neighboring pixels as well.

oh :D , for a long time, unbiased in my mind was = anything that uses connections (PT, BDPT, MLT, ..) with bruteforce, no smoothing.
so irradiance, lightcache, photonmapping, ... are the typical biased algorithms (they use interpolations, merge), as the results of them is just interpolations "sppm is consistent though, but still it is biased".

hmm, explain more, there is something that I'm missing here that I don't understand.
I think it is biased because when camera casts a ray at pixel (x, y), the contribution should be only for that pixel, in this filter, the contribution is done to all surrounding pixels too.

not the exact same result "there is a difference because of the filter contributing weights to neighboring pixels", this is considered a bias, but the difference is smoother image.
let me explain the main difference:

I see, but what if we use both?
filter MIS reduces noise "variance"
but it doesn't address AA "you still see very sharp diagonal lines even if you are using 10000 spp"
here this filter can give you the interpolation between pixels "more blurry", so it enhances AA look

same number of samples "32 spp", the noisy one is using a very small filter "which is actually not calculated to neighboring pixels by the filter function, as the filter size in the noisy one is 0.4, in the good one is 1.5, both is using Mitchell"

@Sergey Sharybin (sergey), inside kernel_camera.h, camera_sample(), here it generates weights "and that's why I couldn't make them in another kernel" , as each pixel is giving 25 weights to neighboring pixels, so it doesn't depend only on a single weight and a single L, it depends on L and 25 weights per pixel.

@Brecht Van Lommel (brecht) , what do you think about kernel filter vs compositing filter? "I prefer kernel filter as stated above"
also you got a good point about the negative weights of Mitchell
what about atomics? any idea to avoid them? only 2 things that I think of are:
1- another buffer to write to (bad for memory, also bad as it is global memory write), or
2- shared memory atomics "faster on Maxwell, slower on Kepler"
or anything that you may suggest.

Jul 23 2015

I see the filter result is not correct, the only place where I suspect is the filter table itself
in PBRT the filter table is just the function, in Cycles the filter table is done using a long process and MIS stuff.

Jul 22 2015

I'm not sure why it is getting red in your case "it is fine here" , it is related to the write part in your side "as I changed some stuff in the get_rect(), they should accordingly adjust some stuff inside the write_cb() and update_cb() functions

Jun 23 2015

I think wrong behavior should be considered as a bug.
if I have an equation f(x) = y * z; , and I wrote it f(x) = y + z; , then this is a bug :) "a bug doesn't have to crash the software, it is just a feature that won't appear correctly in the final image, and has to be resolved with compositing"

Jun 12 2015

I think this is a normal behavior, indirect sampling won't work with branched PT, so if first hit -> it will sample all numbers in branched PT "direct" , other wise it will sample only 1 sample for indirect, which makes AA samples responsible for indirect noise.