V&V GMRAD Planet Render

Verification & Validation → GMRAD Planet Rendering

Up to date for Platform 0.39.3.

Written by Connor Jakubik.

---

Verification & Validation for GMRAD Planet Rendering

Known or probable sources of error are italicized.

Some of the functionality in this page is developed open-source in the stp-planet-data-tools repo.

---

Methods - Coordinate Transformations

1. Data in original state are georeferenced rasters

   • Earth and some other global rasters are georeferenced by hand.

2. Reprojection into Gnomonic projection

   • Using 6-sided Gnomonic projection:

     • Each "side" covers an equal area, and is centered on a multiple of 90 degree rotations from the zero-rotation x+ axis pointing vector

     • Gnomonic sides on a globe

       

     • Gnomonic sides on a simple cylindrical projection

       

   • Self-made frame definition .proj files define the Gnomonic transformation for each individual celestial body.

     • Frame definition files were created by trial-and-error to make a valid definition, and they vary in structure from dataset to dataset.
     • The manual trial-and-error involved to make these is a major bottleneck on the work to expanding GMRAD coverage to more planets.

   • Using python gdal.Warp()

     • Shouldn't be anything in here that degrades the data besides normal bilinear resampling error.
     • Hand-defined meters-per-pixel to use
       • Necessary to reduce some huge datasets
     • Lossless compression (TIFF LZW)
     • Using +- (planet radius * 33/32) as min/max bounds (seems to work as expected)

   • Validated with Apollo 17 descent module location.

3. Processing into GeoBin files

   • Using C++ GDAL RasterIO
     • Heavily-iterated-upon and validated code for converting GDAL geotransform coefficients & known gnomonic projection details to grid-aligned sampling coordinates.
     • Accurate down to sub-pixel alignment.

     • TODO details of quad subsets stuff.

     • It's very complex, so there's still the possibility that something is wrong in this code.

4. DataBand GetGrid / GetGradient

   • All integer math; pretty much impossible to mess up without seeing large discrepancies.
   • GetGradient SampleAtPoint for outside-of-side points might not be correct for UV nonlinearity discontinuity, slightly warping gradient values on the absolute edge of a side.

5. Reprojection back into 3D for mesh data

   • Math referenced from various coordinate projection books.
   • Validated with Apollo 17 descent module location.
   • Math that deals especially with noncartesian -> cartesian mapping MIGHT have subtle errors, especially with the normal-vector math. This would only affect lighting graphics visuals (not surface shape or shadows), slightly shifting the way the lighting interacts with the surface.

6. High-resolution dynamic textures mapped onto meshes

   • Validated compensation for UE pixel-is-area effect of bilinear filtering of textures, so our pixels are EXACTLY aligned with the mesh data points.

• Currently, there is a discontinuity seam (visible gap in geometry) at planet side edges at a ~10 meter length scale. My best guess for the cause of this is a problem in the C++ GDAL RasterIO function call that shifts all points on a side by a certain GeoXY offset or dataset pixel offset. Maybe due to a slight mismatch in assumed radius?
• v0.25.0 edit: the discontinuity seam is probably actually a minor issue with the sample-across-subset point-shifting math. Getting a bad value for altitude will result in incorrect bicubic interpolation near the edge of the subset.

---

Methods - Numerical Integrity of Raster Data Point Values

Surface Altimetry

1. Original values bilinear resampled into Gnomonic.
2. Bilinear resampled again into grid-aligned dataset.
3. Besides highest-res LOD, recursively downsampled with Gaussian kernel (2D 1-4-6-4-1 kernel) for mipmapping.
4. Hardcoded scale factor per dataset, used to map lower-bit-depth data representations to 32 bit float meters (what we use at runtime for each grid point height value).
5. Bicubic interpolation for sampling at higher resolution than grid-aligned data.
6. Currently, if a pixel in a data layer is nodata, the layer does not contribute to the result value. This can result in visual holes / spires where nodata exists, because the data sharply jumps to values that were supposed to be replaced by probably-more-detailed values. We don't do any smoothing at the edges of datasets.
7. Used for calculating surface gradient (average of slopes to 4 adjacent points).
8. Our data processing pipeline doesn't explicitly handle non-spherical basis ellipsoids like WGS84. It is possible that georeferenced rasters for altimetry on WGS84 (or another ellipsoid maybe for another planet) are not accurately represented because the ellipsoid eccentricities (oblate Earth) were discarded.

Surface RGB Albedo

1. Original values bilinear resampled into Gnomonic.
2. Bilinear resampled again into grid-aligned dataset.
3. Besides highest-res LOD, recursively downsampled with Gaussian kernel (2D 1-4-6-4-1 kernel) for mipmapping.
4. Hardcoded scale factor per dataset.
5. Per-band, 8-bit integer mapped with 1 = lowest saturation 255 = highest saturation used at runtime for each grid point albedo value.
6. Bilinear interpolation for sampling at higher resolution than grid-aligned data.
7. When available, photometrically normalized datasets are used for surface color.
   • These datasets contain normalized I/F (radiance factor), a physical value representing the fraction of reflected light that reaches a sensor directly "above" a surface (along its normal vector), with a specified light incidence angle (typically 30 or 60 degrees).
   • Example: Sato, H., Robinson, M.S., Hapke, B., Denevi, B.W., Boyd, A.K. (2014) Resolved Hapke parameter maps of the Moon. Journal of Geophysical Research Planets 119, 1775–1805. doi:10.1002/2013JE004580.
   • Otherwise, on rugged or highly cratered terrain like the lunar surface, albedo/color datasets are usually compromised by the persistence of shadows in the images. This creates greatly disruptive fake extra shadows in the terrain visuals.
8. Currently (v0.37.0) using default Unreal Engine BRDFs (Bidirectional Reflectance Distribution Function), but interested in using a custom BRDF/BSDF such as Hapke parameters for planet surface rendering.
9. Moon
   • Using photometrically normalized color data for +-70 deg latitude, and color-matched 643nm monochromatic photometrically normalized data for the poles.
   • Local datasets vary.
10. Earth
    • Blue Marble Next Generation global datasets used with arbitrary scale factors to match real imagery.
      • Subjectively, not noticeably impacted by shadows.
    • Local datasets vary.
11. Mars
    • Mars Viking Color Mosaic is near real color.
      • Visible shadows, especially in canyons and some crater walls.
    • (v0.37.0) in testing stages of using Tianwen-1 Global Color Mosiac.
      • Visible shadows, especially in canyons and some crater walls.
    • Local datasets vary.
12. Vis Mono Albedo is optionally blended with all 3 R,G,B channels using the common Overlay algorithm.

Surface Emissivity

1. Original values bilinear resampled into Gnomonic.
2. Bilinear resampled again into grid-aligned dataset.
3. Besides highest-res LOD, recursively downsampled with Gaussian kernel (2D 1-4-6-4-1 kernel) for mipmapping.
4. Hardcoded scale factor per dataset.
5. Per-band, 8-bit integer mapped with 1 = lowest brightness 255 = highest brightness used at runtime for each grid point emissive value.
6. Bilinear interpolation for sampling at higher resolution than grid-aligned data.
7. Very difficult to find color-space standards information required to perform photometry calculations to determine physically-based emissivity value. At the moment it's just eyeballed.
8. Possible to do blackbody radiation simulation in a DataBand with accurate physical photometric properties. We haven't done it yet.

Ocean / Lakes / Rivers

1. Earth water surfaces are rendered with lower roughness and higher specularity, along with some normalization
2. Land/Water Mask currently based on Bathymetry dataset, which has significant flaws (threshold away from coastlines, improperly covers sub-sea-level areas like the Dead Sea).
3. Land/Water Mask currently based on Vis Color dataset, which has significant flaws (doesn't have good fit with real coastlines due to color changes, various near-blue land areas are improperly considered water).

---

Methods - Other Rendering Tech

Atmosphere / Clouds

1. Physical values drive UE SkyAtmosphere Rayleigh and Mie scattering simulation.
   • We have rederived the underlying physics and we provide an engineering-value interface to planet atmosphere properties
   • We have resolved a few artifact-causing issues that result from using realistic values for planets besides Earth.
2. Rayleigh scattering properties
   • Atmosphere Scale Height for Rayleigh-interacting particles
   • Molecular density of particles at atmosphere "sea level"
   • Scattering strength specified via "extinction" value per each R,G,B color
     • For planets besides Earth, work still in progress to correct color variation
3. Mie scattering/ properties
   • Atmosphere Scale Height for Mie-interacting particles
   • Molecular density of particles at atmosphere "sea level"
   • Scattering strength specified via "extinction" value per each R,G,B color
     • For planets besides Earth, work still in progress to correct color variation
   • Absorption strength specified via "extinction" value per each R,G,B color
     • For planets besides Earth, work still in progress to correct color variation
4. Other
   • Tent distribution (Specialized solution for the Earth ozone layer)
5. Air Glow is not modeled yet.
6. Auroras are not modeled yet.
7. Flat clouds Blue Marble dataset has lots of artifacts (seams, etc).
8. Volumetric clouds are WIP.

Lighting

1. Direct sun lighting
   • Affected by atmosphere transmission.
   • Sun lighting direction and intensity is determined based on camera position and applied solar system wide. This is incorrect for far planets (especially those at opposition).
     • Could be avoided by doing impostor rendering for planets.
2. Raytraced shadowing
   • Range (caster to cast-upon) is enough for most of Jupiter's moons to be shadowed by it.
   • Disabled as of v0.25.0 due to issues in UE 5.4.
3. Virtual Shadowmaps
   • Range (camera to cast-upon) is ~2600 km, enough for surface details on planets to be shadowed far enough away.
     • Possible to add additional cascades for more distance at a performance cost.
   • After sunset, near back-faces of planets are not properly shadowed by far front-face geometry, leading to specks of light leaking through the planet.
     • Several straightforward solutions possible.
4. Realtime-captured skylighting
   • Approximation of reflections and global illumination.
   • Affected by atmospheric scattering.
   • Sometimes nonphysical, especially when above a sunset.
   • Applied everywhere (Earth skylighting applied to moon as if moon was next to the camera).
     • Could be avoided by doing impostor rendering for planets.
5. Moon lighting onto Earth
   • Not currently implemented in ST as of v0.28.0.
   • Second light source effects on atmospheric scattering are supported by UE.
6. Stellar background lighting (very dark)
   • Disabled currently due to possible incompatibility with realtime-captured skylight.
7. Atmospheric scattering transmission tints Sun bloom
   • Broken or improperly configured as of v0.28.0 / UE 5.4. (fixed in v0.37.0)

Photometry summary

There are many information transformations that happen from real light -> lens -> sensor -> quantization into raw imagery -> processing -> published dataset -> reprocessing for real-time use -> runtime data resampling/blending -> load into GPU buffers/textures -> rasterization -> shader code -> direct and indirect lighting -> postprocess effects -> tonemapping / HDR -> user monitor settings -> user's room lighting -> user eyeballs. I will attempt to describe and address all of these.

WIP

1. Real light -> Lens

• Aberrations:
  • Lens distortion
  • Bloom
  • Sensor Saturation
  • Sensor noise (when not significantly above noise floor)

---

Verification - Geometry and Coordinates

3D location of various fixed points

1. Apollo 17 Descent Module

WIP

2. South Rim at Big Bend National Park

Real photo taken on January 18, 2025: GMRAD Big Bend dataset at the same date and time: