Like many people here, I have tried the bolt-on deferred shading pipeline here: Deferred Pipeline w/ Physically Based Shading
This is an impressive renderer addition for Panda3D, there’s no argument there. But I wonder why this hasn’t had the impact it seems it should have properly had on how we’re actually building games in Panda.
For me personally, I find the interface somewhat overdesigned. A significant amount of the pipeline is setup code. The interface does not feel quite native. It is also, unfortunately, rather slow with more than a few options turned on.
The 1.11 roadmap of the official Panda3D engine has a number of physically-based features on it, which is exciting, and I am happy about all the features listed on the 1.11 roadmap. 1.11 Roadmap · GitHub
At this point I’d just like to offer one perspective on how we apply shaders inside an actual game. I’d like to be able to do the following:
- Apply from a list of built-in shaders which roughly match the “RenderPipeline” or whatever is actually practical to offer as built-in shaders:
IE self.render.set_shader_group(‘ao’, ‘bloom’, ‘clouds’, ‘color_correction’, ‘dof’, ‘fxaa’, ‘pssm’, ‘skin_shading’, ‘scattering’, ‘volumetrics’)
– such that we’re using an entirely text-based way to tell the shader processing system what we want it to combine for a particular node, or the whole scene. I’m not 100% on the implementation details of this, it’s rather more complicated than I suggest of course. But I would personally prefer this kind of setup control over having to build and maintain such a huge architecture as the aforementioned ShaderPipeline.
Does anybody disagree with this idea as a setup strategy? I’d be happy to hear ideas about this.