An idea to simplify PBR workflows: a self-contained PBR material.

With the implementation of the “Principled” BSDF coming, much of the photorealistic workflow in Cycles is in place.
But there was something that something that always bugged me with it: the number of textures and the process of using them. In Blender, this requires loading all textures, setting “Non-color data” to all but one of them, not simply plugging the normal map into the shader but having to go through the normal map process.

Follows a proposal of a new file format, specific to PBR textures, and a possible implementation in Blender.

It is not uncommon to have 5-6 textures defining a material. This poses several problems both in storage, in memory and in implementation. The idea is to group those textures in a single file, complete with a metadata file that describes the files and their role in the PBR shader. For some time I thought about using a multi-layered OpenEXR file, but that limits the file type, and might not work with all situations.
So instead I would implement it with a renamed archive file, containing all textures in their formats and a user-chosen name. Added to it a description file (JSON, XML, whatever) which contains the output type (eg. color, number, normal) and maybe additional configuration (normal map type, for example). Also the description metadata file could allow for uniform numbered inputs instead of a 1x1 texture.

In Blender the result would be a multi-output texture ready to be used directly into the “Principled” or any other PBR shader. No need to fiddle with settings, in a few clicks your material is set up, and consistent throughout engines. Moreover the entire material is self-contained and compressed, optimizing storage space.

But most importantly, I am sure I’m not the first one thinking about it. Is there any other similar implementations?

Hey,

It sound like a good idea ! I haven’t heard of something similar yet. I think it’s because there isn’t a standard between application yet. Softwares doesn’t have exactly the same implementation of these maps. Even if it’s small difference : a map may need to be inverted to work in another software. Normals map also need some channel shuffling when going from one app to the other.

Also some people like to pack some map inside RGB channels rather than having 3 different grayscale images.

But if it’s only inside blender maybe with some naming convention and a clever script it may be enough, sound much like what Hoverkraft as posted…
It’s true that it can be very useful to share and use materials.