I remember that one of the focus of the 1.11 release was to add support for PBR, or at least provide the framework to support PBR pipelines, but is it still the case ?
So far I’m happily using panda3d-gltf to imports PBR based models and apart from a few bugs or limitations here and there it’s working fine. However there is one missing feature in Panda right now that is cumbersome and will grow more and more annoying in the future (at least for me ), the texture stage has nothing to support PBR texture mode. There are mode for modular, normal map, specular, glow, gloss, … and their combination, but nothing for PBR related data like roughness, metalness, AO, …
I have my own shader generator and I’m using the texture stage mode to enable certain rendering feature or not. To support this with meshes loaded by panda3d-gltf I patched it to add texture stage mode, for example the metal/roughness map is set as a gloss map, but this is not a long term solution. Already I have trouble to detect if a AO map is present or not, and that hack can not work with more advanced extensions like clearcoat or sheen.
My question is, could there be support for more texture stage modes in 1.11, even if the default shader generator of Panda does not support them, a bit like the PBR parameters in Material that are not used natively ?
The very baseline of PBR support that I want to get in 1.11 is a more idiomatic and built-in way to specify “PBR” textures (roughness, metallic, etc.). This will be my next priority after I finish the new shader pipeline (which is making great progress).
I am not personally really happy with using texture stage modes, because you can have multiple stages with the same mode and it’s not quite clear how they should interact. I have been proposing to put the textures on Material instead. It feels like the textures belong with the other material parameters, though it is a bit of a shift away from the more close-to-the-metal philosophy behind TextureAttrib. The alternative is to change the texture stage system to a “texture slot” system.
You’d be very welcome to comment on the proposal. Other ideas are also welcome.
Thank you for the good news
I also don’t like much the texture stages, so the move to “full” material seems a good idea and more natural, at least for a end user point of view! I have to read the proposal more carefully though.
My two questions/concerns now are :
how easy would it be to create or derive new materials ? For example if an app needs a glass material or extend an existing material to add a new concept (e.g. anisotropy). Would it be possible to derive a new material class in Python (with all the needed functions and hooks) to support the new attributes and textures ?
Could the material approach limits the flexibility of the workflow used ? For example if my model has a specular color map instead of a specular level map ? (Or that could be handled by another material type)
I think materials should be subclassable. I intend for the standard PBR material to be in a Material subclass called StandardMaterial. I haven’t yet given much thought to extending material models from Python. But that’d be an easy problem to solve at that point.
The idea of adopting the now industry-standard material model with standard slots is that it should become easier to exchange models, shaders and materials—most of the time, it should “just work” even when mix-and-matching materials and shaders. However, if you want to use your own material models, it should remain possible to subclass StandardMaterial and add additional slots, or subclass Material and redefine the slots entirely.
The flipside is that something that used to be relatively simple in the fixed-function pipeline, like texture blending, now becomes hard. After all, you’d need to create an extended material model that is able to take in a second texture and then you need to make a shader that is able to interpret this correctly.
This is why I’m still a little uncertain about the proposal. I think the best way to solve this is to have some kind of node-based material system like Blender has, but that’s certainly an unrealistic target for 1.11.
However, at least the StandardMaterial will give people a solution for PBR, without requiring our default shaders to implement tremendously complicated texture blending pipelines, and we can later build on this to create more flexible Material subclasses.