{"id":82521,"date":"2018-02-13T03:10:22","date_gmt":"2018-02-13T03:10:22","guid":{"rendered":"http:\/\/www.esri.com\/arcgis-blog\/products\/product\/uncategorized\/scene-layer-performance-on-arcgis-online\/"},"modified":"2020-01-29T01:57:08","modified_gmt":"2020-01-29T09:57:08","slug":"scene-layer-performance-on-arcgis-online","status":"publish","type":"blog","link":"https:\/\/www.esri.com\/arcgis-blog\/products\/3d-gis\/3d-gis\/scene-layer-performance-on-arcgis-online","title":{"rendered":"Scene Layer Performance in Scene Viewer, Part 1"},"author":7061,"featured_media":0,"parent":0,"menu_order":0,"comment_status":"closed","ping_status":"closed","template":"","format":"standard","meta":{"_acf_changed":false,"_searchwp_excluded":""},"categories":[23771],"tags":[25781,549072,27491,31911,25791],"industry":[],"product":[36831,36551,36601],"class_list":["post-82521","blog","type-blog","status-publish","format-standard","hentry","category-3d-gis","tag-3d","tag-esrirdzurich","tag-jsapi4","tag-scene-layers","tag-scene-viewer","product-js-api-arcgis","product-arcgis-online","product-developers"],"acf":{"short_description":"You can use 3D object and integrated mesh scene layers based on the OGC\u00ae I3S Community Standard to create compelling visualizations dir...","flexible_content":[{"acf_fc_layout":"content","content":"

You can use 3D object and integrated mesh scene layers based on the OGC\u00ae I3S Community Standard <\/a> to create compelling visualizations directly in your browser. We are using various techniques to make the user experience as smooth as possible on this limited platform. In this post, I will describe three improvements we introduced in the December 2017 release of ArcGIS Online<\/a> and the ArcGIS API for JavaScript version 4.6<\/a>:<\/p>\n

    \n
  1. IndexedDB cache<\/strong>: Once 3D data is downloaded and processed we cache it in IndexedDB so we can reload it quicker.<\/li>\n
  2. Streaming<\/strong>: We optimized parallel streaming of i3s nodes and data so scene layers load faster and in priority order.<\/li>\n
  3. Progressive loading<\/strong>: Integrated mesh scene layers now download an intermediate level of detail (LOD) first then refine to more detailed LOD.<\/li>\n<\/ol>\n

    \"Helsinki<\/a><\/p>\n

     <\/p>\n

    IndexedDB cache<\/strong><\/h2>\n

    There are already many cache levels for scene layers: Data is cached in CDNs and on the client where the web browser automatically caches all requests. However, the geometry data for scene layers is usually in a geographic coordinate system and we need to convert it to an earth centered coordinate system for global scenes. Also, for optimal rendering performance we want to convert the data to a GPU friendly format with interleaved positions, texture coordinates, colors, etc.<\/p>\n

    Ideally, we would keep all geometry data on the GPU and render only the visible parts. However, GPU memory is very limited and we have to remove invisible nodes. To avoid repeating these transformations when displaying parts of a scene layer that we have looked at before, we store the geometry data in a format we can directly upload to the GPU in an additional cache level. This cache uses the IndexedDB API to store temporary data, so we refer to it as the IndexedDB cache. The following diagram illustrates the cache hierarchy on the client:<\/p>\n

    \"Flow<\/a><\/p>\n

    The diagram ends where we send out a request to the server. If you are interested further in what happens next, take a look at Paul’s excellent blog on caching in ArcGIS Online<\/a>.<\/p>\n

     <\/p>\n

    Streaming<\/strong><\/h2>\n

    To create an optimal user experience it is very important to load the right data at the right time. Data that is in the center of the screen or right in front of the viewer should be loaded before data at the border of the screen or in the background. However, network latency makes it hard to use the full bandwidth of the connection and still maintain a strict ordering of requests. The following diagram shows that serial ordering of requests wastes some bandwidth due to the latency of requests (illustrated in green). On the other hand, parallel requests use the full available bandwidth, but don’t preserve the order of requests:<\/p>\n

    \"Illustration<\/a><\/p>\n

    The optimal number of parallel requests depends roughly on three parameters: network latency, network bandwidth, and size of the requested data. In i3s services there are two main resources:<\/p>\n

      \n
    1. Index Nodes:<\/strong> The spatial index, which tells us where the data of the service is located. This consists of many small requests.<\/li>\n
    2. Geometry Data:<\/strong> The data we want to display on the screen. These are generally few but very large requests.<\/li>\n<\/ol>\n

      For those two different types of resources, different strategies are needed. For the small index nodes it is very important to request many nodes in parallel to hide network latency and optimally use the bandwidth. On the other hand, for the large geometry data the bandwidth of your connection is easily saturated, but requesting many in parallel makes loading individual nodes slower.<\/p>\n

      In this release, we individually tuned the parameters for these two kinds of requests to make optimal use of your bandwidth while still keeping the order in which we draw data close to the optimal order. As a result of these improvements, you can see that the loading order is very close to the optimal order (front-to-back) in the following video:<\/p>\n