LuxCoreRender Forums

I added the support for Albedo AOV to OpenCL path tracers.

epilectrolytics wrote: Sat Feb 02, 2019 10:58 am Just found the same. I think this is a bug in Luxcore.
I made a comparison with Cycles normal pass which somehow doesn't contain texture normals, only object's, but it is definitely smooth and not aliased as the Lux AOV.

Sincerely, it is a bug in Cycles:
- LuxCore saves normals after normal interpolation and bump/normal mapping;
- Cycles saves normals after normal interpolation but before bump/normal mapping;

Or you use geometry normals (i.e. no interpolation, no bump/normal mapping) or shading normals (i.e. interpolation, bump/normal mapping), Cycles uses something in between and it is likely to be just a bug.

About the noise/aliasing, I may know ho to fix the problem.

Dade wrote: Sat Feb 02, 2019 12:04 pm
Sincerely, it is a bug in Cycles:
- LuxCore saves normals after normal interpolation and bump/normal mapping;
- Cycles saves normals after normal interpolation but before bump/normal mapping;

Yes, that is a bug in Cycles. (Though there might be uses for a pass with geometry normals but without texture normals, I don't know).
We were just trying to find out if other renderers do normal pass antialiasing because we couldn't find anything in the OIDN docs.

But what B.Y.O.B. discovered:

B.Y.O.B. wrote: Sat Feb 02, 2019 10:39 am I looked into the code, the shading normal AOV does not converge. Every new sample just replaces the old value

is a bug in Luxcore, no?

About the noise/aliasing, I may know ho to fix the problem.

Great!

Ok, so we have a proper albedo(assuming it gives desired result as far as I've seen), we'll get fixed normal pass, and we're golden, right?

lacilaci wrote: Sat Feb 02, 2019 12:59 pm Ok, so we have a proper albedo(assuming it gives desired result as far as I've seen), we'll get fixed normal pass, and we're golden, right?

I think so, because our developers are used to fix things in (nearly) no time

But given that you have the denoiser already running:
You could make a test with Cycles and a displacement bump on an object (some rock PBR material) and render with no colour but the Cycles normal pass which apparently has antialiasing.
Then we would know if it improves Intel denoising.

epilectrolytics wrote: Sat Feb 02, 2019 1:15 pm

lacilaci wrote: Sat Feb 02, 2019 12:59 pm Ok, so we have a proper albedo(assuming it gives desired result as far as I've seen), we'll get fixed normal pass, and we're golden, right?

I think so, because our developers are used to fix things in (nearly) no time

But given that you have the denoiser already running:
You could make a test with Cycles and a displacement bump on an object (some rock PBR material) and render with no colour but the Cycles normal pass which apparently has antialiasing.
Then we would know if it improves Intel denoising.

not until monday probably... Gotta do some photoshoot this weekend.

B.Y.O.B. wrote: Sat Feb 02, 2019 10:39 am I looked into the code, the shading normal AOV does not converge. Every new sample just replaces the old value

I think a normal AOV cannot converge because it has no shading, like albedo. It should be done in one pass.
Except maybe DOF where the background blur has to converge.
Probably it should be antialiased (like Cycles does) even when that produces incorrect vectors at the borders.

Your albedo image shows black shapes for refractive and reflective bodies.
I think that's wrong, it should show the albedo of the refracted/reflected objects behind/beneath instead, or the denoising won't be improved in those areas.
That will probably not be visible in this scene but in other settings with mirrors or glass panes.

I downloaded the Mac version but don't know where to put the images to get them processed so I cannot test it myself

Dade wrote: Sat Feb 02, 2019 12:04 pm Or you use geometry normals (i.e. no interpolation, no bump/normal mapping) or shading normals (i.e. interpolation, bump/normal mapping)

Side note: we have 2 AOVs for normals, GEOMETRY_NORMAL and SHADING_NORMAL.

My guess is that OIDN requires the SHADING_NORMAL AOV.

alpistinho wrote: Thu Jan 31, 2019 1:20 pm

acasta69 wrote: Thu Jan 31, 2019 1:01 pm

alpistinho wrote: Thu Jan 31, 2019 11:57 am Maybe that's better than what I am doing. I think this library uses Intel MKL, so that would be another dependency. I will try to compile against the binary later today when I am home.

By the way: which platform are you working on?

Linux Mint 18.3 (Ubuntu 16.04)

@Acasta69: can you add the intel denoiser to Windows GitHub repository like we do for Intel Embree ? I will do it for Linux.