In our previous visualisation post, we mentioned the two main rendering engines that are currently in development: Chroma and the DigitalBridge SDK (DBSDK). In this post we’re going to go into more detail about the DBSDK, what its purpose is, what the main features are, and some of the improvements we’re developing for the future.
Over the past 4 years we’ve grown massively as a company. The DigitalBridge of today looks a little different to the one I joined a few years ago, and the same can also be said of our technology. Originally we were focused on developing an iPad application that allowed users to take a photo of their room and test out wallpapers and paints in that room.
As a small startup we were focused on quickly getting features into the application to demo to potential investors or retail customers, so all code (including UI) existed in a single library that was linked into an iOS application. There were several problems with that setup:
The DigitalBridge SDK is our answer to those questions; a lower level cross-platform rendering library that we can use to build different applications on different platforms.
Any engine or graphics developer that develops proprietary technology is likely to have heard this question hundreds of times -- I’ve heard it from developers, interviewees, customers, users and so on. While being asked the same question multiple times can become annoying, it’s still a valid question. But to answer it we first need to look at the real purposes of DBSDK.
The DBSDK is a mobile-web-first renderer. This means we target browsers on mobile devices as our main use case. Our primary objective is to provide a great experience in browsers on a large range of mobile devices, performance is more important to us than having photo-realistic light transfer. Unity content is currently not supported at all for mobile browsers, and so it isn’t suitable for our needs.
Developing our own technology also allows us to choose which platforms we actively support. This is important as it allows us to make specific optimisations for our highest priority platforms, such as reducing dependent texture reads in shaders so that we perform optimally when compiling to the web.
Part of what helps us achieve this is a device-independent, gracefully degrading system; we automatically query the capability of a device and disable certain graphical features that may not work correctly. In the future we hope to expand this to automatically detect and disable non-essential features that may perform slowly on the target device.
Tools such as Unity and Unreal Engine are fantastic for developing games, but kitchen and bathroom design is not a game (although we hope to make the whole process a bit more fun!). We don’t need physics simulations, entity control systems or 3D audio support, which makes our renderer lightweight and easily portable. That also means we can focus on features we do need such as quick material swapping for kitchen ranges, or a simplified interface for manipulating polygons with materials to allow efficient rendering of wall coverings.
We develop a number of libraries and tools in-house that all need to have a definition of what a room is, and what data is needed to understand and manipulate that room. Having our own proprietary technology allows us to define a custom scene format and share that one central format between all of the different technologies that need it, whether that be another renderer such as Chroma or our AI-assisted design platform Catalyst.
Until now the main focus of the DigitalBridge SDK has been to build a stable, more generic library that can enable rapid development of different applications. We’ve successfully achieved that and have a version of our original wallpaper design application live with John Lewis, as well as a 3D bathroom design tool live with another major UK retailer, both using the DBSDK.
So, what next? Now that the library is robust enough to be used to create different types of applications, and the interface is stable, we can start working on features that add some real polish to the user experience. Here are just some of things we have in the pipeline.
WebGL has matured massively since we began development of the DBSDK. WebGL 1.0 support was somewhat patchy 3-4 years ago, but it’s now almost universally supported across the board. What’s even better is that WebGL 2.0 support is gaining a lot of traction, with 47% of users now having WebGL 2.0 compatibility.
This is absolutely brilliant news as WebGL 2.0 has a lot more core functionalitythat we can use to develop new graphical features which would’ve been too expensive otherwise.
Now WebGL 2.0 is actually backwards compatible so there isn’t any work needed to “support” it per se, but what we mean to do is to use the new features wherever we can in the DBSDK to improve performance as well as implementing some more advanced graphical effects such as:
This is just a small list of some of the immediate things we would like to add, as well as improving the performance of our existing effects like SSAO and shadow mapping. We’ll also be providing blog posts for these features when we develop them to give an insight into how we’ve implemented them and the visual effect each one delivers.
Another major update we’re currently planning is an overhaul of how we render walls, windows and doors.
Currently windows and doors are placed on top of walls, instead of embedded inside them. While this is more than sufficient to allow a user to design a room, it could look a lot better!
Embedding objects inside walls is fairly trivial, but what we really want is a system that allows the shape and structure of walls to be calculated at runtime whenever the locations of any doors or windows change. Encapsulating complex behaviour behind a simple interface allowing users of our library to develop applications as efficiently as possible.
This also opens the door (excuse the pun) to adding scenery and visuals outside of the room, as glass on windows and patio doors will actually be transparent. Allowing us to experiment with plants, paths and night or day lighting, all contributing to giving the user a real sense of home.
As mentioned earlier one of the big advantages of developing our own technology is that we can keep it lightweight and easily portable. We want to use this to take advantage of new technology coming out of the rapidly growing mixed reality space.
We are looking into porting the DBSDK to VR and AR, experimenting with technologies such as the Microsoft HoloLens, HTC Vive and ARKit/ARCore. At the moment we’re at the quick prototype stage, but we’re doing lots of research into how we can use these technologies to add real value to customers during the kitchen or bathroom design journey.
We’ve come a long way from our humble startup beginnings! A lot of hard work has gone into transforming our all-in-one iOS application into a lightweight, cross-platform, mobile-web-first rendering engine -- and we’re not done yet. Our sights are now firmly set on adding extra value to our customers and end-users wherever possible, whether that be with added graphical features and optimisations in the DBSDK, or integration with other in-house rendering platforms such as Chroma.
Thanks for reading. The next instalment in this series will be an in-depth look into our Chroma renderer and some of the exciting developments we’re making within the photo-realistic rendering space!