Disney BRDF material

[epilectrolytics]

Side note
There is a theoretical advantage in using disney BRDF for all materials in a scene when rendering on GPUs: lack of threads divergence.

When that means that there must not be any non-Disney materials in the scene for the effect to take place it would be great to complement the shader with an option for refractive materials like the cycles version already has by adding transmission and IOR sliders.

Otherwise all scenes with glass materials would not profit from the advantage.

[Dade]

Bad news:
When trying to render with PGI indirect cache + Disney materials Blender crashes or I get a black render with a console warning: nothing is visible and/or cache enabled
scene link
Also I noticed unlike matte or glossy Disney material is one sided = black on the back side.

The code is missing some "glossiness" related function to make it PGI usable, I will add the missing support.

[Dade]

When that means that there must not be any non-Disney materials in the scene for the effect to take place it would be great to complement the shader with an option for refractive materials like the cycles version already has by adding transmission and IOR sliders.

This is an implementation of the original 2012 Disney Siggraph paper. Disney has than extended the model to allow transmission and presented the results in 2015 Siggraph course.

Indeed, we can upgrade the code to support transmission too.

Otherwise all scenes with glass materials would not profit from the advantage.

Only samples involving the glass will diverge and it does matter only if it happens inside a group of 16 or 32 contigue samples (depend on GPU SIMD width). Short version: you are likely to get most of the speed up with the glass too.

Just try to render your previous test scene with a glass sphere, it should be still faster.

[epilectrolytics]

The code is missing some "glossiness" related function to make it PGI usable, I will add the missing support.

Great, thanks!

Just try to render your previous test scene with a glass sphere, it should be still faster.

Ok I already suspected this because in my test scene there was no speed difference if the sphere had a mirror material or Disney 100% metallic & reflectance.

Great work!

[acasta69]

What I would find cool would be an Azure script that creates a new BlendLuxCore daily build whenever:
a) a LuxCore daily build is published
b) a commit is pushed to the BlendLuxCore repo
But it would be a bit of work + requires knowledge of Azure scripts (which I don't have at the moment).

Yes, that would be cool and I'd like to implement it as a next step of our build automation.
But I don't have much free time lately...
Hopefully during the summer...

[B.Y.O.B.]

Also I noticed unlike matte or glossy Disney material is one sided = black on the back side.

I would consider this a bug. It should behave the same on front and back faces.

[lacilaci]

I think it would be best if all materials behaved same way in front and backside. The only exception should be a 2 sided type of material or texture.

[Dade]

Also I noticed unlike matte or glossy Disney material is one sided = black on the back side.

I would consider this a bug. It should behave the same on front and back faces.

I don't remember how it is supposed to work but it is likely to be a bug however try also to check another implementation like the Cycles one to see if the behavior matches or not.

[kintuX]

I too confirm a single sided bug. (Principled in Cycles works fine on both sides)

Found Disney's Specular value rendered with OCL a bit brighter than CPU/BiDiR.

Note: Only blue material. Difference shown in yellow.
Although there's a small difference in Glossy too (Red material, Dif. in Blue)

There is a huge specularity dif between your render test . Bidir is far less specular while OCl GPU is like adding another coating layer. and simple CPU is like a mix of them.

Maybe to the naked eye. It's same scene just different engines used.
For BiDir vs UniDir i expect minor differences, but not such a difference using GPU vs CPU. Though IIRC, i think it's an old issue, got something to do with precision (was already readapted/corrected a few times).
Anyways...
If anyone is interested, Test scene (for latest BlendLuxCore daily 2.2beta): LuxCore2-2Ball.7z 20.6MB (@mega.nz)

[B.Y.O.B.]

I don't remember how it is supposed to work but it is likely to be a bug however try also to check another implementation like the Cycles one to see if the behavior matches or not.

In Cycles it looks the same on front and back faces.