MARTIAN: Mars Aerial Rendering Framework

• MARTIAN is a Blender-based framework that uses real HiRISE DTMs and ortho-images to generate physically accurate, annotated aerial imagery of Mars for vision-based navigation.
• It integrates a Python pipeline for data import, mesh construction, UV mapping, and Cycles rendering to output images with exact camera pose, depth maps, and metadata.
• Validation in Ingenuity and rotorcraft localization pipelines demonstrates significant improvements in navigation accuracy under varied illumination and terrain conditions.

Searching arXiv for the MARTIAN framework paper and closely related Mars aerial localization work. arXiv.search query: id:(Pisanti et al., 28 May 2026) MARTIAN, expanded as Mars Aerial Rendering Tool for Imaging And Navigation, is an open-source Blender-based rendering framework that turns real HiRISE orbital map products into physically faithful, fully annotated aerial images of the Martian surface for vision-based navigation research (Pisanti et al., 28 May 2026). It was designed to address a specific bottleneck in aerial navigation on Mars: the scarcity of large-scale, annotated aerial datasets under diverse illumination conditions and terrain morphology. Its core contribution is a Python–Blender pipeline that couples HiRISE Digital Terrain Models and ortho-rectified imagery to physically based rendering, while exporting exact camera pose annotations, depth maps, and associated metadata.

1. Definition, scope, and research motivation

MARTIAN was introduced for aerial navigation on Mars, where vision-based pipelines must remain robust to diverse illumination conditions and terrain morphology. The framework leverages real HiRISE orbital map products to synthesize realistic aerial views under controllable lighting conditions and at varying altitudes, and it generates observations with accurate pose annotations (Pisanti et al., 28 May 2026). In the terminology of the framework, the objective is not generic image synthesis but the production of training and evaluation data for map-based localization and related vision tasks.

A common misconception is to treat MARTIAN as a procedural scene generator detached from planetary data. In fact, its inputs are real HiRISE DTM tiles and ortho-images, and its outputs are tied to the geometry and texture of specific Martian sites such as Jezero. This distinguishes it from synthetic-only pipelines and explains why it was validated in concurrent work on map-based localization systems for Ingenuity and future Mars rotorcraft.

2. End-to-end architecture and workflow

The framework comprises three modules and an associated workflow that begins from orbital topography and ends with rendered images plus exact annotations.

Module	Function	Outputs
Data Import & Preprocessing	Extracts HiRISE DTMs and ortho-rectified imagery; converts them into Blender-compatible meshes and textures	Terrain mesh, texture assets
Scene Setup & Parameter Control	Drapes the ortho-image onto the terrain mesh; configures virtual cameras and Sun light source	Parameterized scene
Rendering & Annotation Export	Uses Cycles physically based path tracing and exports frame-level metadata	RGB or grayscale images, depth maps, camera extrinsics and intrinsics

A typical workflow is explicitly defined. First, a 1 m-per-post HiRISE DTM tile and its 0.25 m-per-pixel ortho-image are downloaded for Jezero. Second, these are ingested into Blender using a modified PhaseIV “Blender-HiRISE-DTM-Importer” plug-in, which builds a triangular mesh at user-specified resolution. Third, UV coordinates are automatically generated from the georeferenced ortho-image metadata and assigned to a Principled BSDF material. Fourth, camera intrinsics and a 6-DOF pose $(\mathbf{R}_{WC},\mathbf{t}_{WC})$ are scripted in the East–North–Up world frame $W$. Fifth, Sun parameters—elevation, azimuth, irradiance, and angular diameter—are scripted. Sixth, the scene is rendered with Cycles, while depth, segmentation if needed, and exact camera pose are exported.

This staged structure makes the framework simultaneously a rendering system and an annotation engine. A plausible implication is that MARTIAN is best understood as infrastructure for controlled sim-to-real experimentation rather than as a standalone graphics application.

3. Geometric representation and coordinate conventions

As delivered by the HiRISE pipeline, the DTM is a regular grid of height posts $h_{ij}$ at map coordinates $(x_i,y_j)$. MARTIAN’s importer builds a mesh whose vertices in the world frame $W$ are

$$\mathbf{p}_{ij} = \begin{bmatrix} x_i\ y_j\ h_{ij} \end{bmatrix}, \qquad x_i = x_0 + i\,\Delta_x,\; y_j = y_0 + j\,\Delta_y,$$

with $\Delta_x=\Delta_y=1\,\mathrm{m}$ for the 1 m-post DTM. These vertices are then connected into a triangulated mesh. Texture coordinates are obtained by simple equirectangular projection from the ortho-image. When loading at reduced resolution, for example 10%, the importer downsamples the grid, builds a coarse mesh, drapes the texture, and can then reload the full-resolution mesh for final rendering.

Once inside Blender, all objects live in a common world frame $W$. The camera frame $C$ is defined by

$$\mathbf{X}_C = \mathbf{R}_{WC}\,\bigl(\mathbf{X}_W - \mathbf{t}_{WC}\bigr) \quad\Longleftrightarrow\quad \mathbf{X}_W = \mathbf{R}_{WC}^\top\,\mathbf{X}_C + \mathbf{t}_{WC}.$$

Here $W$0 is the camera center in $W$1, and $W$2 orients the camera so that its $W$3 axis points toward the terrain and $W$4 spans image width. To place the camera at altitude $W$5 above the terrain, MARTIAN casts a ray from $W$6 straight down, finds the first mesh intersection to obtain $W$7, and sets

$W$8

These conventions are central to the utility of the framework for localization. Because the terrain geometry and camera pose are both expressed in a shared metric frame, the rendered observations are directly usable by geometric vision pipelines.

4. Rendering model, lighting control, and annotation export

MARTIAN uses Blender’s Cycles engine, which solves the rendering equation by Monte Carlo path tracing. At each surface point $W$9, the outgoing radiance in direction $h_{ij}$0 is

$h_{ij}$1

The terrain material uses the Principled BSDF, formulated as a microfacet Cook–Torrance model,

$h_{ij}$2

The Sun is modeled as a distant light source of spectral irradiance $h_{ij}$3 with direction

$h_{ij}$4

where EL is elevation and AZ is azimuth. Shadow softness is tuned by the Sun’s apparent angular diameter, with $h_{ij}$5, and irradiance is set to Mars’s mean of 590 W/m$h_{ij}$6.

All major scene variables are scriptable or randomizable within user-defined bounds. These include camera altitude $h_{ij}$7\,m, map $h_{ij}$8-location sampled uniformly over the DTM extent, Sun elevation $h_{ij}$9 or continuous, Sun azimuth $(x_i,y_j)$0, camera intrinsics, optional camera attitude errors, and material roughness and albedo. For random solar geometry, the paper specifies

$(x_i,y_j)$1

Ground-truth pose export is correspondingly exact. Blender’s camera world matrix $(x_i,y_j)$2 is read after each render and written to a JSON record alongside the image and depth filename. A typical entry contains the image path, depth path, intrinsics $(x_i,y_j)$3, a rotation matrix $(x_i,y_j)$4, and a translation vector $(x_i,y_j)$5, with positions expressed in the East–North–Up world frame in meters.

5. Validation in map-based localization pipelines

The principal empirical validation of MARTIAN is its deployment in two concurrent localization pipelines (Pisanti et al., 28 May 2026). In the first, Ingenuity Map-based Localization (MbL) used LoFTR pre-trained on 4 500 MARTIAN observations and 17 orthographic maps. On real Ingenuity NAVCAM images matched to a HiRISE reference map, localization performance was measured using Acc@$(x_i,y_j)$6, the percentage of localizations within $(x_i,y_j)$7 meters. Without synthetic pre-training, Acc@5 m = 78.2 %. With MARTIAN pre-training + flight fine-tuning, Acc@5 m = 89.4 %, an increase of +11.2 %. The same system achieved Acc@10 m = 99.8 %.

In the second, Future Mars Rotorcraft (MSH) used Geo-LoFTR, described as geometry-aided LoFTR, trained exclusively on MARTIAN data under varied lighting. On held-out synthetic scenes, the reported gain was up to 31.8 % relative improvement in Acc@1 m under extreme illumination shifts. On real Mars2020 EDL LCAM frames matched to a 6 m/px CTX map, the system produced consistent global localizations from 6 km → 960 m AGL.

These validation results are significant because they establish sim-to-real transfer under precisely the conditions that motivate the framework: varying altitude, strong lighting variability, and the absence of large annotated aerial datasets. This suggests that the combination of real HiRISE geometry with physically based rendering is sufficient to train deep image matchers that remain useful on real Mars imagery.

6. Software characteristics, usage, and interpretive context

The codebase is open source at https://github.com/nasa-jpl/martian and requires Blender 4.0+ with Cycles GPU support. The installation sequence given is to clone the repository, run pip install -r requirements.txt, and activate the “HiRISE DTM Importer” and “Martian” add-ons in Blender. Typical render times are 0.5–2 s per 1024×1024 frame on an NVIDIA RTX 30-series card, using 4–8 samples/pixel for draft quality. Outputs include PNG or OpenEXR images, depth maps in OpenEXR, and JSON annotations per image; ortho maps can be exported in GeoTIFF.

A second misconception is that MARTIAN is limited to RGB image generation. The framework in fact exports RGB or grayscale images, depth maps, segmentation if needed, exact camera extrinsics, intrinsics, and scene metadata. Another misconception is that its geometric labels are approximate because they are synthetic; the paper instead emphasizes “perfect ground-truth poses” derived directly from Blender’s transforms.

Within Mars robotics, MARTIAN occupies a specific methodological position. It is neither a pure simulation environment nor a planetary remote-sensing pipeline in isolation. Rather, it is a tightly integrated path-tracing pipeline that starts from real HiRISE DTMs and texture maps, proceeds through coordinate-accurate mesh construction, and ends in high-fidelity, annotated aerial imagery. A plausible implication is that its main long-term value lies in enabling controlled experiments on illumination, scale, and terrain while preserving direct compatibility with real orbital cartography.