Unity is probably the hottest game engine right now, powering many commercial games and hobby projects. Unity is fully featured, relatively easy to get started with and most importantly free for personal and even small commercial projects. But it's not just games that it is used for. The powerful 3D display capabilities inherent in a game engine are perfect for industrial applications too, which is why a lot of companies use Unity to create apps that operate CAD and 3D data for collaborative design reviews, personnel training, product showcases and other visualization scenarios - often in the form of VR and AR apps.
Being a game engine first, Unity has a specific workflow. It has a single event loop that runs both the project business logic and rendering. This means that event-handling code has to be quick to not freeze the entire application. If there are any computationally heavy operations, they must be offloaded to a separate thread and run asynchronously. Another point is that out-of-the-box Unity is not capable of loading previously unseen models in runtime. This is because games normally use a fixed set of assets which are all available when building the app. Loading 3D data at runtime requires running code in the aforementioned event loop.
Unity supports a number of target platforms: desktop and mobile OSes, game consoles - and also WebGL. To create a WebGL application, one must choose the WebGL as the target platform in Build Settings. Then running the build process produces a set of files, which can be served as a static content with a web server (or a CDN). Provided there are no additional requirements that have to be implemented outside of Unity, a functional web app can be created by Unity developers without extensive experience with web development.
Unity does not produce any server-side code. In order to run the application in the browser, Unity compiles its runtime into WebAssembly binary which utilizes browser APIs (WebGL, audio playback, game peripheral input, Web Sockets, etc.) to carry out the responsibilities of the engine - 3D display, audio playback, input handling, network communication and more. The client code running inside the event loop is written in C#, but is also compiled to WebAssembly (via intermediate translation to C++).
All things considered, the browser appears to be a very functional platform for Unity app execution. The majority of Unity's features are available for WebGL builds. Here are the most important limitations:
Upon the loading of Unity runtime in the browser, a large block of contiguous memory is allocated for the entirety of your app. This block can grow (though not larger than 2 GB), but an attempt to do that can fail if the browser doesn't have enough memory. All the app's objects and assets, including objects you need to load models at runtime, will have to reside there. All of these factors mean that there is a soft limit on the complexity of your app and the complexity of 3D data you'll be able to work with.
Unity claims to support all major desktop browsers, but mobile browsers aren't officially supported. Furthermore, due to the varying level of API implementation in the browsers, some of them might not permit the use of certain features or might perform worse than others. Most notably, Apple's Safari does not support WebGL 2.0, so Unity is forced to fall back to WebGL 1.0 when running in it.
WebAssembly currently doesn't have support for multi-threaded computations in stable browsers, so both the Unity runtime and the client C# code can't utilize threads for computations.
PlayCanvas provides a few hosting options. The app built with it can be hosted by PlayCanvas itself, then it's simply assigned a URL you can link to from your website, or just embed in an iframe. This is a low-maintenance approach that allows to reap the benefits of PlayCanvas' web orientation without extensive web development experience. For more advanced users it's also possible to download the entirety of the app and host it on your own servers (including CDNs).
The downsides for PlayCanvas are quite standard for a younger and more niche project - it can't match Unity's feature set and platform support, nor does it have a huge asset store and a variety of commercial products that integrate with it. In particular, loading 3D data in runtime and in formats not supported by the engine out of the box requires the use of additional software (either on the server, or through an API call).
This time we took a brief look at two tools capable of producing 3D web apps in a different manner, focusing more on the 3D app development than the web app development. If the app requires centralized features like user accounts and sharing, these tools will by themselves only take care of the client-side and server-side development should look as it does for the usual client-server web app built with common web technologies. Otherwise, these tools can prove useful for teams that don't have much experience with web development, but have a background in 3D app development.
So far in this series, we steered away from the specifics and aimed to provide general considerations for picking the architecture and technology stack of your next 3D web app. To wrap things up, in the last part of the series we're going to focus on a small and specific example of a 3D web app and get more practical.
This 3D visualization is powered by CAD Exchanger Web Toolkit - a library for interactive CAD data visualization. Find out more and request a trial here.