Stop Asking for WebVulkan!

In February, the Kronos group, creator of the OpenGL 3D graphics standard WebGL is based off of introduced a new, much faster and lower-level API – Vulkan. It’s an open-standard that seems likely to revolutionize the game, 3D app, and Virtual Reality/Augmented Reality industry.

Source: https://www.khronos.org/vulkan/

Despite its promise, Vulkan should come with a warning label – it is unlikely to run on the web, and developing native Virtual Reality and Augmented Reality apps will be difficult and costly.

How Will Vulkan Affect Web-Based VR and AR?

Right now, all the major browsers support the WebGL standard for 3D, and most support, or plant to support the WebVR standard for buidling VR and AR apps in the browser. These standards are relatively slow compared to lower-level APIs like Microsoft’s DirectX, which limit its use. While you can create VR scenes of moderate complexity with WebGL, you can’t duplicate the current console game experience.

Would a WebVulkan help, if the browser manufacturers create it? This seems obvious, since even Microsoft supports WebGL in its new Edge browser (as well as Internet Explorer 11). As far as a future WebVulkan, this is what Gregg Tavares (a Chrome WebGL developer) had to say:

…it seems likely within 2-3 years OpenGL will be effectively dead on both desktop and mobile. Certainly no game engines will be using it anymore since Android and Linux will have Vulkan, Windows has DX12, OSX/iOS have Metal and all of those are often orders of magnitude faster than OpenGL (my italics) depending on the use case. See the “2015 Sigraph Vulkan BOF” video on youtube for examples. Not only is Vulkan fast but it saves significant CPU power which is important on mobile…

…unless there is a WebVulkan things like Unity->WebGL and Unreal->WebGL are going to have serious problems going forward.

Source: https://www.quora.com/Will-Vulkan-have-any-effect-on-WebGL

So, the problem for the web is not only in browser-based WebGL. Both Unity and Unreal Engine won’t be able to use it for cutting-edge game and 3D development. Also, Apple has its own low-level API called Metal, and is unlikely to use Vulkan.

The other problems with a “WebVulkan” relate to security. Vulkan doesn’t “sandbox” its activity, and gives the Vulkan app full power to control memory management and disk access. So, a Vulkan app could easily install viruses, snoop for passwords, and all the worst-case outcomes in a interconnected world.

In fact, without a secure version, Vulkan will be limited to consoles, and run in standalone versus networked mode. Given the rising level of networking in typical user activity, this would relegate Vulkan, like DirectX, to special use cases for a small segment of the potential virtual and augmented reality audience.

Vulcan, VR, and (especially) AR

Question: what is most exciting about Virtual and Augmented Reality?

Answer: the ability to leverage Internet services, social networks, media into a virtual world.

Let’s repeat that!

If your app can’t securely navigate the Internet, you can’t develop advanced VR and AR.

VR apps that go beyond “toy” worlds have got to have a secure Internet connection, use authorization services, and exchange data between APIs and the app. This is even more true for Augmented Reality, which is basically impossible without safe, sandboxed, access to Internet services.

To make a Vulkan app work with the Internet, it will be necessary to develop big, native-coded custom stacks with security, authentication, network communication and other features, essentially duplicating features found in web browsers.

So, development times will be vastly different from Vulkan projects vs the web. Even simple Vulkan apps will require extensive programming teams to leverage Internet services. In contrast, a lone individual might make a useful VR app using WebGL and a JavaScript 3D library that (relatively) that safely connects to social networks, stores and uses online assets, and so on.

Now, it’s true that other frameworks like Unity or Unreal engine could push into VR. But similar problems exist. If you stay in a high-level framework (scripting Unity), and, you have access to a low-level API like Vulkan, you have a security hole. Simple as that.

Are VR Browsers Eternally Slow?

Not to worry. Vulkan itself may have these problems, but some of the features making it so fast could be incorporated into the web browsers with their built-in security and web access models. The actual Vulkan would be hidden behind a high-level browser API.

So, looking out a few years, we might see 3D running much faster on browsers due to hidden Vulkan code, but the interface used by developers will remain the same.

The resulting apps won’t be as fast as a native code app taking full advantage of Vulkan. But among these faster apps, there will be some that scream at 1000fps, but end up compromising millions of users via hacking due to naive implementation of security and privacy by their developers. Due to the nature of the JavaScript API, this is much harder on the web.

As VR builds out, 3D development for the web will remain distinct from 3D native apps. Neither Vulkan, Apple’s Metal, or any other standard in the near term will provide an “end to end” solution for the industry outside the web. There will probably be two tiers of development, one exclusive, slow  and expensive, the other inclusive, fast, and cheap.

Don’t Sweat the Small Stuff

In conclusion, Vulkan doesn’t really affect the growth of VR and AR in general and WebVR in particular. The need for networked apps means that it will remain in the background, like DirectX does today. For rapid creation of VR and AR apps, 3D buffered by a front end (browsers and Unity) will remain viable for a long time to come.

So, stop asking for WebVulkan. You know not what you ask for….

Speed, like size, isn’t everything. What matters is getting your concept into the virtual world now.