Author Topic: Linear Workflow with Substance  (Read 35128 times)

I also would love to see that we can choose between both input types: RGB and Linear Values in SD & SP. Both software packages have another input type and that's what confuses a lot and makes it harder to author great textures.

I just put up a Uservoice: http://allegorithmic.uservoice.com/forums/261284-substance-painter/suggestions/7044743-multiple-input-types-to-choose-from
Last Edit: February 03, 2015, 08:17:43 am
Environment Artist - Twitter

Set your output Node to RGBA16 and it will export as 16bit.  I just tested this by exporting to .png and opened in Photoshop to verify.

hi,

yes that is working - but if you export via 2D-Viewport (floppy icon) it does not..


Cheers!

I also would love to see that we can choose between both input types: RGB and Linear Values in SD & SP. Both software packages have another input type and that's what confuses a lot and makes it harder to author great textures.

I just put up a Uservoice: http://allegorithmic.uservoice.com/forums/261284-substance-painter/suggestions/7044743-multiple-input-types-to-choose-from

Hi Fabian,

Thanks for submitting the user voice. We plan to add an option for viewing the numerical values in SP as sRGB as well.

The difference between SD and SP is that the color picker works differently. The values are numerically entered as linear in SP. However, the color display in the picker dialog displays color as sRGB. So if you were to visually choose a color, it is in sRGB space. Once the color is chosen, you will see the linear value for that sRGB color. In SP, you are still visually choosing color as sRGB, but the difference is when it comes to enter a numerical value, it must be in linear. I agree, this is confusing.

It all comes down to visualization and conversion. You need to be able to properly visualize the colors. This must be done in sRGB space because of the way our eyes work and screens display color. In the end, SP is creating sRGB output for maps that dictate color (base color, specular, albedo). If colors are displayed in linear space, they'd look too dark. If you paint base color in linear space, it would appear to our eye much darker and you would not be able to accurately gauge the values. You never author maps directly in linear space

However, for lighting calculations, the computation must be done in linear space to be accurate. So this presents a problem with visualization versus computation. Think of it like going to see a movie in 3D. You need to wear 3D glasses to see the picture correctly. If you take off the glasses the picture looks incorrect to our eyes (think of linear space), but put the glasses back on (think of sRGB space) and it looks good to us.

In order for the 3D to work, it must be calculated correctly i.e. split between left and right so the end result will look correct. The same is true for PBR as you need to calculate the values correctly for the end result to look correct. This is done by removing the gamma encoded values in base color, specular and albedo maps so the math will be correct in the rendering process. So with this said, you can think of editing the textures while wearing the "sRGB Glasses." I will stress that this only affects values that represent color data such as base color, albedo, specular color.   

A conversion needs to take place. In SD, the process is sRGB and the conversion to linear is handled in the shader. With SP, the process is linear and the conversion is handled manually by entering linear values. However, if you are just using the picker to choose a color value, it works just like SD. Either way, both SD and SP are computing values in linear space and presenting an sRGB image for export and display. SP works more like UE4 in this regard. SD has been around long before PBR and SP was built for PBR, so this is way you get this difference in the color pickers.

Cheers,

Wes




 

Integrations Product Manager / Training
wes.mcdermott@allegorithmic.com
Twitter: The3DNinja

Thanks for this artist-friendly explanation, Wes!
The reason why The colour picker in SP is sRGB seems good, displaying in Linear space wouldn't make sense, anyway.
To have the ability to type in Values in Linear Space is also great, too. Because to remember values in Linear space is much easier and a lot of LUTs are authored with Linear values.

But as you just said, for color maps it doesn't make sense. It would be a great thing to have the ability to type in sRGB values, too. Just add the sRGB Values next to the Linear values in SP ;)

For SD I wish there would be the same approach: Instead of using sRGB values for grayscale gradients, it would be a great thing to have a grayscale gradient like in SP: from 0-1. Let the user choose whether he wants to use Linear values or sRGB Values ;)

I am reffering to just the values you can type in. It's great how SP & SD handle the workflow of its own and display everything in sRGB But calculates it in Linear space. I don't want you to change that behaviour, I just want to type in sRGB Color values in SP and Linear grayscale values in SD : )
Environment Artist - Twitter

iam sorry to bother you but the PBR_Guide_Vol.2.pdf is offline.

can you plz put it back online? i can't wait to learn the awesome stuff.

Thx a lot ;)

maybe polycount.com wiki would be also a good place to put :D

iam sorry to bother you but the PBR_Guide_Vol.2.pdf is offline.

can you plz put it back online? i can't wait to learn the awesome stuff.

Thx a lot ;)

maybe polycount.com wiki would be also a good place to put :D

We are very sorry for the issue. We are migrating the server. You can download the PDF here in the meantime.

https://dl.dropboxusercontent.com/u/4595383/Allegorithmic/ComprehensivePBR.zip

Cheers,

Wes
Integrations Product Manager / Training
wes.mcdermott@allegorithmic.com
Twitter: The3DNinja

So this is a great topic, I must say. I am surprised that we don't learn this in school (at least for me, and I am a 3D artist!). Anyway, I am aware the linear workflow and have been experimenting in my work for some time now. I use MARI for painting textures and Substance Designer to texture my assets.

Here is an interesting thing:

Based on your explanation about linear and sRGB space, Wes, I understand that if you plug an sRGB baseColor texture into output baseColor node, the shader in Substance will interpret it as an sRGB input and automatically remove gamma correction (0.45) in order to process and display it correctly in 3D view. Am I correct?

In MARI, I paint my baseColor texture using their workflow for PBR shaders here:

https://vimeo.com/90974835

As you can see, in MARI, I switch the "Input Color Space" to "Linear", "View Transfrom=sRGB" (I believe this is to convert back to sRGB space before displaying on my monitor, but just for display purpose only), and in layer stack, I add sRGB2Linear layer in order to process all layers below it to Linear space. Now, when I export this texture out as TGA file, obviously it will export everything in the layer stack, including sRGB2Linear layer==>my baseColor texture is in Linear space, not sRGB!

With that said, when I import this baseColor into SD (the texture look darker in 2D view with sRGB option on==>it confirms that my exported texture from MARI is in Linear, and shown on my 2.2 gamma monitor), and use the baseColor node, the shader will interpret it as in sRGB, and start remove gamma correction, which is not even there, isn't it all wrong? Should I add in the Convert to sRGB node before the output?

If you want to keep your baseColor texture in linear space but want to see correct results in the 3D view, you just need to change the shader parameter named "sRGB Diffuse" to "false". This will tell the shader to expect a linear texture in the baseColor slot (... and that reminds me that we forgot to rename that parameter from Diffuse to baseColor, we should do that in the next bug fix release ...).

Another possibility: if you want to make your texture sRGB instead, you can also add a Convert to sRGB node before the baseColor output node. In that case of course, you should leave "sRGB Diffuse" to "true".

Ah....Got it, totally forgot that I can tweak that option in the shader as well. That makes sense now :) Thanks, Cyrille.

Sorry to bump this topic, but I must thank you guys for all of the valuable information in regards to the linear workflow, especially with things like the equation which gives me the floating point integer to use in Substance Painter (which boggled my mind at first). And after some initial tests, the resulting texture is put into linear when I take it into photoshop (i.e. a value of 2, 2, 2 becomes 28, 28, 28).

So if I want a certain colour like in Unity, I would have to author it darker

Sorry to bump this topic, but I must thank you guys for all of the valuable information in regards to the linear workflow, especially with things like the equation which gives me the floating point integer to use in Substance Painter (which boggled my mind at first). And after some initial tests, the resulting texture is put into linear when I take it into photoshop (i.e. a value of 2, 2, 2 becomes 28, 28, 28).

So if I want a certain colour like in Unity, I would have to author it darker

Hi,

You are most welcome : ) So glad you have enjoyed the info and the guide.

I wouldn't author it darker. You shouldn't worry about authoring in linear space. For color, you will want author this as you would see it which is in sRGB. PBR workflows will handle the linear pipeline. So in Unity, color textures (base color or diffuse - Unity refers to as albedo) will be interpreted as sRGB. This means they will be converted to linear by the shader for rendering.

For textures in Unity, you can enable "Bypass sRGB sampling" which will not convert the texture from gamma space (sRGB) to linear. However, the Standard shader is handling this. So if you were to import a texture in sRGB, and then check this option, the result would then apply the gamma twice to the render as the sRGB image is not converted. However, you don't need to use this bypass option for data textures such as metallic and smoothness as you would expect (you do need to do this in UE4). The Unity shader is handling this.

Cheers,

Wes
Integrations Product Manager / Training
wes.mcdermott@allegorithmic.com
Twitter: The3DNinja

Hey kashif.c.riley,

if you really would like to author your maps in Photoshop, for instance, you wouldn't want to author them darker and recalculate every time you make a change. It's quite confusing :P
What you could do is to create your own working space for Linear sRGB colour. To work just like you would normally you could use a proof setup to view the image in sRGB with a Gamma of 2.2, even if the actual image is linearised.

The biggest benefit I see doing that: You won't get those dark rims around blended colours, which you do get when not working with a linear colour space because Photoshop does the maths wrong somehow.

If you really need to use Photoshop this would the setup I would recommend. If not, just use Substance Painter :P


Best Regards
Environment Artist - Twitter

Hi guys.

I read the post and kind of lost in the middle with so many new things i'm hearing for the first time. I have a situation where we are creating assets that are unreal ready (diffuse, metalness, roughness maps). Currently we are using photoshop and getting the work done, which is a long road to follow for every change.
Using SD is faster, but there's some issue with roughness value between SD and unreal and how its displayed. I read around the forum on how both interpret the linear and sRGB data and someone suggested to change settings in the unreal to read it properly.
The things is, i can't and don't want to alter anything in unreal as we are creating assets as  unreal ready for some other company and i would want them to see the same thing in unreal as we do here in SD. But using SD we are getting wrong result. What i should do in SD to get the result to show similar to unreal.

Hi guys.

I read the post and kind of lost in the middle with so many new things i'm hearing for the first time. I have a situation where we are creating assets that are unreal ready (diffuse, metalness, roughness maps). Currently we are using photoshop and getting the work done, which is a long road to follow for every change.
Using SD is faster, but there's some issue with roughness value between SD and unreal and how its displayed. I read around the forum on how both interpret the linear and sRGB data and someone suggested to change settings in the unreal to read it properly.
The things is, i can't and don't want to alter anything in unreal as we are creating assets as  unreal ready for some other company and i would want them to see the same thing in unreal as we do here in SD. But using SD we are getting wrong result. What i should do in SD to get the result to show similar to unreal.

Hi,

The correct workflow for UE4 is that the roughness map needs to have sRGB unchecked. This is if you are importing the roughness as a texture. I wouldn't try to create a workflow in SD to bypass this in UE4. In terms of PBR, this is a standard workflow in that base color is sRGB and the roughness and metallic should have sRGB unchecked. If you try to change this, then I think it would cause more confusion.

If you are using a substance material in UE4, you don't need to change any settings as the Substance plugin flag the maps correctly for sRGB.

Cheers,

Wes

Integrations Product Manager / Training
wes.mcdermott@allegorithmic.com
Twitter: The3DNinja

Ok, how does this topic relate to Unity5?

Like when in "Player project settings" Color Space is set to"Linear" - will the shader expect a linear BaseColor texture-map?


kind regards