Env. Light Visibility Cache

[kintuX]

Isn't SDS issue an MLT integrator issue?
Seems we're forgetting, OCL dev. is more or less stagnant (@ 1.2) & on the way out! i.e No more computing on AMD chips.
"Will Vulkan replace it or will LuxCore become CPU only?"

Dade does the great work and finally he knows what the future of LuxCore looks like.
Also, CPU cores have skyrocketed with higher frequencies (Ryzen 3x supposedly coming with 16 cores @ 4.6 MHz & 12 cores @ 5.1 MHz), w/o having to wait for GPU compilation, animations are a treat Development evolved (with AI algos got much better, more efficient).
While RTX is still low on the industrial map (especially with examples of "code" doing it - HW agnostic).

Sorry for the offtopic, just needed to mention this.

[lacilaci]

While I was not really impressed with gpu development in past 2 years, today I think I'll get a 2070 before I upgrade rest of my hw and the I get even better gpu...

[provisory]

... I'll get a 2070 before I upgrade rest of my hw and the I get even better gpu...

And for your use case it seems to be a logical decision.
If LuxCore had BiDirVM on GPU, I would buy a fast GPU too.

[Sharlybg]

For me bidir is still a very good engine. With now monster CPU (128 threads) and guided tech it can become very amzing.

But back in 2009 Alex roman did this amazing 3rd & 7th animation with super caustics i still Wonder how i can achieve affordably with my current set of Tools.
A faster bidir could help

https://youtu.be/AQ-3aRhvFwU?t=608

[provisory]

By the way what was the problem with BiDirVM, why isn't it supported anymore?

[B.Y.O.B.]

As far as I know it's simply unfinished.
Maybe Dade can explain the reasons why it wasn't developed further?

[Fox]

BiDirVM sort of works, but the lack of MLT is very big disadvantage, the MLT part is broken.
One render that i did the MLT version with BiDirVM looked better at 20 sp to the random with BiDirVM at 1000 sp.
But the bias creeps in fast with MLT.

In bidirvmcputhread.cpp file there is this info:

Code: Select all

		// Using the same time for all rays in the same pass is required by the
		// current implementation (i.e. I can not mix paths with different
		// times). However this is detrimental for the Metropolis sampler.
		const float timeSample = rndGen->floatValue();
		const float time = scene->camera->GenerateRayTime(timeSample);

For me it worked well when MLT worked with 180 x 180 pixel image block,
but when i disable russian roulette, then i see how random has only sampled 2 or so pixels where MLT covered 30000 pixels.
Then it reaches to next pass and reduces radius by alpha, but that 2 pixel samples are not enough info when they are far apart.
So with random it does a lot of work with large radius 100 pixels or so. First 10 passes look fine, but next 1000 passes nothing changes.
The initial bias from first 10 passes doesn't go away when with next 1000 passes nothing happens.

[B.Y.O.B.]

That comment is only relevant if you have time-related stuff in your scene, i.e. motion blur.

[Fox]

That comment is only relevant if you have time-related stuff in your scene, i.e. motion blur.

Oo i see.
What can it be then, the bias is strongest with MLT when largesteprate is close to 0 and maxconsecutivereject is highest value?

[Dade]

I have further improved the building process of visibility map cache entries. This is a normal rendering with 50 samples/pixel:

and this with the cache enabled: