V&V GMRAD Planet Render

Verification & Validation → GMRAD Planet Rendering

Up to date for Platform 0.28.0.

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
   • 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.
   • (currently unused) Hand-added shifting ("false northing / easting" IIRC) by certain amount of meters on the geotransform.
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. On rugged or highly cratered terrain like the lunar surface, albedo datasets are usually compromised by the persistence of shadows in the images. This creates greatly disruptive fake extra shadows in the terrain visuals. Shadow removal techniques are being devised to clean up the data. Ideally, we would be rendering albedo from data that is uncorrupted by shadows (like surface material composition & roughness data).
8. Very difficult to find color-space standards information required to perform photometry calculations to determine physically-based albedo per-band.
   • There are many color transformations that happen from real light -> lens -> sensor -> raw imagery -> published dataset -> GMRAD blending -> unreal texture -> unreal material -> unreal lighting -> unreal tonemapping / HDR -> user monitor settings -> eyeballs
9. At the moment we have an arbitrary scale factor and possible missed conversion to/from sRGB that affects the value. It looks ok for our Earth textures but Mars visible RGB seems less red/orange than it should be.
10. Vis Mono Albedo is 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. Definitely 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.
2. General atmosphere properties
   • Scale Height
3. Rayleigh scattering properties
   • Molar density of particles at atmosphere min altitude
4. Mie scattering properties
   • Molar density of particles at atmosphere min altitude
5. Other
   • Tent distribution (Earth ozone layer?)
6. Air Glow is not modeled yet.
7. Auroras are not modeled yet.
8. Flat clouds Blue Marble dataset has lots of artifacts (seams, etc).
9. 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.

---

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: