Google’s Draco for Mixed Reality Applications: Compression Test
Written by Ryan Groom, CTO, Kognitiv Spark
Welcome to the Kognitiv Spark developer blog. The Kognitiv Spark innovation team is using this forum to give you a behind the scenes insight into our drive to create secure holographic applications that thrive in low-bandwidth environments.
Early on in Kognitiv Spark’s history, we decided to build our own 3D rendering engine. This decision was made to avoid using off-the-shelf authoring environments designed for video game creation rather than secure applications for businesses, especially organizations in high-security sectors. This has allowed us to optimize our rendering engine for use in rigorous – often geographically remote – end-user environments, while also allowing us to have the source code validated by our security review processes.
In our commitment to making sure RemoteSpark – our flagship application for remote support – can operate at the lowest possible bandwidth, we’re constantly evaluating ideas, algorithms, and code libraries that can help us not only deliver video and audio in low-bandwidth environments but also content (2D and 3D) from the expert user to the front-line, remote user, all with the same constraints.
Meet Google’s Draco
This week the innovation team explored an open-source project from Google called Draco. The description of Draco from the GitHub repo reads “Draco is a library for compressing and decompressing 3D geometric meshes and point clouds. It is intended to improve the storage and transmission of 3D graphics.”
Perfect, we’re in the business of reliably transmitting 3D content over consistently poor network conditions.
We tested Draco to see if it compressed 3D data any better than Zip.
Compression Test
Here are the results:
As you can see above, the results were impressive. Our next steps are to determine how to add this to our content creation workflow and add Draco into our 3D engine. This way, a content author can create a glTF asset, compress with Draco, and have it rendered in RemoteSpark. If all goes well, we will add this feature in Q1 2020.
“Open Source,” Isn’t a Dirty Word
On the topic of open source, I was surprised this week, while on a call with a customer, that open-source software was regarded as a four-letter word. I previously thought that this notion been laid to rest. In the mind of this customer, the term “open source,” was painted with connotations of insecurity, non-industrial grade, and code written in a dark basement.
Even the use of glTF was brought into question because it was an open-source specification. As glTF is not a software, anyone can adopt this standard. The great thing now about open source it is no longer just the domain of hackers but large organizations with professional software engineers that create world-class software and give that back to the community. Let’s say that again, professional software engineers from companies like Intel, Microsoft, Google, and IBM create sophisticated enterprise-class software and hand over the keys to developer communities. Best of all, it’s free.
Open specifications, in my mind, have a fantastic security posture as it’s a blueprint (instructions not software) on how to create and store data (like glTF 3D files). Proprietary formats, like most CAD files, lock your corporate knowledge into a file format that cannot be freely retrieved without using the software that created the file.
With open standards, you have the option at any time to write software that can read your data and is not bound to the software that originally created the file. With glTF you can write your own implementation and can even write validation techniques to ensure what the file contains only what it should in the proper format.
Checking the license of open-source software and QA the code before deployment
Like any open-source software, you need to verify that the license it’s published under meets your intent of usage and additionally the code can be vetted through your security processes for verification or even modification before being added into your toolkit. Your inputs and outputs are defined by a specification and you get to analyze every line of code before you use it. It doesn’t get much better than that!
It’s early days for us and Draco, but if all works out, we’re looking forward to adding this solution into RemoteSpark as it helps with our mission to deliver rich, holographic content from the expert to the front-line worker over restricted networks, when and where workers need it the most.
If you have any questions, please reach me on Twitter anytime, RyanGroom.