LuxCoreRender Forums

Sharlybg wrote: Tue Jan 29, 2019 8:01 pm

look at crytek sponza at 16spp

Dont't know why but this sponza look like overboosted photoshoped advertising

what do you mean?

I've hard time to believe we can get so sharp detail from nothing. even on heavy GI dominant scene like sponza. look the corner and tile line detail. where do all theses detail come from ? If it is true luxcore is not a render engine now it is a "REAL LiFE ENGINE".

Maybe it is possible who know how wild computer science can be theses days

Sharlybg wrote: Fri Feb 01, 2019 5:19 pm I've hard time to believe we can get so sharp detail from nothing. even on heavy GI dominant scene like sponza. look the corner and tile line detail. where do all theses detail come from ? If it is true luxcore is not a render engine now it is a "REAL LiFE ENGINE".

Maybe it is possible who know how wild computer science can be theses days

Sponza Compare.Jpg

Oh I understand now...
So, this is the result of having normal pass and albedo pass to recover texture details.
Actually even cycles denoiser can recover this incredible details from noise, however cycles denoiser is pretty bad with smoothing GI and reflections.

With Dade making it possible to output unlit color pass/albedo and normal pass it should be possible to get results similar to sponza out of luxcore+oidn.

PS: the albedo pass Dade posted here seems very nicely antialiased, but last time I tried shading normal pass it looked like no antialiasing was happening. Is this ok?

Sharlybg wrote: Fri Feb 01, 2019 5:19 pm I've hard time to believe we can get so sharp detail from nothing.

All the detail information is in the albedo (and normal) AOV.
It only lacks the lighting information, but even the rough noise when averaged contains this information so it can be used to "reconstruct" the image from the albedo detail.

Cycles denoiser already does this and the Intel one as well.
Cycles also works well on animations, we'll see how the Intel version performs there...

Edit: Laci beat me to it

epilectrolytics wrote: Fri Feb 01, 2019 5:33 pm

Sharlybg wrote: Fri Feb 01, 2019 5:19 pm I've hard time to believe we can get so sharp detail from nothing.

All the detail information is in the albedo (and normal) AOV.
It only lacks the lighting information, but even the rough noise when averaged contains this information so it can be used to "reconstruct" the image from the albedo detail.

Cycles denoiser already does this and the Intel one as well.
Cycles also works well on animations, we'll see how the Intel version performs there...

Edit: Laci beat me to it

Yes I did...

This is precisely the reason I always was complaining about BCD. It has no feature recognition and no aov's that help keep edges and textures sharp. There is exactly 0 reasons to use it and no one does use it.
I always feel a bit bad when complaining about open source software, but luxcore is super fast and easy to use(on par with commercial software) and then you turn on bcd denoising and horror begins...

Not that it couldn't evolve, but last time I checked the bcd development is not progressing and everyone is turning for neural networks for denoising anyways..

lacilaci wrote: Fri Feb 01, 2019 5:32 pm PS: the albedo pass Dade posted here seems very nicely antialiased, but last time I tried shading normal pass it looked like no antialiasing was happening. Is this ok?

I don't think the shading normal AOV can be anti-aliased. It contains normals, which are 3D vectors. If you "anti-alias" a vector, it becomes an entirely different vector, so it doesn't make a lot of sense. Imagine a cube with sharp edges - if you blend over the pixels on the edge where two faces meet, you get some normals that point in a completely wrong direction.
I'm pretty sure the denoiser can deal with this "aliasing".

B.Y.O.B. wrote: Fri Feb 01, 2019 5:44 pm I don't think this AOV can be anti-aliased. It contains normals, which are 3D vectors.

Hm, I thought the albedo AOV has no normals included and therefore the need for the additional normal AOV, which then are somehow combined by the denoiser, no?

lacilaci and me were talking about the shading normal AOV.
I edited my post to make it less confusing.

B.Y.O.B. wrote: Fri Feb 01, 2019 5:44 pm

lacilaci wrote: Fri Feb 01, 2019 5:32 pm PS: the albedo pass Dade posted here seems very nicely antialiased, but last time I tried shading normal pass it looked like no antialiasing was happening. Is this ok?

I don't think this AOV can be anti-aliased. It contains normals, which are 3D vectors. If you "anti-alias" a vector, it becomes an entirely different vector, so it doesn't make a lot of sense. Imagine a cube with sharp edges - if you blend over the pixels on the edge where two faces meet, you get some normals that point in a completely wrong direction.
I'm pretty sure the denoiser can deal with this "aliasing".

I see... But this also means that you can only use albedo+normal pass in hdr mode right? So either everything is hdr or you just use beauty pass for oidn(kinda the same situation as with nvidia).
So probably a realtime viewport denoising would end up denoising only in beauty 8bit pass mode and final renders with all passes and 32bit?

One way or another, if the outputs that luxcore can provide now can get us to the level of sponza denoising in example then it's fantastic. I've recently did small test comparing a 5K render with luxcore and corona and if I'd keep denoising out of the equation, luxcore was way faster (cause it's also using gpu) so a proper denoiser and upcoming GI could make some waves among renderers..

lacilaci wrote: Fri Feb 01, 2019 5:53 pm I see... But this also means that you can only use albedo+normal pass in hdr mode right?

Not sure what you mean?
I think what we will do is: supply to the denoiser the following AOVs:
- Combined aka Beauty (anti-aliased, 4 byte float aka HDR)
- Shading normals (4 byte float)
- Albedo (anti-aliased, 4 byte float)
We will of course use the HDR mode, and I see no reason why we should use a different configuration for viewport renders.

edit: if you are talking about the limitation I had in the optix branch of BlendLuxCore, this was caused by Blender's image datablock which doesn't support HDR data when drawing it through OpenGL. But since we won't be using Blender image datablocks for OIDN, this is not a problem.