Slides and example from Delphi Day 2025 presentation and after-thoughts (Afterwarp, shadow maps, BGFX and deferred rendering)

[michalis]

I’m traveling back home after enjoying Delphi Day 2025 in Piacenza.

1. I think I’ve made a nice presentation about the engine features.

   Slides are available here and one new (simple and fun 🙂 ) example is part of the engine now: examples/physics/physics_throw_chickens.

   During the talk, I also showed a number of existing projects, including platformer, fps_game, complete FPS game using Blender, Sketchfab, Quaternius models, TCastleMoveAttack (shown first at Zlot 2024).

2. I also watched a number of inspiring presentations from fellow Delphi users. It was really good to see so much activity around Delphi and Pascal!

3. One talk that in particular remains in my memory was about the Afterwarp Framework by Yuriy Kotsarenko. I was truly amazed by some features he shown, in particular the deferred shading implementation combined with shadow maps that allows to have 65k dynamic light sources casting shadows (and he showed demos really proving it — one demo with really ridiculous 65k dynamic lights, one demo with over a thousand lights casting shadows and car with headlights moving through them). Really impressive, and it makes me jealous, and I told him about it 🙂

   To make it happen, deferred rendering is the key (in contrast to the current CGE forward rendering). I was looking into this in the past… but there was never enough time to “attack” it, as it’s a bigger task.

   Edit 1: My intention here is not “let’s just switch to deferred rendering”. The cited Wikipedia page about deferred rendering already mentions disadvantages of this approach, and Afterwarp that inspired me is actually using a hybrid approach (“uses a hybrid forward, deferred rendering using clustered shading”). My intention here is to explore our options for lots of dynamic lights and shadows in the engine, and I note 2 things: 1. it’s high time to focus on shadow maps, as I already wrote in roadmap (see more below) and 2. I want to experiment with deferred rendering.

   Edit 2:: Originally I wrote here that our optimal path to deferred rendering may be to speedup BGFX renderer integration, as BGFX will give us deferred rendering, and we want to have BGFX as alternative renderer anyway. However, while BGFX indeed allows for deferred rendering, it’s a manual approach (not a simple toggle “forward / deferred rendering”). So: 1. we still want to have BGFX!, 2. but it’s independent from deferred rendering, as we can introduce deferred rendering either on top of BGFX or CGE current renderer, with ~similar work.

4. I had a few “nudges” recently to focus more on our shadow maps as a preferred shadows algorithm, and maybe leave the shadow volumes as… maintained, but not default.

   To explain more:

   • In the current engine version, shadow volumes are more comfortable to setup (just click 1 checkbox, if only your models are 2-manifold), while we have a few TODOs to make shadow maps comfortable.

   • But the shadow maps have likely a brighter future: more performance, because you can control the shadow map resolution and frequency of updates, which was pointed both by Afterwarp presentation and recent forum thread where Erik Johnson managed to use our shadow maps with great performance gain. Also, shadow maps work out-of-the-box with our upcoming (not yet merged to master) skinned animation on GPU, while shadow volumes… in short, require fallback to animate skin on CPU (see TODO there for more details). So, again, shadow maps seem to give “more performance, easily”.

   • And of course shadow maps “just work” with any geometry, 2-manifold or not, and even account for alpha testing (e.g. precise shadows cast by typical leaf textures). So there’s no need to worry about whether your 3D model is 2-manifold, and no need to tweak RenderOptions.WholeSceneManifold either.

5. So, thoughts coming from the above:

   • shadow maps improvements are important (and don’t be afraid to make shadow maps, not shadow volumes, default),

   • deferred rendering is important (to experiment with, and maybe come up with a hybrid approach),

   • BGFX renderer is important, albeit independent from us “getting deferred rendering option”.

   OK, this mostly validates our roadmap, with shadow maps before 7.0, and BGFX after 🙂

Have fun everyone! Stay tuned for more technical announcements next week. And if you like what we do please support us e.g. by subscribing on Patreon.

[kagamma]

Correct me if I am wrong, but I don’t see how BGFX automatically give us deferred rendering. From my understanding BGFX is just a wrapper around existing graphics API, so we would still have to implement deferred rendering in BGFX the same way we do it in OpenGL.

Their own example demonstrates that you must handle everything yourself: bgfx/examples/21-deferred at master · bkaradzic/bgfx · GitHub

Hybrid approach is easier to do, especially when dealing with transparent objects (deferred rendering for solid objects in one pass, forward rendering for transparent objects in another pass)

Edit: I think the first step would be allows the current renderer to render geometry information (normals, specular, pbr etc) to g-buffers. This is necessary for both deferred renderer, and any screen effects that requires additional geometry information in order to implement (like Screen Space Reflections effect, enhancements to GLSL API for effects – Castle Game Engine). It also opens the possibility of implementing a deferred renderer without having to modify the engine’s source code.

[edj]

I am honored to have been named! I look forward to all shadow progress. My constraint currently is the requirement to have the light and receiver in the same x3d node creates complications since each terrain tile and water tile are their own TCastleScene.

[michalis]

@kagamma

Correct me if I am wrong, but I don’t see how BGFX automatically give us deferred rendering. From my understanding BGFX is just a wrapper around existing graphics API, so we would still have to implement deferred rendering in BGFX the same way we do it in OpenGL.

Their own example demonstrates that you must handle everything yourself: bgfx/examples/21-deferred at master · bkaradzic/bgfx · GitHub

Oh, you’re absolutely right, thanks for this.

When writing above news post, I saw that BGFX has the deferred rendering example, and I incorrectly assumed “oh, so they have a simple toggle to switch to deferred rendering”. Looking now into the C++ source code, it’s indeed more like “you can do deferred rendering, but you need to manually setup the buffers and operations on them”. I’ll edit the news post accordingly.

I agree with the rest too