OpenImageDenoise

[lacilaci]

And last example with super heavy GI noise...

I'll stop spamming now

[epilectrolytics]

sometimes there's a gradient on the object that doesn't make sense and becomes completely black, losing details that would help denoiser!

Looks very promising, thanks for your testing (and general insisting)!

Normally normal values fall in the range from -1 to +1, times three directions (xyz).
When this is translated to rgb without correction, all the negative values are clipped and appear black.
So for an AOV in some image format there should be some correction like (x+1)/2.
Maybe OIDN cannot deal with negative values and needs a corrected image.
I've seen other early adopters are also struggling with how to configure the normal pass.
I don't really understand why Intel has no information on these basic requirements.

[epilectrolytics]

Well, the correct one is SHADING_NORMAL while the AVG_SHADING_NORMAL has some meaningless data on edges (like explained by B.Y.O.B. some post ago). But I guess Intel Denoiser uses normal AOV as an hint of where to smooth and where not.

Ok thanks for clarifying!

[lacilaci]

sometimes there's a gradient on the object that doesn't make sense and becomes completely black, losing details that would help denoiser!

Looks very promising, thanks for your testing (and general insisting)!

Normally normal values fall in the range from -1 to +1, times three directions (xyz).
When this is translated to rgb without correction, all the negative values are clipped and appear black.
So for an AOV in some image format there should be some correction like (x+1)/2.
Maybe OIDN cannot deal with negative values and needs a corrected image.
I've seen other early adaptors are also struggling with how to configure the normal pass.
I don't really understand why Intel has no information on these basic requirements.

Yes it is kinda weird that they don't provide example of the required inputs. I've seen people having same issues with nvidia denoiser addon where no one could figure how those passes should look like and since they weren't actual renderer devs (unlike Dade!) they couldn't even create those aov's.

I don't know if the avg normal pass could get more improved, but even at this state albedo +avgnormal are providing excelent preview quality and I wouldn't worry even using this for final renders (hell, so far I was using nvidia denoiser in ldr mode with beauty only and it kinda worked)

[Sharlybg]

So now we should change the renderer name to Luxcore Realtime Engine. No ?

[FarbigeWelt]

I don't know if the avg normal pass could get more improved, but even at this state albedo +avgnormal are providing excelent preview quality and

I wouldn't worry even using this for final renders

Looks like honey‘s dripping from the mouth of a most realistic reviewer.

Thnks for all the preparing testikg steps before alpha‘s done.

Feels like a second Xmas coming this year .

[alpistinho]

I've added the initial support for the library but couldn't test since LuxcoreUI was refusing to load any test scene, being unable to parse the PLY files included.

Code: Select all

[LuxCore][254.269]   /home/daniel/Documents/lux2/LinuxCompile/LuxCore/scenes/simple
[SDL][254.269] Reading scene: ./simple.scn
[SDL][254.269] Material definition: whitematte
[SDL][254.269] Material definition: redmatte
[SDL][254.269] Material definition: blumatte
[SDL][254.269] Material definition: greenmatte
[SDL][254.269] Material definition: whitelight
[SDL][254.269] Camera type: perspective
[SDL][254.270] Camera position: Point[10.951, -20.663, 8.017]
[SDL][254.270] Camera target: Point[0, 0, 1]
[SDL][254.270] Camera clipping plane disabled
RPly: Error reading 'x' of 'vertex' number 0
RenderConfig loading error: 
Unable to parse PLY file './simple-mat-cube2.ply'

There were also errors during texture parsing

Code: Select all

[LuxCore][25.422]   /home/daniel/Documents/lux2/LinuxCompile/LuxCore/scenes/luxball
[SDL][25.423] Reading scene: ./luxball-copper.scn
[SDL][25.423] Material definition: shell
[SDL][25.423] Material definition: whitematte
[SDL][25.423] Material definition: luxtext
[SDL][25.423] Material definition: blacktext
[SDL][25.423] Material definition: whitelight
RenderConfig loading error: 
Syntax error in texture name: 0,75 0,75 0,75

Any idea of what could be causing this?
The code is at https://github.com/Alpistinho/LuxCore in the intel_oidn_denoise branch
Thanks

I've tried the latest compilation from Azure it showed the same error. Luxcoreconsole was working apparently, but where should it put the output image?

[B.Y.O.B.]

Syntax error in texture name: 0,75 0,75 0,75

Why are these numbers using commas instead of decimal points? This might be the issue (i.e. locale).
https://github.com/LuxCoreRender/LuxCore/issues/103

[alpistinho]

Giving the scene to LuxcoreUI as a command line argument makes it render correctly.

I've set-up a second image pipeline but it doesn't change the image in any way, even though it becomes very slow and something is happening.

[alpistinho]

Syntax error in texture name: 0,75 0,75 0,75

Why are these numbers using commas instead of decimal points? This might be the issue (i.e. locale).
https://github.com/LuxCoreRender/LuxCore/issues/103

Just opened the file and they're not using commas. It must be related to this bug

EDIT:
I should probably change my LC_NUMERIC. The standard here is using commas as decimal separator

Code: Select all

daniel@daniel-desktop ~/Documents/lux2/LinuxCompile/LuxCore/bin $ locale
LANG=en_US.UTF-8
LANGUAGE=en_US
LC_CTYPE="en_US.UTF-8"
LC_NUMERIC=pt_BR.UTF-8