Quote: "but what if we have integrated shaders inside AppGameKit called like names of materials, Glass, Metal, Plastic? Each material would ask different type of texture for certain "layer" and if users mess things up, well, read the manual"
Yes, that sounds like a good approach. They could be based on a physically correct PBRish core and basically be shortcuts for achieving the looks of those materials without needing to tweak everything manually. I like the idea, makes it easier for users to get to the correct parameter settings.
Quote: "how hard would be to get one "material" in AppGameKit that has following:
Diffuse, attributes: texture/ color value, brightness value
Normal, attributes: texture, normal value
Roughness, attributes: texture, roughness value (from rough to glossy)
Metallic, attributes: texture, metallic amount
Specular, attributes: texture/color value, brightness value, fresnel amount
Reflection, attributes: dds cubemap, exposure level"
Right now, when aiming for general usage, quite hard. Not the material itself, the shader part is easy, but the rest.
Getting all the data it needs to look right is currently the hard part. Especially if you are aiming for a system any user could use without hassle, outside tools, custom converters, etc.
Roughness and Reflections work in tandem and are where the real issues start. They only work if you have correctly convoluted HDR reflection probes or an other solution to generate all the high range reflection data for any roughness value. AppGameKit has no floating point textures, no DDS cubemap support, no internal way of generating the data. You have to currently find workarounds for all of that.
The thing to keep in mind is that PBR lives or dies with it's reflections. They are the defining factor. The diffuse is just stock oldschool lambertian usually, like 20 years ago. What makes PBR special is adding correct reflections on top, we have to get those right. Especially for metals. They don't have diffuse, so their basic formula is: finalColor = reflections.
Diffuse and Normal we already have, even in stock rendering, so that's easy for realtime lights, just have to make sure it's not clamped to LDR (I never tested stock lighting in this regard).
If you use lightmaps, same issue as with reflection probes, you need HDR data.
Specular is not really a thing that we need to waste texture slots on if we have a metalness channel. You can kinda scratch that one off the list.
Basically, either you go metalness-roughness route and don't need specular channels or you go specular-gloss style and don't need metalness. I prefer the metal-rough workflow, but both work fine.
You can ofcourse solve all of the issues, but it will be a very specific solution for your workflow and there are also tiny tidbits you have to find solutions for. (Example: Some approaches HDR to RGBA packing having issues with bilinear filtering)
