Lunar Spatial Data Handling

[Difint]

Lunar Spatial Data Handling

Isn't it cool to walk on the Moon? Even in a simulation

Expected outcome

Being able to click on any location on the moon and have a decent 3D model of the location to traverse it using existing operators

Problem

High-quality 3D map of the Moon is crucial for mission planning. Such a map should be able to include several layers, like Rocks distribution, Dust dencity, etc.
Visualisation of mission location, and possibility to quickly try different ways to travers it would cool.
Planet-scale data storage is a solved problem with tons of existing solutions, howevert it's still a very trick task.
There are tons of open data sources, so ideally the whole pipilene of data merging to be implemented in an easy-to config way.
NASA Moon CGI Kit is a nice starting point. It has:

• The color map: 24-bit RGB TIFF, max 27360x13680 pix (494.1 MB)
• Height map: 23040x11520 pix (1012.6 MB) 64 ppd (pixel per degree)  floating-point TIFFs in kilometers, relative to a radius of 1737.4 km

Solution

There is a an interesting MTerrain plugin designed to handle openworld games. For the lunar environment there could be a planetary level LOD generated, when at big distances it's just a texture.

H(lat, lon) - heigh of the terration at lat, log

In general the idea is to divide the whole lunar surface into chunks and have LODs. At some level chunk should have a decent quality and be to scale, allowing traversing of the area

Questions

1. Chunk size should be tuned to MTerrain, e.g. 100x100 meter
2. How H relates to Height map, conversion function?
3. What 64 ppd means? It means that for each degree there are 8 measures, so spatial resoultion is 1/8 of the degree?

[philiplinden]

This toolkit supplies data in higher spatial resolutions but I don't know what the technically feasible limit would be for the sim.

For example, this dataset is available at up to 512 pixels per degree (~60m per pixel at the equator, better at high altitudes) https://pgda.gsfc.nasa.gov/products/67

Here's an interesting article on how the Kerbal Space Program devs approached this problem https://forum.kerbalspaceprogram.com/topic/205930-developer-insights-12-%E2%80%93-planet-tech/

[philiplinden]

Would it make sense to offer levels that are hyper-detailed but limited regions? For example, Blender has been used to render photorealistic terrain for use by optical navigation sims: https://ntrs.nasa.gov/api/citations/20210023848/downloads/smith_scitech_2022_TRN_Blender_final.docx.pdf

Most surface missions will be located in select areas, and orbital missions don't need terrain detail better than the height maps offered by the Moon CGI kit linked in the OP

[Difint]

Great point!

In Game Development there is a term LOD - Level of Details depending on the distance from camera to model.

With that in mind my idea is to split all the Moon into X*X meter chunks. Thous chunks could be updated separately, so existing dataset could be used to build initial map, and then with the new data coming, it could be constantly updated and versioned

[philiplinden]

https://github.com/outobugi/Terrain3D 👀 Can import terrain from height maps, 10 Loads and 1x1k stitching https://youtu.be/NwJEXOglBrQ

[Difint]

Thx, seems like these guys (Terrain3D) made an impact, I've seen a lot of posts on twitter.

I had no time to check their code, but seen a video. I have concern that their approach:

1. Requires a lot of memory, as they store the whole map there and dynamically adjust LODs
2. They've mentioned something like 65kx65k, I'm not sure what it means yet, but compared to M Terrain it sounds limiting

Right now I'm trying to figure out how to slice the Moon surface into plain chunks and then how to add curvature to the whole Moon. I think in a couple of days I'll have the answer

[Difint]

After taking a deeper look Terrain3D looks more promising. I was able to build it from source, and now I'm trying to figure out how to apply Procedural Quad Sphere to it.

[Difint]

A lot of "Globe"-related math could be found in this project

https://github.com/NASAWorldWind/WorldWindJava

[Difint]

I need to wrap ideas about solar-system scale simulation. Post will be updated

Based on KSP 2 blog, GMat, Basilisk, WorldWind, NASA CMS, and other:

1. GMAT is bespoke leader in mission planning. It's not only worth to rely on it in orbital mechanics, it also a great source for design inspiration, easy to integrate into GDExtension
2. Basilisk is another great tool, however it's more focused on Python workflow, and not so advanced in terms of simulations

From my perspective those are the most important things to address:

1. Different physical models should be used for different interactions, works separatly from visual part, mostly on server/CPU
2. Visual engine works differently from physics, mostly on client and GPU
3. Those scales makes sense: human-sized (tens of meters), orbital, interplanetary. Different models for physics and visuals to be used as well
4. There are tons of physical coordinates systems with different properties used for different purposes, e.g. planet centric and surface centric.
5. Such a huge difference in scale causes rounding error. Makes sense to have a tree like coordination system where object defined relative to each other, and for precise calculations use origin shifting. For visual it'll be related to camera, for physics related to objects and currenly used models