interior test [Distributed Path integrator explained]

[NiZu]

Hi,
i kept learning and testing with lux 06 rc5 recently , a few corrections to things i said previously came out :

-Bidir and mlt , indeed the convergence speed is much better than before , so i think : if you have a scene like my 1st test (simple uniform light) , you'll still get very fast result with hilbert + dp . But if scene is more complex, and you need to mess around with all multipliers (direct ,indirect , glossy , refraction , etc..) then it might be much easier to switch to MLT and bidir .
So , if a scene with simple,uniform light renders in 30 mins with hilbert+dp that's nice but then you add more lights (with complex paths), more objects , complex materials ..rendertime goes up (2-4x) , and the solution might not be to go mad tweaking dp samples ,but try switching to mlt (and maybe bidir)
Mlt also does a good job at smart sampling lights and complex materials , result is a uniform noise ...that 's good because having all all parts of the scene (and lights , materials ) converge at similar speed and samples number means an efficient use of rendertime.
(and that's what you obtain 'manually' by tweaking samples multipliers in dp )

-i advertised Durand tmo in Qtpfsgui : it's broken in 1.9.3 , no decent result seems possible , use 1.9.2 or earlier to try it : it can keep natural lights and color , does a great job turning burnout areas into nice 'reasonable' highlights.

- i suggested glossy with low exp. and value for wall paint : can be good if you want a look of varnish glossy paint . the other option is matte with oren-nayar and a high sigma . see this thread here on the forums (thanks to the authors!) :
http://www.luxrender.net/forum/viewtopic.php?f=13&t=2476&p=21548&hilit=oren+nayar#p21548

[NiZu]

Hi,

another test scene : i modelled this a couple years ago as test case for indirect lighting (sunlight must bounce a lot to reach foreground objects )
it's also a good test for compositing/tonemappping as the areas in direct sun light are necessarily much brighter than the rest .
It's based on M.C. Escher's 'covered alley' , too bad my model is a bit too clean and cad-like (done in Rhino , really great app, but painful meshes ..polycount, topology ) the scene would deserve a remake in blender ..one day.

Setup is MLT+BIDIR : so why it's here ? because it's the same scene as 'MLT vs. LD' (example on page 4 of this thread) , which was very hard to solve with LD+DP . MLT instead had no problem why a far, soft sunlight . This took 4h but after 2 was already quite good.

In qtpfsgui , i used durand tonemapper , that and 'mantiuk' (if used with 'contrast factor' around 1 ) are very useful tmos (tonemapping operators) : they don't alter the look and photorealism of the picture too much ( 'fattal' and default mantiuk give an 'illustration' look ..nice, but not always desiderable )
Reinhart also doesn't give that illustration look , but can give a problem of reduced contrast when you set very high 'burn' (light adaptation) , or at least i need a lot of time to balance high burn vs. good contrast with reinhart , with durand it's just about moving the 'base contrast' slider until you're happy.
Durand is the slowest tmo ,unfortunately, but mantiuk isn't that slow .. so maybe could be useful in luxgui ?
(it's still , much slower than reinhart , not really 'interactive' and likely a significant waste of cpu to update while rendering)

The pic you see has also been composited with an ao pass from blender internal ..(i know someone is thinking: whaat?why? ) i just wanted to see if it would look better or not , and imho it does .. a 4h render with bidir shouldn't need ao to look better ..and indeed it's not a matter of lighting, but of simulating dirt ..
This test made me think ... AO is always somewhat useful (except for hyper clean environments) in the form of 'dirtmap' , better if used to blend two textures and not a generic 'black ao' . So imho it's useful even with accurate, physically based engines but as a material / texturing thing not as part of lighting..
(i'd love to see something for blender ,one day, that works as a simple texture slot like vraydirt ..but it's stored and not re-calculated each render ..would be great:) the current ao bake isn't bad anyway.. )

edit : i wrote "mlt vs. bidir" actually was mlt vs. ld a comparison pic on pag.4 ,which, btw was done with rc4 , from rc5 the convergence speed of mlt is better

[pckmark]

NICE

When i read that this took 4 hours, my jaw dropped to the keyboard. This is amazing. The render itself is very beatifull. I think you should consider this for the gallery if you feel like it.

The Chromatic Aberration might be a bit to much for some people, but i usually crank it up like this when using DoF. Well, i like it.

Im looking forward to see more from you. The quality of your work is exceptional. Luxrender really benefits from contributions and hacks(if i may) like these.

[NiZu]

Hi, i'm glad you like it ,
I think this scene has great potential ..(but then again, it's a copy of a work of M.C. Escher ..)
My idea is to remodel it in blender, with bevels ,some more detail, a nice topology that works with displacement.
(and make the .blend available , i didn't with this one because of the bad topology .. a pain even to just browse the scene ..)

the rendertime : it's good, in a case i've seen even better (the haunted hallway with mlt render in 30mins..) But ..also much worse cases..I still need to get used (understand better) the parameters. i said nothing of setup because i'm still 'familairizing', anyway i think:
--mlt doesn't slow down with some complex lights , like sunlight softness (even 20-30)
-- mlt+distributed path: doesn't require to go crazy with the sample multipliers (so far leaving all to 1 seems good and fast ..but i haven't tested enough) , while cutting bounces numbers still works well to speed up.
--the devs are doing a superb job well.. that was obvious, but still to remember , as development goes ,on mlt gets smarter and with better stratification .. i thought MLT was just about better quality but now i see it can mean speed too.
For the advanced params, see this thread : http://www.luxrender.net/forum/viewtopic.php?f=16&t=2593&p=22274&hilit=+metropolis#p22274 Jeanphi explainations are clear ..It's the subject is nasty.. pro/cons aren't easy to evaluate. i used insanely low values in advanced ( LM.prob = 0.001 max.rejects = 8) here it worked , in some scene it can just reduce quality without speed gain , in others can cause artifacts or slow down (that thread has some info on that)

Regarding hacks .. i don't think i succesfully found a single 'hack' (i tried ) all good things i learned, work thanks to the flexibility of lux itself , and are part of the standard behaviour of the app.
Anyway , speed usability and physically based ...there isn't all that conflict that one may think , or maybe there still is now, but there won't be in the future (and i mean thanks to software development not just faster computers)

About chromatic aberration .. i'm a big fan , i think of the cameras BBC had in the 70ies .. really , really terrible!
but sometimes the effect is .. fascinating , like http://www.survivorstvseries.com/The_Enemy.htm

[NiZu]

Hi,
once more i post a correction to something i said -not really explicitly- but could have mislead or confused someone, sorry if it happened ..
i guess this is natural in forums, i discuss and study things even if i'm no expert , but since post are public material they can be seen as 'manuals' , often it's also easier to write a post like a manual (with disclaimer) and correct later ..
I see professional forums as a blend of 'friends talikng about job at pub' and 'international science research magazine' ..can be kind of hard to say how proven is what you're reading , right ?

So, this is the issue : in path tracing rays are cast from camera not from lightsource
i said they started from the light source, i was wrong.
It's Photon map that casts rays from the lightsource ( bidirectional does both ).
" The distributed path tracer is an extension of the regular path tracer. Instead of selecting a single reflection direction, it will select multiple and spawn additional rays along each direction. The number of rays to spawn is configurable per material type (diffuse, specular and refraction)"
(quote from lux documentation "render settings")

I got the first hint (that i was wrong) when Jeanphi posted about distributed path (and how direct light is handled in this integrator) he said DP shoots a ray from the camera ..and i understand now that's just normal pathtracing behaviour.
Sorry again if i confused anyone , this infos are in the manual , i swear i read it many times before, but.. took time to really get into my head


On to something different, a comparison pic , about how mlt can be good for speed :
What's interesting about this pic is that MLT is converging faster in this scene.

SAMPLER
--top: MLT (lmprob 0.014 , max.rej 16)
--bottom: HILBERT samples 16
INTEGRATOR:
distributed path 3diffuse bounces, 0 glossy
LIGHTS:
mesh emitters for artificial lights , mesh plane on windows for sky
time: (each pic.) 30mins , 2 cores q6600 (luxrender rc5)
(WARNING: This are very biased settings , as such, depending on the scene they might produce artifacts , generally incorrect lighting or simply not bring any advantage respect to reccomended settings !!. again, the interesting thing of this scene is just that mlt is clearing faster than LD )

[jeanphi]

Hi,

Your example is also very interesting in that it also clearly shows the kind of artifact that is to be expected when setting the max consecutive rejects too low: bright parts are too dim. Actually areas brighter than 16 (in this case) times the mean intensity will appear dimmer because they won't properly accumulate samples.

Jeanphi

[SATtva]

I just want to say that this is one of the most informative and insightful threads in the forum. And the must read for anyone wishing to take advantage of DL integrator. I tried it several times myself, but dropped it all the time due to the absence of any documentation on the subject. Thank you much for the great work done!

[NiZu]

Hi,
Interesting, i read about low max.rejects = dim bright areas , i had not noticed in that picture because i had not thought that artifact can happen with very different intensity. i notice now, as you lower max.rejects:
1st , highlights get dimmer but not noticeably.
2nd, some highlights disappear , the pic. seems ok, but things like wall-washer spotlights are lost.
3rd, the pic. clearly show a reduced contrast in lighting , similar to a whased out print (bad inkjet or old photo)

Even if the render doesn't show the 3rd ,evident, level that doesn't mean it's ok (notice how the direct light on ceiling is totally gone at max.rejects 2)
Also this picture was less affected by this artifact than the average (probably because it's a clay render ,i.e. on a pic with black floor and white walls would be much worse)

Regarding speed : the 2 pics rendered for same time ..and have similar noise . But generally low Max rejects speeds up render .
(i haven't done enough tests on this param alone to find a rule..)
Edit : both pics use default reinhart tm seetings , for confronting , but the 2nd pic could look better with different tonemapping settings (not burnt)

Thanks, SATtva i'm glad you found this useful, (and Thanks to everyone who posted infos and tests) i think one reason why DP is little documented is that the params aren't really specific to the inegrator , but are general concepts of raytracing ..definitely DP can be more frustrating to setup than i.e. photon map ..but at least the params aren't that abstract (i mean, photon map defaults work , and give good speed 90% of times ..but when they don't work , i feel like tweaking numbers by just trial and error..)

[SATtva]

Dougal, could you please set a sticky on this topic?

[dougal2]

Sticky done - perhaps the thread title might need to be edited to highlight why it's sticky? suggestions ?
perhaps move to another forum also ?
Anyone want to extract important info + image into a wiki tutorial?
(bear in mind that the aim is that any really good wiki pages will be converted into 'real' pages on the website).