Massive Free Collection of PBR Materials

[Frionil Fang]

2 hours ago, Cynite00 said:

ACES... what a bold move, which isn't standard yet even on many engines, unless their focus is on CGI

 

1 hour ago, Porky Gorky said:

I have not seen those benefits in SL though, I think it is a partial ACES implementation which was a required compromise to make the old content look “acceptable” in the new PBR lighting. I cant see any other reason why they would do it.

I saw mention of them implementing the Khronos neutral tonemapper and switching to it as the default, in the viewer issue log: https://github.com/secondlife/viewer/issues/2464

[Cynite00]

1 hour ago, Frionil Fang said:

 

I saw mention of them implementing the Khronos neutral tonemapper and switching to it as the default, in the viewer issue log: https://github.com/secondlife/viewer/issues/2464

Ok, so if this change sticks, then we need to move the conversation away from ACES type chat but to an OCIO config chat, as the same issues will persist across softwares, as they will all have to have acess to the ocio file to represent the colors accurately between applications. I'll have to read up a bit more about that, and try out the demos at Khronos\ToneMapping\PBR Neutral to see if that is feasible too. Preferrably I don't want to change my entire workflow and colorspace JUST to suit SL, as I work in a variety of software and engines, and tired of 'customizing for SL

Khronos Tonemapper vs ACES comparison and what it all means

 

Edited September 6 by Cynite00

[Cristiano Midnight]

2 hours ago, Ceka Cianci said:

I went to buy it and seen that I already bought it back in early July..

I could almost swear it was you that posted about it.. It might have been inside one of the PBR threads back then.. hehehe

I was kind of disappointed that I already have it.. Cause I wanted more stuff!!\o/  LOL

I didn't know about this until recently. What I posted previously were the pbr EEPs that Onsu had for 1L.

[Ceka Cianci]

16 minutes ago, Cristiano Midnight said:

I didn't know about this until recently. What I posted previously were the pbr EEPs that Onsu had for 1L.

Oh ya that's right.. Thank you for those, they are nice.. 

Everything was so long ago it seems..

Now I'm wondering how I got this already.. Because I really haven't looked for things like this that much, that I can remember.. lol

[Aethelwine]

26 minutes ago, Ceka Cianci said:

Oh ya that's right.. Thank you for those, they are nice.. 

Everything was so long ago it seems..

Now I'm wondering how I got this already.. Because I really haven't looked for things like this that much, that I can remember.. lol

I think Kathleen posted about it in the week following the firestorm PBR release. I can't find that post to confirm it was her that posted it 

There is no harm posting it again I am sure many missed the original post.

[Scylla Rhiadra]

4 hours ago, Porky Gorky said:

It is easy enough to flip the normals but there is more work to be done.

Sorry, I've heard this before, but how? In what direction? If I have a normal map that I know is DirectX sitting in front of me on Affinity, what exactly do I do?

Also, does this relate to converting normals from Blinn-Phong specification, to SL's implementation of PBR?

[Cynite00]

29 minutes ago, Scylla Rhiadra said:

Sorry, I've heard this before, but how? In what direction? If I have a normal map that I know is DirectX sitting in front of me on Affinity, what exactly do I do?

Also, does this relate to converting normals from Blinn-Phong specification, to SL's implementation of PBR?

Same process as in Photoshop, go to the channel layer select the Green channel (in Photo 2 it's not as clear but you will see an eyeball light up on it) then Ctrl=I (Invert)

Unreal has a node that can flip this easily, so I would like to see similar functionality in the Material Editor, should a DirectX normal texture make its way in (and it has happened to me as a newbie and I was confused as to why my  normals looked backwards)

 

Blinn-Phong normal textures and PBR normal is the same texture. It's how BP and PBR calculate the light reflections using ALL  the maps provided is the difference.

Edited September 6 by Cynite00

[Ceka Cianci]

1 hour ago, Aethelwine said:

I think Kathleen posted about it in the week following the firestorm PBR release. I can't find that post to confirm it was her that posted it 

There is no harm posting it again I am sure many missed the original post.

I sure wasn't complaining about them being posted again.. I was just surprised that I already had them and got things mixed up on where I got things from.. hehehe

[Charlotte Bartlett]

21 hours ago, Cynite00 said:

Ok, so if this change sticks, then we need to move the conversation away from ACES type chat but to an OCIO config chat, as the same issues will persist across softwares, as they will all have to have acess to the ocio file to represent the colors accurately between applications. I'll have to read up a bit more about that, and try out the demos at Khronos\ToneMapping\PBR Neutral to see if that is feasible too. Preferrably I don't want to change my entire workflow and colorspace JUST to suit SL, as I work in a variety of software and engines, and tired of 'customizing for SL

Khronos Tonemapper vs ACES comparison and what it all means

 

This has been my point on other other threads, the SL pipeline is completely custom at this point and is supporting 2 forks - bp materials and PBR.   PBR materials, even when we are using ones created in Substance Designer into Painter, now need SL versions and it genuinely (I have a fun very long post about what it now takes to create a house in SL) is a material impact (ok part pun intended) on time, effort and complexity.

However I do wonder re Tonemapping V ACES (and if LL moved toward ACES updating in the future).  
Tonemapping has tighter ranges and I wonder if this will reduce the vibrancy, detail etc of content that has been creating during the "ACES" phase.
I am not an expert (in either and have very limited knowledge on Tonemapping) but I have always thought Tonemapping was better for speed where ACES was better for ensuring that materials look consistent in different lighting and viewing environments.   (EEPs then challenge my statement there as we have inconsistency across users and are not controlling those)?
 

Edited September 7 by Charlotte Bartlett