There are situations where some settings may be preferred, although with a more biased / worse result, but faster, could be interesting to have a "draft" configuration, or some of these settings exposed as advanced.
For what i can understand there is no such parameter inside Luxcore.It isn't build this way.
Only ways to introduce bias is with stuff like clamping or PGI cache ... what we discussing is
that engine like cycles do introduce internal bias user don't see on the surface. Lux don't do that.
So my idea is to reveal that difference.
The idea of the RR settings, Dade you said that the worst situation could be perceived as 6 times faster, this is just because the numbers or because it reaches an specific amount of noise faster but with more dangers like more fireflies? or is the other way around?
It just look faster because of the samples/sec number (6.12M samples/sec) but in reallity it converge slower because of the small amount of rays/samples
But check the "rays per samples": the first one traces ~36 rays per samples while the last one only ~4 per samples. Clearly the last one is perceived 6 time "faster" ... but it isn't, it has just more noise and potentially fireflies.
So I think RR doesn't introduce bias for speed as tradeoff.
One of the things I noticed when working with LuxCore is that we have very small room for tweaking, and while I think this is something that should not be exposed to new users, could be interesting to have access to these settings that can give us more performance at the cost of quality, specially when we have to show quick drafts and things like that.
What do you think?
I think that nowdays there are multiple way to speed up a render engine while being ""fully unbiased""
a recent numerous papers just show. And introducing aggressive bias in engine tend to break lot of code
like bidirectional or light tracing.
I remenber clarissefx have something to filter fireflies without clamping
Dade wrote: ↑
Mon Mar 23, 2020 9:51 pm
Sharlybg wrote: ↑
Mon Mar 23, 2020 4:56 pm
Clarisse Fx or Octane one ? is it better If yes can we add it ?
If I add the their sources...
The PDF based clamping is an old JeanPhi's idea, he tried an implementation based on local vertex path clamping and it didn't worked well however I think the idea may work if considering the complete path PDF.