Esri is a member of the Open Geospatial Consortium (OGC®), and has been delivering geospatial solutions for over 5 decades, investing significant brain power to solve one vexing problem in the geospatial world: making massive geospatial content available across platforms and devices, including web browsers, mobile devices, and desktop applications. In response to that challenge, the Indexed 3D Scene Layer (I3S) specification was created about a decade ago. Esri worked with the community to release the specification under an Apache license in 2015. The OGC adopted I3S in 2017 as its first 3D streaming Community Standard.

I3S was created to enable streaming and storage of massive 3D geographic data. An I3S dataset, called a Scene Layer, can contain millions of discrete 3D objects, each with their own attributes, integrated surface meshes, point cloud data, etc. I3S allows various types of geospatial content to be efficiently encoded and transmitted as a single scene in order to create an interactive visualization experience that is accessible across a wide variety of devices. Recently, OGC adopted the latest version of I3S, OGC I3S 1.2, which incorporates advanced physically based materials that are feature-compatible with the Khronos® glTF™ 3D asset format standard, and supports referencing of glTF 3D models in I3S Scene Layers.

I3S Scene Layers often contain significant amounts of texture data, consuming large amounts of storage and processing power. Their size makes it a challenge to maintain desired levels of interactivity. High resolution texture files are integral to the realism and legibility of a 3D object - but uncompressed, they’re huge. Textures using JPEG or PNG compression are typically software-decoded, eating CPU cycles and resulting in slow loading. Additionally, they must be held as large uncompressed images in GPU memory, consuming this precious resource and slowing rendering performance compared to GPU-compressed textures. When dealing with assets as complex and detailed as geospatial images, this problem is multiplied manyfold.

Textures can be compressed into a GPU-native format, such as BC1/3 or ETC2, that may be efficient for a GPU to use, but these formats are much larger than JPEG or PNG, making them slower to transmit. What’s more, the landscape of GPU formats is highly fragmented, with different formats only supported on particular platforms. This fragmentation makes it impossible to use the same GPU-compressed textures across all systems.

Basis Universal was created to address this issue. Basis Universal is a compression technology developed by a company called Binomial. It enables supercompressed texture files that are comparable to JPEG/PNG in quality and transmission size, but can be efficiently transcoded, on-the-fly at run-time, directly into a wide variety of natively-supported GPU formats to match the hardware on any receiving system without ever consuming the memory of a fully decompressed image.

Esri worked directly with Binomial to improve the encoding time for the creation of Basis Universal supercompressed texture files. The optimization work resulted in a ~4X reduction in compression time in version 1.13 of Basis Universal, while maintaining quality and compression ratios. Esri and Binomial also introduced OpenCL in v1.16, assisting with the simultaneous encoding of multiple textures.

The final piece of the puzzle for reliably distributing textures to diverse platforms and applications is Khronos’ KTX™ 2.0, an efficient and lightweight GPU texture container format. KTX precisely specifies how the contents of a texture file are to be handled, from a simple base-level 2D texture to a cubemap array texture with mipmaps. KTX files also hold all the parameters needed for efficient texture loading into 3D APIs such as OpenGL® and Vulkan®, including access to individual mipmap levels. The latest version of the specification, KTX 2.0, adds support for Basis Universal supercompressed GPU textures - creating truly ‘Universal Textures’ that can be encoded once, are compact to transmit, and are efficient to process on any GPU across multiple platforms.

KTX 2.0 Universal Textures using Basis Universal Supercompression

The latest version of I3S, version 1.2, adds support for KTX 2.0 textures, together representing a win on every front: transmission size, GPU memory consumption, image quality, and encoding time. A Scene Layer using KTX 2.0 loads faster, consumes less memory and power, and is practically identical in terms of image quality.

Side-by-side demonstration of Indexed 3D Scene Layers (I3S) showing a street view of Frankfurt, Germany, courtesy of Esri. KTX 2.0 textures in GPU memory are 6-8X smaller than JPEG textures, enabling larger data sets to be displayed at higher levels of quality and interactivity.

We’ve created a side-by-side app based on ArcGIS API for JavaScript to demonstrate the value of compressed textures in transmitting scene layers:

• Live Application
• Source Code

The full interactive demo is best viewed on a desktop, but the screenshot above captures the results. The app shows the relative performance, quality, memory usage for an I3S Scene Layer rendered with JPEG textures (on the left) versus KTX 2.0 (right). The caption at the bottom left of the side-by-side applications shows:

• Scene Memory (Used/Available) - where Used is an estimate of the memory that is in use by the SceneView (in Megabytes) and Available is the total memory available to the SceneView (Megabytes)
• Quality - level as a number between 0 and 1 (expressed in %). Quality decreases when loading all requested layers results in allocating more memory than available to the app.
• Layer - The name of the I3S layer displayed in the scene
• Memory Used (MB) - the memory used by this layer only

In the example above, the demo produces the following results:

• Left: I3S Layer with JPEG
  • Memory Used: 1210MB
  • Quality: 35%
    
    
• Right: I3S Layer with Basis in KTX™ 2.0
  • Memory Used: 615MB
  • Quality: 100%

Note that the application loading textures in JPEG (left) routinely decreases ‘Quality’ because loading all requested resources results in allocating more memory than available to the app. In such cases, memory reduction is achieved by reducing the level of detail, number of features and tile resolution. As a result, it routinely fails to retain maximum scene quality (100%). On the contrary, the app loading KTX 2.0 (right) typically stays at 100% quality most of the time, staying within its ‘memory budget,’ not triggering quality loss, and loading all resources at the quality/resolution requested. The memory difference between the two apps is only a factor of 2-3X as the KTX 2.0 app loads more tiles (without level of detail reduction) as determined by the layers’ screen selection criteria. If we loaded the same exact quality resources in both apps, the memory difference would be upwards of 6-8X.

I3S v1.2 is, thus far, the only OGC format that has standardized support for KTX 2.0 built into the specification. Given these results, though, the value of this texture container format to the geospatial community is clear, and we expect more to follow.

As the virtual worlds we build become more complex, and demand for their availability becomes more widespread, open standards and open source specifications targeting efficiency, portability, and interoperability will be key to the growth of the geospatial industry and the metaverse at large.