The last days (and weeks) I’ve been working on a Vulkan example implementing physically based rendering with image based lighting (you can find a nice article with lots of details over at Trent Reed’s blog) and just pushed it to my public github repository.
While working on this demo I realized that putting all the binary assets (models and esp. textures) in the repository might not have been a great idea. They quickly bloat the size of the repository and once a binary asset is there you won’t be able to completely remove it (to shrink the repo again) unless you actually rewrite the history. But with the repository being public with almost 400 forks and numerous pull requests this pretty much a no-go.
Took a bit longer than expected, but I finally got around releasing updated binaries for my open source C++ Vulkan examples. Compared to the last updated (in 2016) there are numerous changes and lots of new examples added. One major addition is touch support on Android.
I have added another example to my open source C++ Vulkan examples. The new one is about indirect drawing (including multi draw if supported). Contrary to their non-direct counterparts, the indirect drawing commands in Vulkan take their draw calls from a buffer that is ideally stored in device local memory. So instead of running single draw commands that get their index base, index count and instancing numbers passed by the host upon getting called, the indirect commands are backed by a buffer that stores an arbitrary number of draw commands.
The example renders a huge number of plants with different geometries only using one single draw call. All plants geometries are stored in one buffer, and each indirect draw command uses different index offsets and also does instancing.
This technique is the based for several GPU-based functions that have traditionally been handled by the CPU. As the draw commands are stored in a buffer that the GPU has access too, it’s now possible to have a compute shader manipulate the draw commands that are issued so the GPU can take on tasks like culling or draw command generation in general.
Based on the recently updated deferred shading example, I have added a new example to my open source C++ Vulkan samples. This example adds dynamic shadows from multiple light sources, showcasing a few technologies that can be used to make rendering of multiple shadows more efficient.
To achieve this, the example uses a layered depth attachment with one layer per light source that is sampled in the final scene composition. Traditionally one would do multiple passes to render the depth maps for the scene’s light source, and to avoid this the example also uses shader instancing by doing multiple invocations in the geometry shader. The geometry shader then uses the invocation index to output into the different layers of the depth attachment, with the matrices from the different point-of-views of the light sources getting passed as an array.
This is an approach that fits modern GPUs very well and allows for an arbitrary number of shadow casting light sources to be added without the need to add multiple render passes.
Over the past few weeks and months I’ve been constantly working on my Vulkan examples, enhancing existing demos, adding new ones, fixing bugs reported and merging pull requests (thx to anyone that has contributed!). I even found some time to work on a Vulkn deferred shading playground using Crytek’s famous Sponza model. You can find the repository for it here.
This Sunday I decided to visually upgrade the deferred shading example included in my samples repository. Deferred shading is commonly used nowadays, and I felt that the example didn’t showcase the technique properly. And so I went on to add some normal mapped surfaces, render multiple meshes and make the light sources dynamic.
And thanks to nvidia’s ShadowPlay I can even capture the Vulkan samples at nice frame rates, so I decided to upload a small video of the updated example to my YouTube channel:
As there have been lots of new information on Vulkan, Khronos‘ new graphics and compute API I decided to do a little write up of the new API from a hobby 3D developer’s point of view.
Although I’ve been writing games, demos and applications with OpenGL for roughly 15 years now I still consider myself a hobby developer in terms of 3D graphics. My job is not depending on pushing pixels, maxing out draw calls or swizzling shader commands, and most of my work on 3D (primarily OpenGL) is done during my spare time (mostly late at night).
During this years SIGGRAPH and GamesCom, Khronos showed off some stuff related to Vulkan (LunarG e.g. uploaded a video of LunarXChange, the developer platform for Vulkan) and several IHVs (e.g. PowerVR) and ISVs demoed applications and implementations.
And while it’s still a way to go before Vulkan is released to the public (should be by the end of the years) I’d like to write down a few words on the new API for hobby (OpenGL) developers that may be uncertain on whether to switch or not, or even on what Vulkan actually is.