OctaneRender™ 2019.2 XB2 [latest 2019.2.x]

[Notiusweb]

I am also getting Red GPU (All GPUs failed) on any scene having a higher level of complexity.
Note - the scenes load in XB1.

EDIT -
I can recreate a scene in 2019.2 XB2 and then it works, but is very tempermental.
A lot of hangs when rendering, and Denoiser hangs also.


On another note, Material-Picker works great!

[funk]

I have a concern regarding kernel > "affect roughness". I don't think its a good idea to make this a per scene/global value. The default is different in 2019.1 (0.5) compared to 2019.2 (0.0) as well

If anyone is creating layered materials to be shared or sold, their materials will look different, depending on the value the user sets in the kernel.

This can have a pretty drastic affect eg. glossy material with sheen enabled. The sheen roughness affects the specular roughness in proportion the "affect roughness" value in the kernel.

"Affect roughness" would make a lot more sense if it was a new pin on materials.

[Notiusweb]

I have a concern regarding kernel > "affect roughness". I don't think its a good idea to make this a per scene/global value. The default is different in 2019.1 (0.5) compared to 2019.2 (0.0) as well

If anyone is creating layered materials to be shared or sold, their materials will look different, depending on the value the user sets in the kernel.

This can have a pretty drastic affect eg. glossy material with sheen enabled. The sheen roughness affects the specular roughness in proportion the "affect roughness" value in the kernel.

"Affect roughness" would make a lot more sense if it was a new pin on materials.

I wouldn’t want them to base node tweakability on that somebody’s product might be wonky if the user has a different preference set up. That seller really need only convey under what settings their material will work instead.

Like, don’t do some seller the favor of making their for-sale material work good...
do me, as user, the favor of allowing me the flexibility to decide my own settings

[funk]

do me, as user, the favor of allowing me the flexibility to decide my own settings

You would gain (not lose) flexibility by making the setting a per material setting, rather than a global kernel setting.

[rajib]

do me, as user, the favor of allowing me the flexibility to decide my own settings

You would gain (not lose) flexibility by making the setting a per material setting, rather than a global kernel setting.

Maybe the solution should be have a global setting that is overridden by whatever is set on that material. So if a material does not set any, global one is used. But yes, some flag apart from 0 value should be used to specify 'not set' as 0 might be the value set in the material. So that way users get to do what they want and vendors get to sell material that work as expected irrespective of the user's global setting.

[Notiusweb]

Actually, now that I am trying Affect Roughness in Kernel, I am noticing 2 things:

1) it seems that Affect Roughness is an optional override to already-existing per-material roughness settings...
So what's the concern with needing an individual per material roughness? We already have that.
Just don't use Affect Roughness if you don't want it to affect per material.
We don't need to take it away!!!

2) It doesn't seem to actually work / do anything when I try using it. Like, it is broken.

[funk]

Actually, now that I am trying Affect Roughness in Kernel, I am noticing 2 things:
1) it seems that Affect Roughness is an optional override to already-existing per-material roughness settings...

It's not quite as simple as a general "roughness override". It affects what percentage of the roughness on an upper layer, affects the roughness of layers below them.
eg. On a glossy material, your sheen (which is an upper layer) roughness can be 1.0, while your specular roughness can be 0.1. If you set "affect roughness" to 1.0, your specular roughness will no longer be sharp (0.1), but rough (like 1.0), since the sheen roughness is 1.0.

So what's the concern with needing an individual per material roughness? We already have that.
Just don't use Affect Roughness if you don't want it to affect per material.
We don't need to take it away!!!

If it would default to 0 (off), then that would be fine, but it defaults to 0.5 in 2019.1, while it's 0 in 2019.2. If you are loading a material from a library, it will look different in 2019.1 than 2019.2

2) It doesn't seem to actually work / do anything when I try using it. Like, it is broken.

I have attached an OCS with an example material, so you can try it. Right click the material > render. This has "affect roughness" set to 0.5 (the 2019.1 default). You'll see sheen roughness = 1.0 and roughness = 0.1.

Go to kernel, and set "affect roughness" = 0.0 (the 2019.2 default) . You can see the blueish sheen layer roughness doesnt change, but the roughness (specular) layer changes, giving you a sharp specular reflection.

If you had this material saved in your local DB and loaded it in 2019.1 and 2019.2, it would look different, because the kernels have different defaults for "affect roughness"

[wallace]

If you had this material saved in your local DB and loaded it in 2019.1 and 2019.2, it would look different, because the kernels have different defaults for "affect roughness"

Hi,

I have actually applied the same default values in 2019.1 and 2019.2, but we just haven't released the 2019.1 build with the updates that 2019.2 has in it.

It will definitely be changed to 0.0 in 2019.1.

[funk]

I have actually applied the same default values in 2019.1 and 2019.2, but we just haven't released the 2019.1 build with the updates that 2019.2 has in it.
It will definitely be changed to 0.0 in 2019.1.

Thanks Wallace. I still don't think this setting belongs in the kernel, but at least we'll have matching default behavior between the 2 versions.

[wallace]

I have actually applied the same default values in 2019.1 and 2019.2, but we just haven't released the 2019.1 build with the updates that 2019.2 has in it.
It will definitely be changed to 0.0 in 2019.1.

Thanks Wallace. I still don't think this setting belongs in the kernel, but at least we'll have matching default behavior between the 2 versions.

Sorry, I was still digesting your post .

I do think you have made a valid point, and will move it to per layer instead.