interior test [Distributed Path integrator explained]

[jeanphi]

Hi,

Ok, that's what I thought, but wanted to be sure to avoid confusion. Actually Luxrender uses both explicit and implicit algorithms with multiple importance sampling between both methods: if you have a large light source and a nearly specular glossy surface, it's more efficient to use the implicit algorithm, but if you have a diffuse surface and a small light source, it's more efficient to use the explicit one. So Lux computes both, estimates the most efficient and weights the contributions accordingly (E. Veach's thesis has a very good explanation of all this and is a must read for anyone interested in unbiased rendering techniques).

Regarding the bug with direct lighting, I'll have to try and reproduce, this is the first time something similar is reported.

Jeanphi

[Electro]

Ok thanks

Some tests with the Distributed path integrator

light source not visible

glass with dispersion

caustics visible in glass reflection but not on diffuse surface pixelsamples 6

My settings for the first two images were
low discrepancy hilbert at 4 pixelsamples
10 bounces for diffuse glossy and specular(reflect and refract)
4 samples at the eye vertex for diffuse and glossy (reflect and refract)
the third image was the same except it used 6 pixelsamples

When using the distributed path integrator you should set all the number of
samples at the eye vertex the same and at least to 2 (excluding direct/indirect),
using only one will act like regular path tracing. For example if you set the diffuse
samples greater than the glossy samples the matte objects will converge faster than
ones with glossy or roughglass this can be seen well when a glossy material reflects
another. I rendered the prism first with 2 samples at the eye vertex then with 4 samples
as in the first image, the results were that i got the same level of noise in half
the time with less samples per pixel. More vertex samples is always better due to
less variance in the samples but there is more overhead because of all the extra rays
in the scene. Since the integrator doesn't have russian roulette yet to cull the
paths it can be tough on heavier scenes and lowering the bounces results in
a lot of bias but more reasonable rendering speed.

great work guys

-Electro

[SolaraSolarwind]

That looks like a very detailed render!!!

[NiZu]

Hi,
a few more things i noticed experimenting with museum and sunsky in general

- hilbert samples as last thing : it's best to raise that value as last thing , (Edna said this also)
hilbert samples affect all other light / materials parameters , it's often better to raise only the parameters that need it.
Just don't forget that they work as antialias too. ( 4-8 hilbert samples won't be enough if you have 1 pixel thin objects)

-Direct samples: can solve problems with sunsky , raising them will remove noise in 'penumbra' areas (in other engines, those areas would be 'soft shadows')
Relatively large number of samples (like 4-8x indirect samples) can help the picture converge fast.
They can also help with situations like the "LD vs MLT" pic ... mlt is not the only way to solve that soft sun shadow , 8x direct samples solved that well , however increasing the relative size of the sun (softness) it wasn't enough anymore (mlt did it , but took his time)

-Glossy is expensive : i said that , but it's so important for visual quality that i tend to forget it .. even for 'near matte' materials makes quite a difference. (my environments are always mostly glossy mats )
Anyway , try 'glossy bounces number' set to 0 ... and you'll see the difference in speed , quality might not be acceptable , but it will sure help in identifying noise sources in your scene.
While It seems that adding 1-2 diffuse bounces doesn't slow down the render that much (except for matte transulcent) , each glossy bounce instead requires more samples and time.

[ckbrd]

Glossy materials are expensive in all render system actually not only Lux.

After reading this thread I was going back to a scene I did with Yafaray
a typical cornell box rendering and I was surprised to see how color GI
differences were different, I liked the Yafaray results much more than
actually the Lux one. While with a previous jewelry rendering Lux simply
kicked out more realism.

I am also curious about the photon finale gathering system and the speed
for it.

[NiZu]

Hi,

Yes glossy are expensive in all engines , but i got the impression that yafaray and lux (that use exponent) aren't slowed down too much by a very low exponent , while other engines (like BI) get exponentially slower with low glossy values (below 0,7)
I don't know much about the code behind this , but i think lux (and yafaray) are designed make heavy use of raytrace ..so glossy does come more 'natural' to them ,
So, i got over-confident and forgot that is still slower , expecially multiple glossy bounces ( my previous post was in particular about glossy 'bounces' and the fact that "0" doesn't mean no glossy but "only direct light glossy" )

The photon gathering system : i haven't tested it much ..but imho .. both in yafaray and lux , it's not significantly faster than other methods (with similar raydepths)
The fact is, that in both engines 'final gather' is somewhat "brute force" raytracing , in the sense that doesn't use interpolation ( to give smooth results with sparse samples )
That's just my guess , but i've seen average rendertimes of 5-10 up to 40 hours with lux photon map for final quality interiors (and similar with yafaray )
On the other side, for example , Vray's light cache is more similar to bidir (as integrator) .. but heavily blurred and interpolated (and that's the sampler part)
Imho it's the sampler part what makes a 10x speed difference , while integrator speed (photon FG or distributed path) depends on setup.
(note : qmc ..is it related with this? i must learn more about QMC..)

About gi / color / realism .. jewelry sure benefits from lux materials ,
But in general , when using lux more biased setups ..result varies a lot same scene with diffrent light sources and dp settings can look photoreal or very fake-cg.. rendertimes vary accordingly.. i'm confused too,
but actually that's good , i think , for archviz renders you need great flexibility : from a 10 mins wip-preview up to 2days if it's going to be a book cover.. ideally without redoing everything .. (same engine and materials but different sampler / integrator)

[ckbrd]

Well I am not sure what VRay uses but they are painfully fast.

Also keep in mind that Blenders raytracer is to what I know not optimized
and still based on the old code. BI is great as long as you do not really use
raytracing.

Interesting that you say that PM and Pathtracing gives you same speed
results in Yafaray.

Well in the VRay manual they also mention that PMap is considered an old
and outdated method which I think is why they rather feature the other
two types.


Most interesting what you say about the integrator. Man Lux has so many
options I dont understand them all based on the manual. I hope one point
I can use it because I know how Lux works instead of hoping to click together
a good fit.

[NiZu]

Hi,
I didn't mean to say pm and path tracing give same results , whatever the engine path tracing is very bad in interiors , it takes a huge number of samples (rays from the lightsource ) to converge , maybe 5,10 times slower than PM.

Photon map also starts from lights and 'blends' those samples (sort of : it counts how many are in a certain area)
But then FG casts rays from every point in the scene to refine the result.. So they both produce a fine noise .
think also at direct+ao and ibl sky (yafaray) : that can take hours too (in interiors): it's not a complex integrator , but since it needs many samples per pixel to clear the noise in some unlucky cases that can take forever ...
So PT , PM , AO give very different rendertimes ..but in some cases they all get in troubles.

I suspect vray's "reliability" secret (apart from years of developement , cash , talent and continuous optimizations ) it's in the ability to take samples where needed (on the picture) and nicely blend them togheter.
With light cache, having a single sunsky ray each pixel doesn't produce noise (as PT would) but maybe 'splothces' and surely will ignore small details.

(on the contrary MLT i guess is a different philosophy as it tries to find most useful ray paths ..but it's based on having many samples per each pixel.)

Don't ask me what's better it's speed vs catching small details .. with chances of some very unbalanced solutions

[psychotron]

also vray use 'early path termination' or something like that.. dark shadows are more noisier

[NiZu]

I've never heard of that , but i think i know the effect : technically there is lot of noise in dark shadows but it's not noticeable (unless you boost contrast insanely) ..the same amount of noise would be problematic in bright areas , but in shadows goes unnoticed..

Btw i came accross this post by radiance: http://www.luxrender.net/forum/viewtopic.php?f=8&t=1415&st=0&sk=t&sd=a&start=10#p12381
Imho, that sounds great .. let's leave speed aside (which indeed involves lots of factors)
i keep thinking of "reliability" ..what i mean with that, is the ability of vray to perform well in all situations: interior , exterior , natural or artificial ...doesn't matter much... That's priceless for end-users as it makes everyday life easier. It gets confused with just "speed" ..because it's hard to notice how many details you loose to keep rendertime low and predictable.

A good example (actually, the reason why i started wondering about this )
Compare skylight in an interior room with 1/8 of openings in walls ..Light cache does 100s of light bounces in minutes .. but misses lots of details ,
Yafaray ibl (=direct light raytracing not interpolated) is very slow in comparison ..but surprisingly it reaches almost every point of the room (you'll need tonemap to see that) and every small detail with just direct light ..a depth of 1 bounce but done with great accuracy.

So apart from my natural hype for possible features , this is interesting in relation to bidir and dp setup (using LD or MLT ): since they aren't interpolated (or not much) a sigle light source or material that gives less ,sparse , scattered samples will slow down everything.
As end-users this is important to know .. with lux dp and (yafaray light samples as well) if the cause of the noise is a single lightsource or material.. is very inefficient to raise all values!