Here I'll show a technique I came up with that lets StereoKit draw all the UI surfaces in a single draw call! Since StereoKit targets standalone Mixed Reality hardware as first class citizens, I'm always searching for the most efficient way of doing everything, while still providing flexibility to developers!
Interested in building a Mixed Reality application that's properly cross-platform? How about one that can deploy to a HoloLens 2 in under 20 seconds? Maybe you're not interested in worrying about how much of your user's information Unity is collecting and selling, or you aren't keen on paying Unreal a chunk of your income? Writing MR applications yourself can be a daunting challenge! But it's one that's about to get much easier, thanks to OpenXR. With every major MR company backing OpenXR, this is a tool that's going to set the standard of MR development!
While many people will be able to simply hook into an existing engine's implementation of OpenXR, it's not all that hard to do it from scratch yourself! Here I'll show you a single code file that's about 700 lines of code, builds and deploys in seconds, and can run on Windows Mixed Reality headsets and the HoloLens 2 emulator! I'll be using C/C++, DirectX 11, and the OpenXR runtime that Microsoft recently shipped!
Lately, I've been doing a lot of AR development for the HoloLens! Very exciting stuff, but a little rough on iteration time! Deploying to a device that has the right sensors, hardware, and setup just takes too much time, especially considering that in many cases, these sensors and hardware are already on my laptop! They're simply not accessible from within the Unity Editor by default. Adding access to them has really sped up development for a number of my use cases, so hopefully this will be of help to you as well!
In this section, we'll mostly talk about lighting! I'm not much of a math person and I'll do my best not to botch terms, but that means I'll be talking mostly about visual results rather than in equations! So those of you who are also not math people may enjoy this :)
If you haven't read part one, be sure to do that first! I'll be assuming you know a bit about shader syntax and what's going on.
Shaders are easily one of my favorite parts of game development! I could spend all day writing little shader programs that do various different effects, and I could probably spend just as much time staring at the results! Shaders are delightful. But some people seem to think they're ominous black boxes!
It's true that shaders are pretty opaque up front! What do all these extra words mean, why is the syntax so strange, where does the data come from, what on earth is going on here?? Diving in headfirst can be confusing.