Noise Reduction back

(L) [2006/09/01] [greenhybrid] [Noise Reduction] Wayback!

Which noise-reduction-tec's are you using for your Monte-Carlo-Tracers?


I've just implemented a trivial path tracing alorithm, with 400 path's per intersection, at the time of the screen-shoot without importance sampling:


[IMG #1 ]



Now I am writing a generalization of the path-tracing, meaning that every intersection of the path lights up all other found intersections (like implented in bi-directional path-tracing). I am developing it on my own (just spend around 2h yesterday nite), first results are biased for some reason but noise is already reduced.



My question is: which methods are you using for unbiased monte-carlo-ray tracing?
_________________
[LINK http://greenhybrid.net/ greenhybrid.net]

Real Men code Software Graphics.
[IMG #1]:Not scraped: https://web.archive.org/web/20071029233656im_/http://root-engine.net/greenhybrid/images/rayfront_tec_0003.jpg
(L) [2006/09/01] [Michael77] [Noise Reduction] Wayback!

What BRDF do you use?   You need to make shure it is energy conserving. So my guess here is, you forgot to divide by pi.
(L) [2006/09/01] [greenhybrid] [Noise Reduction] Wayback!

I let out pi both for the direct (=rays strictly casted towards the luminaires) and the indirect illumination (=distribution over the whole hemisphere, excluding rays hitting luminaires [=Whitted-style, not?] ). So I think at the moment it doesn't matter (I only have lambertians in the scene) if with or without pi (two nearby surfaces are actually equally lit).


I don't apply energy at the moment, because I'm focussing on the noise reduction (after a major increase i'll switch over to the lighting)


on the other hand....lyc told me "FIRST GET THE LIGHTING PHYSICALLY CORRECT, OR YOU'LL BE MESSING UP WITH METROPOLIS" [SMILEY Wink] or kinda.


Looks like i gonna have a smooth friday-noon, chief isn't around, so I will renew my radiance-physics [SMILEY Wink]
_________________
[LINK http://greenhybrid.net/ greenhybrid.net]

Real Men code Software Graphics.
(L) [2006/09/01] [Michael77] [Noise Reduction] Wayback!

Well, although I am not shure, what exactly you are doing at the moment, but if you do indirect illumination you must pay attention to energy conservation. Otherwise the scene will get brighter and brighter with every indirection you do. But don´t worry, even the Alias guys needed two releases to get this one right [SMILEY Wink]
(L) [2006/09/01] [greenhybrid] [Noise Reduction] Wayback!

I have an intensity factor called A:


Based on the canonical lighting formula (disregarding the distance between the two points):
(L) [2006/09/01] [Lynx] [Noise Reduction] Wayback!

Well there are several ways to reduce variance, but not all are compatible (i think).

The first thing every algorithm should benefit from is importance sampling. Since from what i understand you end up with a cosine in your path throughput calculation, you probably sample uniformly over the hemisphere. That's not optimal, for lambertion reflectors it should be cosine-weighted hemispherical (i.e. direction near normal are more likely since they contribute more).

When you have things like area lights, you can also use multiple importance sampling, i.e. instead of only sampling the BSDF or the light, take samples from both and combine them by some heuristic. That gives advantages when you can't predict the pdf which gives lower variance when importance sampled.


Another technique is quasi-monte-carlo (QMC), i.e. you replace the random numbers with low-discrepancy sequences, which results in faster convergence. But, i don't think LD-sequences work with metropolis methods...but i still haven't found the time (and motivation) to read through all that. QMC It also causes headache about correllation problems, but there's also a great advantage: It's strictly deterministic (read: trivially threadable).

And as already said, the choice of algorithm has a large influence on convergence..."basic" path tracing, bidirectional path tracing (Lafortune, Veach), MLT, energy redistributed path tracing (ERPT, apparently simpler than MLT, but similar in results), and even more...
(L) [2006/09/02] [greenhybrid] [Noise Reduction] Wayback!

okay, then let's talk about importance-sampling.


what I am currently doing is kinda:
(L) [2006/09/02] [greenhybrid] [Noise Reduction] Wayback!

Fixed it: Now I am using every direction produced (where the selection is pdf'd), record a totalP  (totalPD = totalPD / currentPD, where totalPD is initialized with 1) and finally scale the color according to totaPD
_________________
[LINK http://greenhybrid.net/ greenhybrid.net]

Real Men code Software Graphics.
(L) [2006/09/02] [Lynx] [Noise Reduction] Wayback!

Err...i have like no idea what you're actually doing [SMILEY Smile]


Importance sampling here means: Make the distribution of generated sample-directions fit the actual function as close as possible (e.g. use BSDF as best guess, if we knew the shape of the integral, we wouldn't need to integrate it...).

Or in other words: bsdf(dir)/pdf(dir) should be as constant as possible over all directions. So you need to change the function that transforms a uniform distributed 2D-sample in a spherical direction to fit the BSDF characteristics. For lambertian reflectors you only have a cosine falloff for the incoming direction, so your sample distribution should have a cosine falloff too, and not uniformly sample a hemisphere.

So you sample important directions more often than unimportant ones.


The first code snippet looks pretty much like russian roulette, only i'm not sure about the purpose.

Looks like you transform your apparently uniform distribution of directions into another distribution by randomly rejecting samples according to a pdf...? That would mean p does not reflect the probability of the actually chosen direction but the wanted probability, and if it does the whole code makes no sense at all to me...so what does randomDirection actually do?

The second one looks like a weird mix of rejection sampling and russian roulette to me...no idea.


For an unbiased path tracer you of course still need to terminate the path somewhere, so there you need something like russian roulette, but that's again an example where you increase noise over a biased path tracer with hard limit on path length. But i don't see what that would have to do with the pdf of your current sampling direction. I'd either use a fixed probability for path termination, or maybe base it on the path throughput, i.e. after you hit a couple of dark surfaces you stop on average earlier than when you hit a couple of strong reflecting surfaces...
(L) [2006/09/02] [greenhybrid] [Noise Reduction] Wayback!

oops gave some bad examples, sorry.


RandomDirection does simple overall-distrubution and just returns the dot product of normal°newDirection (=cos(angle)), so in RandomDirection there are actually no probabilistics.


I had problems with the normalization, which I now have fixed.


btw I just have finished (correctly) the new algo, which connects each point of the path with each other. Results are quite good. One could say "net-tracing" instead of "path-tracing" to it, heh, just kidding. That will be a good base for bi-directional-path-tracing.


Thanks for help so far.
_________________
[LINK http://greenhybrid.net/ greenhybrid.net]

Real Men code Software Graphics.
(L) [2006/09/04] [Ono-Sendai] [Noise Reduction] Wayback!

Some ones i use for indigo (www.indigorenderer.com)

* multiple importance sampling: basic technique that is very important, and serves as a foundation for more complicated algorithms.

* bidirectional path tracing: not perfect, but depending on the scene, can display vast improvements over standard backwards path tracing, particularly for small light sources in the presence of specular surfaces etc...

* metropolis light transport: This one's a strange one, can help a lot in difficult scenes, but has some drawbacks (firefly artifacts etc..).  Kinda tricky to implement as well.

* importance sampling of bsdfs: totally essential.
_________________
[LINK http://indigorenderer.com/]

back