The upcoming (in v2.1) denoiser is going to be very handy for animations. This is a 68 samples per pixel rendering (left plain output, right denoised):
WOW! Outstanding news! Any date of release?
Any date of release?
No, we first have to release v2.0. The denoiser comes after that.
By the way, here you can find more test images: https://forums.luxcorerender.org/viewtopic.php?f=5&t=220
While Rendered viewport preview is active, if in an object you add a new non existing material (assuming that the object did not previously have a material), that material is not updated in the rendered preview until you move the object or something. I do not know if that should be like that.
I fixed this bug. The solution was actually super simple, I just never thought of it.
Also I do not remember if just āMatteā material existed in presets in previous version? Or always there was only āMatte Translucentā?
I have added matte to the presets.
Thank you very much!
That denoiser looks really impressive.
I see several mentions of animation in this thread. Does it mean that deformation motion blur is also to be expected in LuxCore?
How is the denoiser in luxcore different then the one in Cycles?
Results look great, and it seems to handle animations also, so cross-frame denoising? Something the blender denoiser doesnt have yet (almost finished i think)
Is the denoiser enabled for cross frame denoising ? (AKA avoid flickering in animation denoising)
LuxCore will integrate Bayesian Collaborative Denoising for Monte Carlo Rendering algorithms. (BCD)
For animation read the paperat Section 7.
I know, it says so in the luxcore forum tread 
I was just wondering what the difference is compared to the blender denoiser.
Thatās the denoise algorithm i linked to cycles devs on the ML 3-4 weeks ago. Seems very powerful, too bad has been ignored tough.
@Dade, Is there a developer test build available with the denoiser yet or do we have to wait for official release? Cheers J
Sorry forums acting weird, Double post. Ive just had a play with Lux core 2 for the first time, Only a few things I donāt like, No principled shader support (support of the cycles one would be awesome or your own version) No luxcore 2 smooth or auto smooth groups support. Other than that I like it.
Have to do some arch viz renders tonight to see what I can get.
I added it to the feature request thread.
How is the denoiser in luxcore different then the one in Cycles?
It only needs very few basic information about the samples from the render engine.
The denoiser in Cycles needs many extra passes to do its work.
Is the denoiser enabled for cross frame denoising ? (AKA avoid flickering in animation denoising)
It can be implemented, but for now we will focus on getting the single-frame denoising to work with all render engines and OpenCL.
When that is done, we can look into multi-frame denoising.
Is there a developer test build available with the denoiser yet or do we have to wait for official release?
No test builds so far, you will have to wait for v2.1alpha1 after we release v2.0.
Or you compile from source, the denoiser stuff is on the bcd_integration branch.
Ive just had a play with Lux core 2 for the first time, Only a few things I donāt like, No principled shader support (support of the cycles one would be awesome or your own version) No luxcore 2 smooth or auto smooth groups support. Other than that I like it.
We have both of those features logged in our issue tracker, so if we find the time we will implement them eventually.
I worked a bit on denoiser integration in the Blender addon.
Note that this is early work in progress.
The UI, default values, parameter names etc. are not final.
If the luxcore denoiser only needs very little info, isnt the blender denoiser better? Afaik; the more info a denoiser has the better.
If not, why wouldnt we want the same denoiser in blender? The luxcore version also seems faster (realtime)
It uses a different approach. You will have to read the paper for more details, I donāt think I can explain it very well.
Not quite realtime, it needs a few seconds to denoise the image.
However, we implement it as an imagepipeline plugin, which means that you can run it repeatedly while the rendering runs.
So if the denoiser gives a poor result at say 30 samples, you just let the render run a bit longer and try again, and you donāt have to restart from scratch.
It is also planned that you can adjust the denoiser parameters during the render, however I did not implement this yet.
Passes (raw render / denoised) would be useful for eventual post production tweaks.
We should release v2.0 stable version very soon (next days if nothing new come up). We have already a working PATHCPU and TILEPATHCPU (CPU path tracer) on a branch. I think we can release a v2.1alpha0 test build soon after v2.0. So people can start to check how it works.
Iām working on the OpenCL/GPU version and after there will be the support for bidirectional path tracing to add too. They will follow with v2.1alpha1, etc.
I donāt know what kind of denoiser Cycles uses so it hard to make any comment. However BCD denoiser is intended and designed for off-line rendering (it takes between 5-30secs to denoise a rendering, indeed, higher is the resolution and more it takes). It also requires a not minimal number of samples per pixel (i.e. 50+).
It is not the kind of 1 sample-per-pixel real-time denoising you see around nowadays (i.e. they kind of stuff not particular useful for Lux/Cycles/YafaRay/Appleseed/etc. render engines).
P.S. and the major bonus: it doesnāt includes any AI 