Generally speaking, I believe Sponza has been considered too performance intensive to render in real time. However, given modern advancements in computing hardware (minimum specs below) and the application of complexpbr 0.6.3 with Panda3D, I have managed to do so! Screenshots and in-game video below.
Sample program minimum specs: RTX 5050 and a modern quad-core processor or better. Given the graphically intensive nature of the sample program, you’ll need fairly beefy hardware to run this smoothly, especially in ultra-HD like the demo video below.
The sample program git repository is engineered to be minimal while keeping the model files within GitHub’s 100 megabyte file limits for in-repo hosting. I’ve split some of the models into multiple files to keep them under 100 megabytes. The repo also includes Sponza credits so that you can find all the original author’s model contributions.
Simply run main.py to start the sample program. I’ve kept the program under 200 lines, so it’s actually a very straightforward way to study a Panda3D rendering application.
Let me know if you have any questions or comments here!
We need to try to redo this for the standard auto shader, if I’m not mistaken, the last release Panda3D implemented the roughness map. However, the screenshots posted by Simulan have an inexplicable unnaturalness, I am not a PBR expert, but it seems to me that Ambient Occlusion is not correctly rendered, since the ceiling is too bright and evenly illuminated.
On that, it might be worth waiting until the new shader system is released. For one thing, it might be better than the current, and for another, it’ll demonstrate the system that’s (presumably) intended to be used going forward.
I do think that a bit more ambient occlusion could be used (or perhaps a more-accurate offline method), indeed. The areas in shadow are perhaps a bit “flat”.
It is unlikely that the new shader system will include a new rendering system, as far as I know, the interaction of Panda3D with shaders (compilation, portability) is currently being handled, these are not the same thing.
I was thinking that it might change the primary interface for developers to produce shader-driven graphics–but I suppose that basic shader-work will still use the simple “auto-shader” system on the front-end.
So perhaps it would be fine to use the auto-shader for the sample!
Thanks for the replies. I would like to note that the scene is adjustable, and things like AO can be set on a node level. Indeed, I left lines for AO adjustments in the sample program (set at 1.0).
The shadowed areas are boosted a little in the apply_shader() call, by a factor of 0.05 – this is just my preference, you can set it to 0 if you want to.
Based on your comments (and some others on YouTube) I decided to take a second look at my AO (SSAO) implementation. I believe that the implementation currently has an incorrect way of comparing depth, which leads to the totally flat SSAO we see with complexpbr currently.
I’ve started working on a fix, which I plan to commit once it’s ready. It’s not that much code to update, but it’s kind of a tricky effect to get right for every situation.
Here’s a WIP example (which is not great, but shows “more subtle shadowing” at least):
