LuxRender is actually a very good renderer. Although I think a better integration is required to make it usable in real work, they put a lot of effort in that direction, so let’s not devaluate it with words like “jumble”. I think we all have to win from the diversity of renderers. The Lux devs didn’t get half a million like the BF did and the render API case is controversial.
Luxrender? Jumble? Are you kidding? The parameters there are clear, unambiguous and perfectly understandable. It’s whenever parameters like “Quality” are introduced that there’s a real headache to understand what’s going on.
Thanks for the clarification, Lukas!
Something like this one http://www.luxrender.net/forum/viewtopic.php?p=85664#p85664 (Multi-stage Noise-aware Metropolis Sampler) ?
Lukas, it isn’t a problem but you have to be careful with the credits of what your work is based on. Mostly because, at the end of the day, it is the only reward for people working for free like me, other Lux developers and you.
P.S. there are good reasons why I do MTL only without tile rendering and tile adaptive rendering without MTL. I have also spent sometime working on Noise-aware MTL (as you can see from the link above) and I must admit I have never been happy of the end result.
I’m suggesting you to implement, may be in another patch, exactly the same algorithm used in LuxCore with adaptive tile rendering with odd/even estimator and without MTL, I’m quite sure people will love it 
I never said Lux wasn’t a great renderer. I love LuxRender, I use it all of the time. But this mess of options isn’t something an artist should have to deal with directly, especially for something as straightforward as path tracing. Additionally, unless you’re a render developer, most of this is going to look like nonsense to you. I’m of the mind that simpler is better, especially in GUI design. Mitsuba knocks this out of the park, and Cycles has done its best to not turn into word/panel soup despite the number of factors that can be tweaked by the user.
Yes, that looks quite similar. I see how that might look to you, but I can assure you that I didn’t use any code from LuxRender for adaptive rendering. As you describe in the linked post, your implementation is based on the same paper, so the similarity is only natural. Thanks for pointing this out, I never looked closer at the noise-awareness in Lux. The algorithms are all self-designed using classic variance estimation, MC theory and trial-and-error.
Another note: This patch has nothing to do with Metropolis, it just originated in the Metro patch. It’s just classic variance estimation, calculating an error for every pixel, averaging them and comparing to a threshold, plus some CDF sampling for the per-pixel part, nothing fancy. I realise that in FOSS software, giving credit is a requirement, and if you look at https://developer.blender.org/T38401 and my first answer, you’ll see that I always mentioned my sources. I really like LuxRender (I even have made a tiny commit :D), am impressed by the cutting-edge stuff in there and would never steal/copy code from it without mentioning.
The problem with the even/odd-estimator was that it produced correlation artefacts with the Sobol sampler, and I found it to be slightly less stable/more noisy than the classic variance approach. Tiles for Metro aren’t that great, I agree (the biggest problem seems to be the mean brightness estimation, which also makes noise-adaptiveness much slower since after each importnace change, it must be done again), but Cycles is designed around tiles so using no tiles was really hacky (even the progressive mode uses tiles internally).
Trying out other estimators might be interesting in the future (it’s still in experimental to make this possible), but currently I try to get this accepted so that more people can start trying it out.
EDIT: Pressed Reply too quickly…
FWIW, you DO have “advanced” settings enabled. Most of those are hidden in there because they’re arcana that rarely needs to be changed anyway.
@m9105826: Not sure what point you were trying to make by posting that pic. The options seem pretty self-explanatory to me. Yeah, some of the options require a little rendering knowledge to use (like the Mitchell filtering B and C params, heh), but IMO that’s just the nature of the beast. A render engine is not an idiotenkamera, and it shouldn’t be.
I think the ones he has planned to expose are pretty self-explanatory and shouldn’t contribute to a ‘jumble’.
Error - could be renamed to ‘noise tolerance’ as an easier to understand term, the value would default to what would make a perceptively noise-free image at modern resolutions for the vast majority of cases.
Interval - simple to understand once you figure it out, just how often the adaptive map is updated, the warmup value can also simply be hardcoded to be twice this value and thus hidden from the user.
enable adaptive stopping - Could just be a checkbox, this stops the rendering once every tile hits the threshold or moves on to the next frame in an animation, could simply be renamed to finish at tolerance threshold or something less ‘techie’
The exponent meanwhile by now can also be hardcoded to 4 since, as he says, he sees no other reason for different values based on his own tests. With only three options added, it may not even be enough to necessitate a new panel even.
EDIT; and I just forgot, we would have a checkbox for the use of adaptive sampling in general as well, which checking will reveal the error and interval settings.
I prefer ‘error’ because if you change it to a long string like ‘noise tolerance’ and put it next to a slider, what you’re going to see just ‘noi…’ a lot of the time. But this is bikeshedding really. Both are fine. Hardcoding warmup as 2x interval? If it works well, LGTM. Someone should test it though. And yeah, adaptive distribution and adaptive stopping should probably just be checkboxes in the sampling panel.
It could be renamed to error tolerance as well if that would work better, the addition makes it a little more self explanatory on what it is.
enough talking. now…
gimme a build!!! 
Sorry this was nonsense.
This too! :o
Cheers, mib
Hopefully, this is the day we get the long awaited Win64 build from Lukas. I really can’t wait to see just how much progress he has made in improving the adaptive sampling code. 
Well he did say one or two days, so theoretically the build should be up today.
Ace, the kernels in my post should work for Windows too, rename your experimental kernel and use my kernels for testing.
Does anybody read my posts?
Cheers, mib
Okay, your solution, at first glance seems to be for rendering with Nvidia GPU’s only and not for people like myself who use the CPU for rendering. If this is not the case, then I would like to know exactly what I should do here to make it work for CPU.
I would really prefer a ready-made Win64 build because it’s not exactly easy to determine which files need to go where under what name.
Ah, sorry, it is only for Nvidia GPU you are right.
I think sometimes anybody use GPU for Cycles but many don´t.
I hope Win CPU users get there build next days.
Cheers, mib
Ever considered learning to build, Ace?
I slogged through it, it took about a week to figure it all out. Since you aren’t worried about CUDA support, you have it even easier than I did. I had to give up once I realized that in order to get it to compile with CUDA and 64bit I needed to have Visual studio pro, and I’m not investing $500 in that.
But seriously, building blender is no more complicated than operating blender.
I only mentioned hope for a build due to Lukas’ post saying he’ll try to get a new version ready with complete builds around today, give or take a day or two depending on factors like time availability. I wasn’t intending to try to be a beggar or anything of that sort.