Fast High-Resolution Lunar Surface Visibility Analysis Using a GPU Ray Tracing Framework

FAST HIGH-RESOLUTION LUNAR SURFACE VISIBILITY ANALYSIS USING A GPU RAY TRACING FRAMEWORK. T. Junkermann1, M. Schwinning1, M. Hutton1, F. Renk1, 1ESOC, European Space Operations Centre, Robert-Bosch-Straße 5, 64293 Darmstadt, Germany, Theresa.Jun[email protected]. Introduction: Almost 60 years after the first soft lunar landing, the Moon has again become a priority target for space exploration, with nine lunar landing missions by eight different entities launched in the past three years alone. The European Space Agency (ESA) is currently also working towards its first Moon landing in 2031, with ESA’s Terrae Novae 30+ strategy roadmap [1] naming “autonomous Moon landing capabilities for European-led missions” a key goal. As part of these efforts, the Mission Analysis section at ESA’s European Space Operations Centre (ESOC) is building a set of tools for lunar surface modelling, analysis and landing site identification. Central to ESA’s lunar surface strategy is the Argonaut project, with repeated lunar surface missions planned from 2031 onward. While Argonaut is designed to provide global access to the Moon, the first two flights will target the lunar south pole region, an area with enormous science potential and unique lighting conditions. At the lunar south pole, illumination patterns are highly irregular due to the typically low elevation of the Sun. For any mission landing in this region, understanding illumination and Earth visibility is key: landing site selection and further mission planning depend on it. This type of visibility analysis is computationally intensive, especially if performed over long periods and large areas at high spatial and temporal resolution, which makes hardware acceleration techniques like GPU parallelization desirable. GPU-based ray tracing is frequently used for thermal analysis of smaller areas on the lunar surface, but has only recently been applied to large-scale visibility analysis [2]. Previous work has checked every possible ray-triangle intersection, requiring a large GPU cluster to support the computations. In this paper, we make use of Nvidia OptiX [3] – a dedicated ray tracing acceleration framework from the field of computer graphics – to produce high-resolution binary visibility results in a matter of minutes, even on a lowend gaming GPU. Analysis Case: Typically, we are interested in visibility analysis of several million sites at once, with up to tens of thousands of time steps (e.g. 2 km x 2 km area at 1 m spatial resolution ≈ 4,000,000 sites, 3 years at 1 h temporal resolution ≈ 26,300 epochs). We model the target body (e.g. Sun/Earth) as a single point in space which is either seen or not seen from a lunar surface site (binary visibility). To model the terrain, we employ a combination of up to three different digital elevation models (DEMs), such that DEM resolution increases with proximity to the site. This usually means large-scale Lunar Orbiter Laser Altimeter (LOLA) DEMs [4] further away from the site, as well as local high-resolution shape-fromshading (SFS) [5] DEMs immediately around the site (see Table 1 for details). The software supports the analysis of different altitudes above the lunar surface for the set of sites. DEM type Resolution [m/px] Typical usage radius [km] LOLA 118 220 LOLA 5 or 10 10 SFS 1 0.1-1 Methods: The technique of ray tracing originates in the field of computer graphics, mainly in the context of rendering 2D images based on 3D models of a scene (see e.g. [6]). We apply it to the lunar surface visibility problem as follows. Mesh Generation. First, we generate a 3D mesh model of the lunar surface from the relevant section of the DEM file, converting the data to the Moon-centered, Moon-fixed (MCMF) coordinate frame using GDAL [7]. Each DEM pixel becomes a mesh vertex, and neighboring vertices are connected into triangles, resulting in a continuous approximation of the lunar surface. This is done at runtime, allowing flexibility with regards to the extent of the mesh. Target Body Positions. A lookup table of target body positions in the MCMF frame is precomputed once using SPICE kernels [8], and target body positions for the appropriate epochs are read from file at runtime. Ray Tracing. For each site and each epoch, we trace a ray from the site to the current target body position. If the ray intersects with the lunar surface mesh, then the target body is not visible. If no intersection is found, then the target body is visible. To efficiently handle these computations, we make use of the Nvidia OptiX ray tracing framework [3]. It organizes the surface mesh into an acceleration structure using the bounding volume hierarchy method. Thanks to the acceleration structure, the number of intersection tests performed is only a fraction of the total number of mesh elements: for a number of DEM pixels on the order of n2, the number of intersection tests is on the order of log(n). Tiling and Batching. Due to a numerical limit in OptiX, no more than 230 site-epoch combinations can be handled in one run. With 1 m spatial and 1 h temporal resolution, this equates to e.g. 1200 m x 1200 m Table 1: Overview of DEMs used for the visibility analysis. over 31 days. For areas and periods that exceed this size, we make use of spatial tiling and epoch batching strategies, wherein the algorithm iterates over a set of area/interval chunks. This is also useful when working on lower-end GPUs with limited VRAM, since the generated meshes may be large. Results: As an example, we consider a region of interest for ESA’s PROSPECT mission [9]. Figure 1 shows the mesh generated from the SFS DEM for the region. The software produces binary visibility maps for each epoch of interest, like the one shown in Figure 2. Computation time. Runtime is influenced by several factors. Most significant are the number of sites, number of epochs, and altitude above the lunar surface. In Table 2, we present some runtimes for visibility analyses without any tiling/batching, varying each significant parameter around the following baseline case: analysis area 1 km x 1 km at 1m spatial resolution, time period 30 days at 1h temporal resolution, altitude of 1m above the lunar surface. All computations are performed using a Nvidia RTX 3050 Ti. Clearly, the overall runtime is not dominated by the ray tracing itself, but by other steps in the process: constructing the mesh, building the OptiX acceleration structure, and saving the binary visibility data. Scaling. Using the tiling/batching strategy, significantly larger areas and time intervals can be analysed. If area/interval chunks are chosen for the maximum chunk size of 230 site/epoch combinations, the runtime simply scales linearly with the number of chunks. The largest analysis done so far covers a 6 km x 6 km area over a period of one year, at resolution 1 m/1 h and altitude 0.02 m. The computation took ca. 100 mins. Comparison to Horizon Mask Method. The software previously used at ESOC for lunar surface visibility analysis is also GPU-accelerated, but based on the horizon mask method [10]. Essentially, it understands each DEM pixel as a small flat area in order to compute the horizon mask, meaning its approximation of the lunar surface is piecewise constant. In contrast, the mesh used by the ray tracer is a continuous model of the lunar surface. Consequently, the ray tracer offers more precision on the shadows cast by the terrain, and is able to reduce certain types of artefacts in the results. Furthermore, the ray tracer offers a significant runtime advantage over the previous horizon mask software (factor ~4-10 depending on exact use case). Summary: Using a dedicated ray tracing framework such as OptiX offers significant advantages for lunar surface visibility analysis. Runtimes are on the order of minutes even on basic graphics hardware, enabling the analysis of large areas over long periods at high spatial and temporal resolution. In addition, some runtime and precision advantages over the horizon mask method are also observed. References: [1] Strategy and Innovation Team ESA Human and Robotic Exploration directorate (2021). [2] Thomas Montano and George Bussey (2022) 2022 IEEE Aerospace Conference (AERO). IEEE, 2022. [3] Steven G. Parker et al. (2010) ACM Transactions on Graphics (TOG), 29.4, 1-13. [4] M. K. Barker et al. (2023) The Planetary Science Journal, 4.9, 183. [5] R. A. Beyer, O. Alexandrov, and S. McMichael (2018) Earth and Space Science, 5.9, 537-548. [6] Steven G. Parker et al. (2013) Communications of the ACM 56.5, 93-101. [7] GDAL/OGR contributors (2025). GDAL/OGR Geospatial Data Abstraction Software Library. Open Source Geospatial Foundation. https://gdal.org. [8] C.H. Acton (1996) Planetary and Space Science, 44.1, 65-70. [9] Orgel et al. (2025) European Lunar Symposium (ELS), Abst. #XXXX. [10] E. Mazarico et al. (2011) Icarus, 211, 1066-1081. Table 2: Input parameters vs. runtime for the raytraced visibility analysis. Base configuration in first row; the varied parameters are highlighted in blue. AOI [m] days altitude [m] ray-tracing time [s] full time [s] 1000 30 1 1.26 14.08 800 30 1 0.81 10.28 1200 30 1 1.82 18.75 1000 20 1 0.93 10.83 1000 40 1 1.73 17.19 1000 30 0.02 1.40 15.56 1000 30 5 1.19 13.80 Figure 1: Mesh generated from local SFS DEM for PROSPECT site. Figure 2: Binary visibility results for one epoch.