Hi,
since it all went nicely with the 2nd scene i've summarized the results of my tests
This is mainly aimed at interior rendering .
Read it , but don't trust it ! : ) seriously, i wrote it as a 'manual' so it's quicker and easier to read,
But i'm really looking forwards to corrections and comments of other users..
I've highlighted in orange suggested values , but i think they only make sense with the explanations , not as 'reccomended settings' by themselves.
in violet are some questions /missing parts / doubts ..
LOW DISCREPANCY + DISTRIBUTED PATH
AND OTHER SPEED OPTIMIZATIONS IN LUXRENDER.
Luxrender is mainly an unbiased , very accurate render , but it's also quite flexible , so it's possible to use it in a slightly more biased
way : with good rendertimes and still being able to use most of lux features.
There are many shades of grey between physically perfect rendering and ultra-fast biased renders.
As example, an average archviz interior scene done the unbiased way means 10-40 hours .
With LD+DP a rendertime of 1-6 hours can be achieved with little sacrifices in setup and a little knowledge of render theory / raytracing.
Render times of 15-45mins can be achieved with significant sacrifices in setup (lights and materials) or , perhaps, with a knowledge of render theory better than mine : )
WHAT IS DISTRIBUTED PATH TRACING ?
DP or distributed path , is a form of path tracing :
" 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)"
In other words ,
distributed path allows you to tweak , optimize and bias the behavior of pathtracing by : A) taking more samples for things that need it (i.e. glossy mats or direct light)
B) choose different ray depth for different ray types ( i.e. glossy are slow but you won't notice if they have few bounces , mirror refraction is fast and looks very wrong with few bounces)
THINGS TO KEEP IN MIND:
-is distributed path complicate to setup ? yes and no. its parameters aren't as abstract as photon map's ones . All DP params are general concepts of raytracing and light physics.
But .. Raytracing and light physics are awfully complicate
This means you can't rely too much on a 'simple' tutorial and manual . What really counts is your ability to understand the scene's peculiarities and adapt your settings to the situation.
Example : this is not a standard interior scene , DP is useful , but difficult part here aren't glossy reflection or sunsky . but translucency ,in setup, the corresponding multipliers have to be tweaked, so to use more render time on the aspects that really need it.
Image by Edna
-what's so difficult about interiors ? they require light rays to bounce around many times and they need to deal with a high range luminosity Beware that 'interior' or 'exterior' scenes aren't that easy to classify : the really nasty interiors are the ones with light coming from outside (sun-sky) bouncing thru obstacles like balconys ,porches or other buildings and then thru small openings (like in traditional buildings) but still producing strong - daylight illumination.
An interior with artificial light only (maybe big panels) or with glass walls isn't much more challenging for the raytracer than an exterior.
Example : this isn't a though interior lighting : this scene geometry is complex , lots of windows , with a real life setup would be very slow to render .
But if you remove sky and place just 3 big light planes it renders in minutes .
It's not obvious and straightforward to Understand how 'complex' your interior scene is.
It's not just polycount , lamp types and materials. but also the complexity of 'light paths'
History museum modelled by Alvaro Luna Bautista for 3drender.com challenges.
-isn't path-tracing bad for interiors? yes .. for the tough ones (see above) , but DP integrator can be tweaked (to some extents) to compensate, and also there's MLT.In the tougher cases MLT changes a lot : Pathtracing rays are cast from camera then they bounce around randomly (with LD), in interiors it could take many bounces before they hit a lightsource and this is a big waste of time. Bidir is good for interiors ,since rays start also from lightsources, they meet more often, and this means efficiency.
But with MLT +path rays start from camera , bounce randomly -at first- but then MLT 'remembers' the significant ones (that have reached a lightsource) and keeps following similar paths ..and this means efficiency too.
example: Low Discrepancy will be very slow to solve this sunsky
Notice how most areas (shadows diffuse light) converge fast with LD ..but doesn't matter much if the sunlit area won't converge !
What makes sun a difficult lamp is the 'penumbra' area : where a dumb (random) sampler as LD sees sunrays only sometimes but this rays have still an important contribution.
This can be mistaken for caustic fireflies ..they aren't : they aren't as bright and much more dense , and the cause of this kind of "strong noise" is different.
Metropolis can deal with them , but on the other hand takes many samples to converge (even for simple lighting)
Same scene solved with metropolis :
To keep rendertimes low , the advanced params of MLT where set very low ..but it's a delicate subject : works sometimes, in some scene it can just reduce quality without speed gain , in others can cause artifacts or slow down.
SAMPLER :There are 3 parameters to decide what's the right sampler for your scene.
1- Samples per second : for the same scene LD+HILBERT 8s can give 1spp/minute , while MLT 4spp/minute . but this doesn't mean much actually .
2- Samples for a clean image : in optimal conditions LD+HILBERT can be noiseless at 32 spp , MLT sometimes requires >3000 spp to clean up.
3- flexibility : LD is faster when lights are simple. MLT will solve any light setup.
So,
try LD+HILBERT for maximum speed ,but if pic is still very noisy at 32-64spp consider using MLT : it could give 100spp in the same time and a cleaner picture. (see example above)
sampler: LOW DISCREPANCY
pixel sampler :HILBERT samples: 8 min. - 16 - 32 max.
This number is the samples computed during bucket cycle , when that's finished, the render will keep going but in "progressive" mode.
Samples from bucket cycle are faster : better stratification , less noise (at a given spp value) but -at least in my experience- the difference between bucket and progressive speed is not much.
Personally i use this rule : i set hilbert samples to 50% or 75% of the final spp to get a balance of render and update speed (meaning i leave to render after bucket cycle up to 16-32-64spp)
For extra quality ,of course, higher numbers can be used ..but if you need to render more than 128 spp for a decent pic, it means your scene would probably benefit from MLT .
example:
The hilbert bucket cycle took 20min (8spp) then i stopped after 1h20min at 24spp. Bloom and glare in luxgui .
on a q6600 4gb ram ,ubuntu, Lux rc4 64bit. 1600x1200 pixels , 200k quads , statues from Stanford scans and the3dstudio.com
Note : this pic doesn't use sunsky but an arealight on windows, this simplifies calculation when using the LD sampler.
INTEGRATOR:Distributed pathThis integrator is very flexible , by tweaking the number of samples and bounces per each 'ray type' it can be very fast.
Ray types and corresponding materials :
DIFFUSE - MATTE materials
GLOSSY - GLOSSY materials
SPECULAR - ARCHITECTURAL GLASS , MIRROR
Specular in Lux doesn't mean 'fake/pointlight - highlights" as in other engines ! instead, it refers to a raytraced , mirror-like reflection or refraction !
Ray depth (or number of bounces)more bounces means more rendertime, so use them wisely :
REFLECTION:DIFFUSE : this is the main component in normal scenes , relatively fast to render -
3 bounces can be enough for close light sources (e.g. artificial)
GLOSSY: important but very expensive ,
1 bounce can be enough for most scenes (unless your average material has very high glossy reflectivity )
consider also using 0 bounces : glossy will happen only for direct light , depending on the scene it might look very bad (no errors or artifacts, just dull and unrealistic) or might save lots of time
SPECULAR : fast , important only if you have mirrors seeing each other and some objects are not shown in them (
6 bounces)
REFRACTION:less important than reflection for lighting the scene, but can give incorrect shading (ugly,dark materials) if not set high enough.
DIFFUSE , GLOSSY: for thick rough or normal glass objects
1-3 bounces can be acceptable .
SPECULAR : important ,
6 bounces is good / minimum . when using architectural glass (reccomended for speed) this will control how many layers of glass you can see thru. 6 means you'll see thru 3 glass panels max.
Samples number Theese are multipliers to focus the calculation . In general terms, more sample means slower render , but raising samples only for a specific ray/material type (glossy, diffuse , etc..)
is a key for optimization.
That's why i suggested low values for the sampler , 8-32 spp is the base. but that value is multiplied by these sample values . (only where necessary)
- high number of glossy samples . (probably the single most significant optimization i found yet.!!) glossy reflections require much more rays and samples to converge (than diffuse) so : 1 glossy / 1diffuse samples means that, by the time you have 10 glossy samples, the image is still noisy because 10 samples for glossy isn't enough ..but you're wasting samples on diffuse rays that are already noiseless.
i generally use
1 diffuse sample / 4-6 glossy samples .
Again, this are some general rules and some based on the average interior archviz scene , but adapting them to your scene is very important (see 1st example "not a standard interior" )
Note : When using MLT theese multipliers are much less important. In many cases MLT ability to find the most significant path works better than shooting many rays (=increasing samples) like for direct/indirect and glossy.
REJECTIONRejection means ignoring samples much brighter than the existing ones , this aren't errors , but require time to be solved , so if you're going for speed , you'll want to simply ignore them.
This parameter is a 'treshold' : a high value of 10 means that samples whose brightness is 10 times or more than the existing are discarded , a low value of 1.1 means that even samples just 1,1 times brighter than existing are discarded (rejected)
So,
a low value, close to 1.0 , means heavy rejection , less chances of fireflies , but also means discarding some useful samples thus having a more contrasted , less detailed and less realistic result :
this might be barely noticeable or leave some ugly and noisy 'shadows' (totally black areas) that will take ages to converge.
This ugly noise patches happen in areas with a light much dimmer than the average, generally these correspond to areas of 'very indirect' light (areas that are many light bounces away from the emitter )
So, start with
10 or 5 ,
then reduce only if needed .
Note : EFFICIENCY:With the above settings you
should get an efficiency between 500-1500% . in that case the picture should converge with 8-32 spp.
Or up to 128 spp if you have nasty materials (rough glass , translucent) and distant lightsources (sun, sky)
If your pic is still very noisy at 32 spp , and efficiency is below 200% Try this :
Raise
Direct and indirect samples to 2-6 ( the ones next to buttons directALL and indirectALL) until efficiency is around 1000%
This is related to scene complexity , not much to polycount but rather the complexity of the paths of the light
EDIT: added paragraph on rejection
EDIT: after lux 06 rc5 mlt+bidir converges faster , so what is said here is still basically correct, but the speed advantage of LD is less significant now , also MLT has the big advantage of solving more complex light setups. edit: changed a few lines based on things discussed in further posts .
edit: no part 2 , i wanted to put there material /sky speed tricks (light panels on windows, matte materials)..but they aren't really useful and often create problems ..they are discussed in some posts , but at this point i have more confidence in mlt and other 'proper' solutions (which are getting faster , thanks to the great work of Lux developers)
