---
title: 'MARTIAN: Mars Aerial Rendering Framework'
url: https://www.emergentmind.com/topics/martian
type: topic
---

# MARTIAN: Mars Aerial Rendering Framework

Searching arXiv for the MARTIAN framework paper and closely related Mars aerial localization work.
arXiv.search query: id:2605.29647
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 [2605.29647]. 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 [2605.29647]. 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 \(\mathbf{t}_{WC}\) is the camera center in \(W\), and \(\mathbf{R}_{WC}\in SO(3)\) orients the camera so that its \(Z\) axis points toward the terrain and \(X\) spans image width. To place the camera at altitude \(h_C\) above the terrain, MARTIAN casts a ray from \((x,y,h_{\max})\) straight down, finds the first mesh intersection to obtain \(h_{\rm ground}\), and sets

\[
\mathbf{t}_{WC}=
\begin{bmatrix}
x\\
y\\
h_{\rm ground}+h_C
\end{bmatrix}.
\]

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 \(p\), the outgoing radiance in direction \(\omega_o\) is

\[
L_o(p,\omega_o)
=
\int_{\Omega^+}
f_r(p,\omega_i,\omega_o)\;
L_i(p,\omega_i)\;
(\mathbf{n}\!\cdot\!\omega_i)\;
\mathrm{d}\omega_i.
\]

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

\[
f_r(\omega_i,\omega_o)
=
\frac{D(h)\,G(\omega_i,\omega_o)\,F(\omega_i)}
{4\,(\mathbf{n}\cdot\omega_i)\,(\mathbf{n}\cdot\omega_o)}.
\]

The Sun is modeled as a distant light source of spectral irradiance \(E_\odot\) with direction

\[
\hat{\omega}_\odot
=
\begin{bmatrix}
\cos(\mathrm{EL})\,\cos(\mathrm{AZ})\\
\cos(\mathrm{EL})\,\sin(\mathrm{AZ})\\
\sin(\mathrm{EL})
\end{bmatrix},
\]

where **EL** is elevation and **AZ** is azimuth. Shadow softness is tuned by the Sun’s apparent angular diameter, with \(\alpha_\odot\approx0.35^\circ\), and irradiance is set to Mars’s mean of **590 W/m\(^2\)**.

All major scene variables are scriptable or randomizable within user-defined bounds. These include camera altitude \(h_C\in[64,200]\)\,m, map \(XY\)-location sampled uniformly over the DTM extent, Sun elevation \(\mathrm{EL}\in\{30^\circ,60^\circ,90^\circ\}\) or continuous, Sun azimuth \(\mathrm{AZ}\in[0,360^\circ)\), camera intrinsics, optional camera attitude errors, and material roughness and albedo. For random solar geometry, the paper specifies

\[
\mathrm{AZ}\sim\mathcal{U}(0,360^\circ),\qquad
\mathrm{EL}\sim\mathcal{U}(30^\circ,90^\circ).
\]

Ground-truth pose export is correspondingly exact. Blender’s camera world matrix \(T_{W\leftarrow C}\) 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 \((f_x,f_y,c_x,c_y)\), a rotation matrix \(\mathbf{R}\), and a translation vector \(\mathbf{t}\), 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 [2605.29647]. 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@\(d\)**, the percentage of localizations within \(d\) 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.

Source: https://www.emergentmind.com/topics/martian