You are browsing as a guest. Sign up (or log in) to start making projects!

samcberry

@samcberry

Joined June 27th, 2026

  • 4Devlogs
  • 1Projects
  • 0Ships
  • 0Votes
Open comments for this post

52m 17s logged

Day 3: Making the Moon actually orbit (ugh)

Today i had to do two things. First, finishing the terrain feature from Day 2 (i put it off), and building a real time astronomical engine so the Earth and Moon are where they actually are.

Wiring up the terrain analysis

First I connected Day 2’s landing-point analysis to the frontend. So now when you select a landing area, you click a button that says “Search Area”. It will then pull the most optimal exact landing coordinates from precomputed data (for reference, I made a simple python script that downloaded official NASA .TIFF files for areas of interest, analyzed each pixel that shows slope and such, and found the most optimal landing point in that area).

So I wanted to test if it worked. I plugged in the coordinates into a moon map I found online, and zoomed in on Nobile Rim 2 and its exact marker, and you can see why the algorithm picked that spot. The marker lands on a smooth flat patch while the crater walls and shadowed pits around it get avoided.

The orbital model

Here is the bigger piece. I wanted the Earth and Moon to be synced to real world time. So I built a standalone module that turns any timestamp into the correct geometry. This includes Earth’s rotation angle, the Moon’s position in its orbit, the tidal-locking, the Sun direction, and the moon phase.

The positions use standard mean orbital elements, the Meeus algorithms, which are accurate to about a degree. Not full JPL-ephemeris precision, but it’s fine for now. Exact placement is a later upgrade once the Horizons backend is in.

Verifying it’s actually right

This is the part I’m happy about. Instead of building the whole 3D scene and really really hoping the math was right, I kept the orbital model separate and tested it against reality first. Sooooo i fed it the current time and checked the output: 402,389 km Moon distance (real range is 356k–406k), and it reported a waning gibbous moon at 97% illuminated. Then I checked the actual moon phase for tonight. Waning gibbous, 97 to 99%. It matched. YES!!!

The time engine

I also built the simulation clock that’ll drive everything: play/pause, speed control from real time up to a week per second, a live “follow the real clock” mode, and jump-to-any-date. If you’ve ever played Universe Sandbox, it’s like that. Time always runs at whatever rate you set, and you pause it yourself if you want the Moon to hold still. Got it ticking cleanly at a steady one second per second, verified against wall clock UTC.

The unglamorous part

Also spent a genuinely stupid amount of time untangling git after accidentally committing a 250MB Python virtual environment and a folder of giant NASA GeoTIFFs. GitHub has a 100MB file limit, which I discovered the hard way when it rejected the push. Lesson permanently learned: write the .gitignore first.

Next

Wire the verified orbital model into the actual 3D scene, the literal Moon-orbits-Earth motion, tidal locking, and the time-control bar. Then on to the launch window calculator with real JPL Horizons ephemeris.

0
0
0
Open comments for this post

25m 19s logged

Day 2: Real NASA terrain analysis

Today I built the part that actually finds the best landing site in an area near the south pole of the moon. I wrote a Python pipeline that processes real NASA 5-meter-per-pixel lunar terrain data to find optimal landing points.

What it does

The script pulls real slope GeoTIFFs from NASA’s Planetary Geodynamics Lab (PGDA). for reference, that’s the same 5m/px Digital Elevation Models used for actual Artemis landing site selection. For each candidate region it:

  1. Downloads the real slope raster (40–140 MB each)
  2. Scores every location by the mean slope across a 100m lander footprint, because a real landing zone has to be flat across the whole area the lander occupies
  3. Finds the optimal point down to around 5m of precision
  4. Converts the winning pixel from polar-stereographic coordinates back to lat/lon (this part sucked)
  5. Writes everything to a JSON file the app serves instantly

Results

Processing NASA’s actual DEMs, the optimal landing points came out to:

  • Nobile Rim 2: 0.45° mean slope over 100m
  • Haworth: 0.91°
  • Shackleton Crater Rim: 1.15°

The hard part

Two bugs. The first version picked nodata artifact pixels that read as “perfectly flat 0.0°.” The single-pixel approach could also land on a fluke-flat spot surrounded by cliffs. Fixed both: excluded the artifact values, then switched to integral-image windowed averaging so it evaluates the full lander footprint in O(1) per location instead of brute-forcing it.

Next

Wiring this into the frontend so “Search Area” surfaces the precise optimal point, then on to the launch window calculator using JPL Horizons ephemeris.

0
0
1
Open comments for this post

47m 48s logged

Day 1 (part 2): Cinematic Earth and Moon intro

Spent today building the entire visual foundation of Artemis Navigator. pretty dope

What I built

The opening shot: has a cinematic view with Earth as a massive curved horizon on the left, with the moon in the distance.

Photoreal Earth: built from real NASA/Solar System Scope 8K textures. It includes a day map, cloud layer, specular ocean reflections, and normal-mapped terrain. Wrote a custom GLSL atmosphere shader with a Fresnel limb glow that fades into space as a real gradient instead of a hard ring. That part took the most iteration.

The Moon: tidally locked (it doesn’t rotate relative to Earth, just like irl), textured with the actual NASA LRO color map.

Lighting & post: ACES-style rendering, UnrealBloom postprocessing so the atmosphere and markers glow.

The hard part

The atmosphere. Getting it to look like a soft gradient instead of a sharp blue outline took a lot of sweat and tears. The fix was switching from a back-side shell to a front-side halo shader that concentrates the glow at the grazing limb and falls off both inward and outward.

Also the animation from the starting shot to the Moon’s south pole kept jumping at the start, and i had to do some serious debugging to figure out that my (in dev) orbit controls were jumping the Earth while the camera stayed still.

Next

Next I have to actually do the real work, which is implementing the launch window calculator using JPL Horizons ephemeris data, and the Python FastAPI backend for the orbital mechanics. Hopefully I can but its late and I’m tired.

0
0
2
Open comments for this post

17m 37s logged

Day 1: The Moon is rendering!!

Started Artemis Navigator today. The concept is a mission planning tool for the lunar surface missions that uses real data to score landing zones and generate a flight path based on that.

The goal is something that uses real LOLA terrain data, real JPL Horizons ephemeris, real NOAA weather probability to map a flight trajectory from launch to landing.

What I built today

Got the Three.js globe running with the actual NASA LRO color texture from NASA’s Scientific Visualization Studio. Real lunar surface detail at 1k resolution, procedural star field with 3000 points, directional sun lighting, slow rotation.

Tomorrow

Parsing the 13 NASA Artemis III candidate landing zones into the south pole map with real coordinates and terrain scores derived from LOLA slope data.

Data sources

  • NASA JPL Horizons API - Earth/Moon ephemeris
  • LRO LOLA terrain GeoTiffs - slope, elevation
  • LROC WAC illumination maps - solar exposure per site
  • LCROSS/LEND - confirmed ice deposit locations
  • NOAA - Cape Canaveral launch weather probability
0
0
2

Followers

Loading…