More on spherical harmonics is coming, but this is a slight intermission about Vulkan. Yesterday, I got a chance to attend a Vulkan workshop (called Vulkan DevU) in Vancouver, Canada. It was a short conference with talks by some of the Vulkan working group, with a mixture of both advanced and beginner sessions. You can get the slides here. Unfortunately, isn’t been awhile since I’ve touched the Vulkan implementation in XLE, and it wasn’t fresh in my mind – but I got a chance to meet some of the working group members and ask a bunch of random questions.

This is a continuation of the previous page; a tutorial for using spherical harmonic methods for real time graphics. On this page we start to dig into slightly more complex math concepts – but I’ll try to keep it approachable, while still sticking to the correct concepts and terms. Integrating the diffuse BRDF On the previous page, we reconstructed a value from a panorama map that was compressed as a spherical harmonic.

Yikes; it’s been awhile since my last update! I wanted to share a little bit of information from a technique I’ve recently been working on for an unrelated project. The technique uses a series of equations called “spherical harmonics” for extremely efficient high quality diffuse environment illumination. This is a technique that started to become popular maybe around 15 years ago – possibly because of its usefulness on low power hardware.

Work is still continuing on XLE! Over the last few weeks, I’ve have been very distracted by other priorities. I’m likely to be somewhat busy and distracted during for a few more weeks until things return to a more normal situation. However, I’m still finding time to work on XLE, and make some improvements and fixes! Lately, my focus has been on Vulkan support (in the experimental branch). Vulkan is looking more and more stable and reliable, and the HLSL -> SPIR-V path is working really well now!

XLE has a thin layer over the underlying graphics API called “Metal”. This was originally built for DirectX11 and OpenGLES. But over time it became more DirectX-focused. Part of the goal of building in Vulkan support was to provide a basis for refactoring and improving the metal layer. The goals for this layer are simple: compile time polymorphism between underlying graphics APIs not link time or run time. We know the target during compilation of client code “leaky” abstraction layer meaning that most client code is independent of the underlying graphics API but the underlying objects are still accessible, so client code can write API-specific code when needed very thin, minimal overhead for example, many DeviceContext methods get inlined into client code, meaning that performance is similar to using the underlying API directly To make this kind of layer work, we need to find abstractions that work well for all target APIs.

The Vulkan build is steadily getting more and more functionality. Now the core rendering pipeline in SceneEngine is working – which means we can have deferred lighting, shadows, IBL, tonemapping, etc. Simple scene should render correctly now. But there are some inefficiencies and issues (see below). Unfortunately the DirectX11 version isn’t working at the moment. This is all in the “experimental” branch. Declarative render passes Tone-mapping now works, and it was a good prototype for the “declarative” render pass model.

The lighting parser is a set of steps (including geometry rendering and full screen passes) that occur in a similar order and configuration every frame. In some ways it is like a higher level version of a “renderpass” (or frame buffer layout). Each “subpass” in the renderpass is like a step in the lighting parser process for evaluating the frame. But how do we map the lighting parser steps onto render pass subpasses?