- User Since
- May 30 2013, 12:55 AM (381 w, 4 d)
Apr 2 2020
Dec 28 2019
Apr 5 2019
Apr 4 2019
denoiser was crashing in OSX (latest Cycles standalone from 14/2/2019), it was doing negative indices randomly, behavior is undefined.
Mar 4 2019
Hey @Lukas Stockner (lukasstockner97) , any idea when this one will get resolved?
Oct 22 2018
May 15 2017
Mar 7 2017
I'm just following the great folks :) , Brecht, Sergey, Lukas, DingTo, Juicyfruit
Nov 9 2016
@Lukas Stockner (lukasstockner97) as I mentioned, for object and material IDs, they need a layer per ID. (So here you can average them, as the layer will be used any way, black and white).
Nov 8 2016
from code inside buffers.cpp, bool RenderBuffers::get_pass_rect(PassType type, float exposure, int sample, int components, float *pixels)
Aug 26 2016
Oct 18 2015
hey Sergey, what about recursive splitting to this triangle? "depending on triangle size" , this would solve everything in the preprocess stage
Oct 15 2015
win 8 64 bit
I'm using gooseberry 2.75 e96e452 and it works fine on CPU "i7" and CUDA "780, 970" , both supported and experimental mode.
Oct 6 2015
I got 2 cards, GTX 970 and GTX 780, testing with experimental mode with a SSS material
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 20 2015
Aug 11 2015
Hey @Brecht Van Lommel (brecht),
I think I'm very close to solve this :)
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.
so if these light path tricks will generate different results with different light transport algorithms, then "Is Caustic Bounce?" should be fine?
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.
Aug 6 2015
ok, I thought about this a lot and found a good result which should work in all cases/light transport integrators, like BDPT, VCM, SPPM, photon mapping, MLT, GPT, GMLT, etc...
oh, forget about my previous reply "was too hasty"
I can access what I want when doing the denoising stuff.
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,...".
Aug 5 2015
what about a new converter node, Closure to Color? with an option "check box" to use the Closure final Color, or just the BSDF probability.
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"
or even better,
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.
here is a test file, just render in viewport interactively, and drag the AO slider from world settings.
I edited my comment "read the comment here not in email", it is multiplied by all, only added to L->AO
here are some images, background HDRI image, without AO, with AO = 2%, with AO = 100%
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.
Jul 25 2015
ah, I see, this is the benefit for MIS filter :) "writing to the current pixel"
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:
this is a fast test, using Mitchell filter of width = 1, 64 spp
@Brecht Van Lommel (brecht), yea I know that, the above code is not the final, images here are from an updated code without MIS and CDFs, a different table.
about 5., yep, they got like 2.5x speed up in BVH build.
Jul 24 2015
so what shall I do now "if the MIS sampling filter is better, then this task will be useless"
I guess I remove filter from inside the kernels, and just add Blackman-Harris filter function to the code.
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"
here is a test from PBRT2, with and without filter, Mitchell 1.5
@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.
I fixed the problem now, added another table without MIS, and results seems correct
here are 4 images, 16 spp, 64 spp, with and without filter, filter is Gaussian , width = 1.5
@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
ok, I figured out how, thanks Martjin :)
here is the correct diff,
sorry for being noob, my first time to do a diff
so I got many commits, I squashed them into 1, did a diff from the master
- also disabled Saturate inside get_pass_rect() for alpha, Sature is done after weight denormalizing
forgot to add the diff,
sorry for this, didn't know where to add the diff, my first time here.
ops, I missed and put it in BF Blender, should have chosen BF Cycles.
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 21 2015
in other words, AO Closure behavior should be:
- at intersection, detect near surfaces by secondary rays, compare to AO global distance value "may be a setting for local value? or texture"
- after intersection, continue the ray through the object "similar to transparent node" , and so on..
- for the resultant color of AO Closure, it should be input texture color * AO (for RGB) , and for Alpha it should have AO color.
also for AO closure, it should add shadow to the surface, not colors, so if the surface is refracting, it should shadows it "not removing see-through part"
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.
Jun 11 2015
nvm, everything works in 1 click now after fixing hierarchy layout, thanks Thomas, it was my fault that I changed the folder name.
you can remove this task, cmakelists are correct and fine.
ok, you nailed it Thomas from the first shot, I didn't notice that it uses relative paths internally.
so pthreads should work fine now, what about LLVM_LIBPATH & GLEW_MX_LIBRARY part?