What channel layout do you want for PBR materials?

[Josh]

I need to decide on a channel layout for PBR materials. There are four images to consider: metallic, roughness, occlusion, and height. These could be packed into a single RGBA texture.

From the GLTF spec here:
https://github.com/KhronosGroup/glTF/tree/master/specification/2.0#metallic-roughness-material

Quote

pbrMetallicRoughness.metallicRoughnessTexture

The metallic-roughness texture. The metalness values are sampled from the B channel. The roughness values are sampled from the G channel. These values are linear. If other channels are present (R or A), they are ignored for metallic-roughness calculations.

• Type: object
• Required: No

I keep seeing people asserting that GLTF stores occlusion in the red channel, but the spec says it is a separate texture.

So there does not seem to be any standard at all, as far as I can see. What do you think is best to do here?

[Abstergo]

The subject itself is out of my depth, but I'd always stay as close to spec as possible. I don't know how authoritative those individual comments are and what kind of user share they represent, but I'd expect other developers to base their work off the specs, even if initial research yields conflicting information. That is why they exist.

If that is the official spec and it covers this question, there is a standard and that is it.

[reepblue]

The issue is that other engines/tools allow the end user to pick what mask goes in what channel; creating the fragmentation. I used to put my roughness in Red, metal in Green, and AO in Blue personally. There can be an issue when it comes time for artist to port their assets in the new engine. To be fair, I think most people just want to copy and paste their textures and to create a material file.

A fixer/mask importer app would be nice.

 

[Josh]

I could add a texture swizzle in the material file like this:

"swizzle": "bgra"

But simplest is best. It can take forever to import a bunch of materials one-by-one.

I can't believe people actually go through and drag lines between color channels for EVERY SINGLE MATERIAL they import.

A visual tool will be a necessity in the future, but that is part of the editor.

[wadaltmon]

To answer your question from my status update: I'm not really sure if this is what you mean, but Substance Painter can export a PBR material with color, metal, roughness, normals, and height (bumpmap). 

[reepblue]

@wadaltmon Does it merge all the masks into one image or outputs one by one separately?

[wadaltmon]

3 minutes ago, reepblue said:

@wadaltmon Does it merge all the masks into one image or outputs one by one separately?

All those maps are exported as separate images.

[reepblue]

Yeah, Ok. So The issue is that it's common to open Photoshop and merge all those outputted sheets into one images using the RBGA channels. However, there is no standard; people put whatever mask in whatever channel and then when they import it into an engine, they use the silly nodes to define what's their roughness/metal/AO/etc.

Issue is that right now, Turbo doesn't have a node editor, and from the looks of it, Josh wants a standard which is non-existent within the art space. Really big mess right now.

[Josh]

It’s more optimal for us to make a decision now than for everyone’s GPUs to make a decision for each pixel, for each frame ever rendered by this engine, on anyone’s computer. ?

[reepblue]

Set a standard, make a tool that merges peoples masks into one image, call it a day. You can have the editor detect these sheets and auto merge them

[wadaltmon]

1 minute ago, reepblue said:

Set a standard, make a tool that merges peoples masks into one image, call it a day. You can have the editor detect these sheets and auto merge them

But then that begs the question of what maps the tool will have to know how to merge, which brings us full circle

[reepblue]

Sorta how Leadwerks knows what masks are your color. normal, and spec; how you name them.

mytex, mytex_n, mytex_r, mytex_m, mytex_ao.

I'm thinking that the editor would read your raw images copy the pixels and merge them into one image then output it as one dds texture.

[Josh]

We already do this a lot. The material generation guesses a lot of file name suffixes and usually can figure out which texture is the normal map, etc.

[awgsknite]

idk but id like to have all different options available to do whatever and not be stuck with one option as this says >>

http://wiki.polycount.com/wiki/ChannelPacking

Why not have options for all channels ?

I would think that people would like to be able to use all channels no ?

For example >> i wanted to make a car texture and that would use the metallic option and then for another texture i would want the roughness texture for some texture on carpets,etc. that use fuzzy or furry textures

Edited June 23, 2019 by awgsknite
examples

[reepblue]

Thanks for that link, it pointed me to an application that I was looking for.

http://orsvarn.com/entry/channel-shuffle/

[wadaltmon]

Is it standard to mix the various maps into a single image? If so, why would that necessarily be better off than keeping them separate?

[wadaltmon]

If the argument is for or against separately inputting the various maps, I'd say I'd like to have all the maps separate. Makes it far easier to establish and then change just one if necessary or for testing. Granted, with one Male you'd just be re-exporting one map and replacing that in LW/TE, but you'd have to go through a middleman to mix the exports into one.

[Josh]

A single image is best for speed because it only requires one texture lookup, and these are a moderately expensive operation. It also reduces you video memory usage, by four times.

[wadaltmon]

On 6/25/2019 at 11:08 PM, Josh said:

A single image is best for speed because it only requires one texture lookup, and these are a moderately expensive operation. It also reduces you video memory usage, by four times.

What does a single map of this kind look like? I can't find any examples.

[Josh]

[wadaltmon]

Interesting. So how does it read the different materials individually? Does it just read the different channels per pixel and interpret them individually?

EDIT: Nvm, you literally said that in the first post