Globe Viewer Outlook

GlobeViewer development started more than 5 years ago. I am currently working on a complete relaunch of the project so that the display quality of the 3D tiles is significantly improved. Here is a brief look at the current prototype and the changes that will later be available in the app. The next version will probably not be released until 2024, so please be patient. You can read below why this is taking so long.

Thank you for your understanding!

More memory available

Since GlobeViewer development began in 2017, (mobile) technology has evolved significantly. At that time there was very little main memory (approx. 250 MB) available for apps on the devices. If this limit was exceeded, the app was immediately terminated by the operating system, which severely limited the number and resolutions of textures that could be loaded simultaneously in the app.

From that time came the definitions for available texture sizes on the 3D tiles, so each tile only allowed a 512x512 pixel texture for elevation coloring and a 1,024x1,024 pixel texture for the surface normal map. The maximum for textures today is 4,096x4,096 pixels - only a few of them could be loaded back then before there were big problems. New texture formats (which can also be viewed compressed on mobile devices) and more memory available for apps now allow texture sizes to be redefined.

Better screen resolutions and more performance

The first iPad generations came out with a 1,024x768 screen resolution. Today almost all devices work with at least FullHD or 4K resolutions and more. In order to be able to calculate these pixel quantities fluently, the computing power has also increased significantly. This means that significantly more effects and more complex shaders can be used for the graphic display today than back then. However, the performance is distributed very differently in the many available device classes. So there will have to be a gradation of the display in the app in order to keep the app running on as many devices as possible.

Current map data with more details

Even the earth has changed, you can see this most clearly on the coast line. Here is an example of how e.g. the coastline near Seol has changed due to land reclamation in the last 5 years. So it's definitly time to update the maps.

The redefinition of the textures also offers the opportunity to accommodate more information on the textures. So far, for example, rivers are missing in the height textures. It makes a big visual difference whether a river reflects light or not:

In the same way, roads, borders and e.g. land use can also be accommodated in the textures. These can then simply be superimposed on the elevation map.

Division of the map

The map is divided into 22,912 tiles. So that meaningfully related areas can be processed together, there is a division into zones. The first zone is Europe and is currently being edited.

Region 1: Europe & Course of the water (Enlarged: Bibione Pineda/Venice)

Development steps to the next version

1. Adjust elevation data
   
   1. ASTER elevation data is already available as 3,601x3,601 data. These are upscaled to 4,096x4,096.
2. Create data layer (data export from OpenStreetMap via QGIS rendered as 4,096x4,096 textures) - DONE
   
   1. Waterways and shorelines
   2. Borders
   3. Roads and railway lines
   4. Development
   5. Land use (agriculture, forestry, towns)
3. Shader definition and texture creation - DONE
   
   1. The shader for display in Unity is set
   2. The textures are then brought into the required form
4. Import into Unity and processing - DONE
   
   1. Determination of the Unity version used: wil use Unity 2022.3 for now (May 2024)
   2. Specification of texture sizes per platform (probably as 2,048x2,048 due to disk space and download times)
5. Export addressables from Unity3D
   1. Export test
   2. Full export and server upload
6. Version building
   1. Loading the new addressables from the server
   2. Switching the UI display options to the new shader

At the same time, a working prototype must always be available to check the data import. You can see which raw data are already available as textures in the following table.

Texture creation and optimization done

In this step, two composite textures are created from the previously created individual textures. The color channels are put together in such a way that we can accommodate the maximum amount of information in the available color channels. This means the amount of data to be transferred remains manageable. We have 4 color channels (RGBA) available per texture.

• Color texture
  
  • The color texture receives the color gradients of the height data in RGB. All water surfaces and the coastline are blended into this color texture. Since land use can only belong to one group (urban area, agriculture, forest use), all three groups are stored in the alpha channel with different brightness levels. The shader used can then separate the three groups in the software.
• Structural texture
  
  • The remaining data (roads, railways, borders and buildings) can overlap. Therefore, these textures must be saved as individual layers. Thus, each layer is placed in a channel of the structure texture.

Current state in May 2024

The data will now be repackaged and prepared for export. Here, the amount of data per platform must be brought into line with the available storage space on the server. It may therefore be that individual texture sizes have to be created smaller... we'll see that in the end.

Attached is a current picture of the data from the destroyed Kakhovka reservoir. The elevation data is from the time the dam was intact, so no data is available there. It is only possible to subsequently smooth areas with water in the elevation data, but without new data no elevation gradient can be displayed there. The streets, railways and buildings were faded out. I'm also experimenting with a new view here to make the structures more visible on the map.