OrbitLens Devlog #7: Implementing a 2D orbit map

To expand the functinality of the website, i wanted to add a 2D world map that has the 3d orbit projected on to it. Here is a breakdown of what i built, how i built it and the challenge i faced.

What I Built:

I made a 2D projection of the 3d globe using the HTML5 Canvas API that runs at the same time with the WebGL 3D engine.

The map automatically appears when a satellite is selected, and fetches live telemetry to draw exactly one full orbital period (half past, half future). The orbit line looks like how it does on the 3d globe with a yellow line representing the past trail and a dotted blue line representing the predicted future track. I also built an “EXPAND” toggle that expands the map to fill most of the screen if the user wants to take a close look.

Challenges:

• If a satellite flies east across the Pacific Ocean (where the International Date Line is), its longitude coordinates suddenly jump from +179deg to -179deg. I originally didnt take this into account and it had like this massive, horizontal glitch streak entirely across the screen cus of the sudden coordinate shift.

To fix this, I programmed a strict mathematical distance gate into the drawing loop. If the engine detects that the X-coordinate has jumped by more than half the width of the canvas, it forces the renderer to break the current stroke (mapCtx.stroke()), lift the ‘pen’, and begin a completely new path on the opposite edge of the map (mapCtx.beginPath()).

• When plotting a full 90-minute orbit, the beginning of the yellow line and the end of the cyan line do not connect perfectly, leaving a massive gap. I originally thought this was a problem and tried for quite a while to fix this and i double checked the math formulas again and again. But i realised this isnt a math error, it’s just physics. While the satellite flies in a continuous circle, the Earth is physically rotating underneath it. By the time the satellite completes one lap, the ground has shifted roughly 22.5 degrees to the east, pushing the satellite’s relative ground track to the west. So i just left it like that to accurately represent the Earth’s rotation.

• This was the biggest problem and took the most time to fix. Three.js orbital camera controls are incredibly aggressive about capturing mouse events. The 3D engine was always suppressing the HTML ‘click’ events, making the “EXPAND” button not work. Not only that, the standard inline CSS was pushing the 3D canvas down the page, which misaligned everything and didnt allow me to select the satellites at all.

To fix this, fisrt, i locked the 3D canvas to a fixed background layer (z-index: -1) to completely isolate it from the UI layout. Second, i bypassed the WebGL event interceptors entirely and connected the code that handles the expansion directly to a global window function (window.toggleMap) and just injected the button with the HTML onclick attribute. This fixed everything and now it works really great.

OrbitLens Devlog #6: Implemented Sun and the day night cycles + camera panning improvements

The core engine was working smoothly, so this session was focused on the ui and aesthetics and realism. Here are the changes i made, how i made them, and the challenges i faced:

Change 1: Implemented the Sun

The first major goal was replacing the static and boring lighting the 3D earth originally had with a Sun.

To do this, I wrote a custom Solar Ephemeris algorithm. Using the current Julian date, it calculates the sun’s exact Right Ascension, Declination, and Earth’s Greenwich Mean Sidereal Time (GMST) to pinpoint the real-time subsolar vector. Since this was some complicated math, i had to use some ai for this.

But in a WebGL engine, lights are purely mathematical vectors and there is no physical object in the sky. So when i first added a solid white sphere, it literally looked like a flat plastic toy and looked really ugly. To fix this, I abandoned the 3D ball and built a 2D Sprite using the HTML5 Canvas API to generate a radial gradient. By using Additive Blending to the material, I forced it to mathematically layer the light over the space, which created like this blinding, light that looked like the sun, which was good.

Change 2: The Day/Night City lights cycle:

To make the globe even more realistic, I wanted the night side of the Earth to have like the night time city lights rather than just a dark shadow.

To build this, I added an 8k night-map texture (from Solar System Scope) and implemented a WebGL fragment shader into the Three.js’s native MeshPhongMaterial using a compiler hook. But there was a problem, the free night map that i implemented had this blue tint to it, and when i tried to correct it, it literally turned to this muddy, polluted yellow.

To fix this, I programmed the shader to intercept the texture data, remove the color tint by calculating luminance, and pass it through a smoothstep noise gate. Anything below a 10% threshold was forced to pitch black, while populated areas were recolored with a warm golden orange hue. And it worked great!

Change 3: More camera improvements

Despite the previous session having to do with correcting the camera engine, there were still some stuff that i fixed here. The problem was since i removed OrbitControls in the last session (read previous devlog), once i had like hte earth upside, it was very hard to make it upright again. like at one point, i had the entire europe upside down and Africa was at the top of the globe but i couldnt get it back to normal.

To fix this I changed the code so that the panning controls thing swaps between OrbitControls (for the 3D globe) and TrackballControls (for the satellites/spacecrafts). But there were some more challenges:

• When a zoom-in animation (read previous devlogs) finished (after selecting e.g. a satellite), the camera would like glitch backward into a less zoomed in position which was kinds uncomfortable to look at.

• Because the satellites were moving a static transition speed couldn’t catch them before the animation finished, so the final frame was a bit glitchy and the screen like jumped a bit.

To fix all of these problems, I first made sure that disabled camera controls are completely turned off so they can’t fight the active zoom animations. I also made it that instead of moving at a steady speed, I added a speed-up effect as the camera gets closer to the target. This ensures that the camera glides smoothly into place right on time without any jerky jumps.

OrbitLens Devlog #5: Camera panning improvements and performance updates

After the changes from Devlog #4, all the math and the 3d models were all working but i faced some problems in other aspects of the website. Here are soe of the changes i made:

Change 1: Correct orientation

This was a small change, but i noticed that some satellites were a bit too big (like Aqua) and were positioned wrongly, so i just chaged teh scale and the rotation to make it a bit more realistic

Changes 2, 3, and 4: The camera improvements

I faced a lots of problems with the camera and how it worked. Before, i couldn’t rotated in all directions around the earth or the satellites because they were using OrbitControls so i swapped that out with TrackballControls, which allows for 360deg panninh

There was also like a rubber band effect where the camera, when the camera lock was selected as satellite, zoomed in towards a satellite, i couldn’t interact with the satellite at all. THis was because as the satellite’s moving, the camera is also actuvely trying to catch up so it never actually ‘ended’ its animation so i was blocked from interacting with the satellite. To fix this i implemented delta tracking. The engine now calculates the exact mathematical vector the satellite moves every frame and shifts the camera’s physical position by that exact same amount, which worked.

Previously, switching targets caused the camera to travel in a straight line, clipping through the Earth, which looked kinda unprofessional so I engineered a custom transition that separates the camera’s direction from its altitude. Now, when you select a new satellite, the camera zooms out, tracels in a an arc over the globe, and zooms in to the destination satellite.

The animation still needs a lot of improvement cus some parts are still a bit glitchy, but i’m happy for now.

Change 5:

I implemented it that the TLEs are now stored in the actual localStorage for like 6 hours and then fetch new TLEs. So the user will always have the latest TLEs cus they update evey 12hrs.

OrbitLens Devlog #4: Adding multiple satellites

In my last update, I finally got a 3D model of the ISS rendering on the globe with a basic UI dashboard. It looked cool, but I wanted to scale it up. I wanted to add multiple famous satellites on top of the ISS:

• The Hubble Space Telescope (HST)
• NASA’s Aqua
• NASA’s Terra
• Tiangong
• ISS (which already exists)
  At least for now. Maybe in later stages, I can add Starlink satellites or sth. Here is waht I built, how I built it, and the challenges I faced.

Change/Challenge 1: the orbit that looked like a slinky

I hardcoded a 90-minute orbit line (the ISS orbit time). But other satellites have different orbital periods, so 90 mins fell short. Increasing it to a 12-hour calculation made the ISS orbit look like a massive slinky wrapping around the Earth cus its orbit is only 90mins. I fixed this by dynamically calculating the exact total orbit time using the satellite’s math:

const periodMinutes = Math.ceil((2 * Math.PI) / satrec.no); const halfPeriod = Math.floor(periodMinutes / 2);

Change/Challenge 2: IP ban (again)

The JS fetch() doesn’t consider a ‘429 too many requests’ (i got this cus vite reloaded the page every time i saved something) response as a network error, so it tried calculating the HTML error page as orbital math and crashed. I fixed this by manually checking the response.ok HTTP status. If the API blocks me, the code redirects to an “Offline Fallback Mode”—loading a hardcoded string of ISS TLE math so the app survives.

Change/Challenge 3: improper API request

After like 4 hours, I realized I still wasn’t getting a proper API response even though the IP ban would have worn off. I looked at the code and realized I was pulling data for all five satellites in one go by just comma-separating the values in the URL like this:

.../gp.php?CATNR=25544,20580,48274&FORMAT=tle
(each number references to a satellite)

But after CelesTrak’s documentation, it strictly dictated that the CATNR parameter only accepts a single catalog number. The server rejected the request, my code assumed 0 satellites, and the engine crashed.

The fix:

Writing five separate fetch() blocks is messy, and implementing an await fetch() in a for-loop creates a slow “waterfall” effect (waiting for one to finish before starting the next).

I fixed this with JavaScript’s Promise.all. I created an array of the exact NORAD IDs, mapped over it to generate separate, perfectly formatted fetch requests, and Promise.all fires them all at the exact same time.

Change/Challenge 4:

I wanted 3D models for all of these. I found Aqua and HST easily from NASA. I found Terra, but it was fetching some other incompatible file I didn’t have, so I just scratched the Terra model. Tiangong was the biggest pain—everywhere I looked was either paid or on Sketchfab, and I cant create a Sketchfab account cus of some stupid Epic Games restriction.

Implementing the files I did have was the next issue. Hardcoding multiple GLTFLoader blocks would turn the code into spaghetti. Plus, 3D models from the internet aren’t scaled equally—my Hubble was massive, and my Aqua model was tiny.

The fix:

I built a central Model Registry object. It maps a satellite’s NORAD ID to its file path and a specific scale multiplier. Even better, I implemented a fallback for satellites I done have a model for. If I track a satellite (like Tiangong) but leave the file path as null, the code detects this and dynamically generates a glowing cyan sphere using Three.js math to take its place.

Changes 5 and 6:

I updated the dashboard to include a dropdown to select the satellite and the telemetry updates accordingly. I also added a camera toggle feature where the user can lock the camera to follow the satellite or stay locked on the Earth. Lastly, I implemented a custom loading screen while the models load.
P.S.Lots of info is compressed cus i crossed the 4000 char limit

OrbitLens Devlog #3: Adding a dashboard + ISS 3d model implementation

I had two goals in my mind in this session. One was to add a dashboard which displays some stats of the ISS and the other is to replace the red dot with a 3d model of the ISS. Here is what and how I implemented these stuff and the challenges i faced:

Change/Problem 1:

Before I even got started on the new stuff i wanted to add, i faced a big problem. While testing the physics code and other stuff, my build tool (Vite) was auto-refreshing the browser every time I hit save. This I spammed CelesTrak’s public API with dozens of requests per minute. This lead to me kinda getting IP blocked temporarily, at least that’s what i think happend because it always returned an HTML error page instead of a TLE string. My engine tried to calculate stuff with that empty TLE and just crashed the engine

The fix:

It is important to know that a TLE is not like a live GPS broadcast that gets transmitted every second. It’s literally like a mathematical snapshot of a ton of stuff of the ISS like its position and its orbit and NORAD only updates these TLEs like twice a day or sth. So I fixed this api problem by making it such that the localStorage caches the TLE once and uses it for the calculation for the next 12 hours and then updates the TLE after that.

Change 2: Dashboard implementation

I implemented a dashboard that shows up on the top left of the screen and shows the following stuff abotu the ISS:

• Longitude: the method i used to calculate this is in one of my previous devlogs (i think my last one). But here is a quick summary:

To find coordinates I first calculated the Greenwich Mean Sidereal Time (gmst), which gives me the exact rotational angle of the Earth at that specific millisecond. I passed the ECI position (one of the previosu devlogs) and gmst into satellite.eciToGeodetic(), which projects the point onto the spinning globe in radians. I then multiplied those values by 180/pi to convert the radians into standard degrees

• latitude: same as longitude

-altitude: The eciToGeodetic() function also calculates the distance from the satellite’s coordinates down to the mathematical surface of the Earth (the WGS84 or the ‘World Geodetic System 1984’ ellipsoid which is like a mathematical reference representation of the earth that is used in calculatoin and stuff). It outputs this directly as height in kilometers, which I then simply rounded to two dp.

-velocity: The propagate() function outputs the satellite’s speed broken into X, Y, and Z axes (measured in km/s). To get a single speed, I calculated the magnitude of that 3D vector using the 3D Pythagorean theorem:
v = squareroot(x^2 + y^2 + z^2)

Change 3:

To implement a 3d model, i first needed that 3d image. I wanted the highest quality NASA model available (Model D - IGOAL). I downloaded the official .fbx, converted it to a .glb, and ended up with a 255mb file. Which is really bad because shoving a 255mb file into a web browser would just crash the entire thing. So i just ran that through a draco compression and a texture compression (WebP 1024x1024) which brought the size to about 18mb which was much better.

To render this, I used Three.js’s GLTFLoader with a dedicated Google WebAssembly DRACOLoader to decode the compressed math.

The next couple of changes were just to make it more realistic:

• i changed the scale from 0.02 (where it was the size of a continent) to 0.001 (which made it a good size)

• the direction the ISS faced was not accurate at all so I wanted to rotate until its in the correct position. But because the animate() loop was actively using math to point the model forward 60 times a second, it kept overriding my manual rotation. So I wrapped the ISS in a THREE.Group, rotated the mesh 90 degrees inside that container, and then applied the math.

OrbitLens Devlog #2: Adding ISS + Orbit

This session was mainly focused on implementing the ISS first to the satellite tracker. Here are the changes I made:

Satellite Data Extraction and ISS Positioning

To understand what I did in this session, it is important to know how I can get the ‘live’ location of the ISS works:

• firstly, satellites don’t broadcast live GPS coordinates to the internet. Instead, radars track them and publish Two-Line Element (TLE) sets. A TLE is like a raw string that “acts as a mathematical variable of an orbit’s shape at a specific moment.” I got these TLE from a non-profit API called CelesTrak.

• these TLEs are kinda useless so I used the satellite.js library to parse te TLEs. This js engine also allows you to run what is known as SGP4 models (Simplified General Perturbations 4) which is a mathematical model used to predict an orbit. Using this, TLEs are then converted to what’s known as Earth-Centered Inertial (ECI) vectors which is a

“non-rotating 3D coordinate system anchored to the center of the Earth with its axes fixed relative to the stars, allowing you to calculate a satellite’s absolute mathematical position in space independent of the Earth spinning beneath it.”

The ECI is still not useful so I passed it through satellite.eciToGeodetic which converted the eci to geodetic coordinates (longitude, latitude and altitude)

But there’s one more step before the data is useful. The thing is Three.js only understands Cartesian coordinates (x, y, z) so the geodetic coordinates need to be converted to catesian. I did that using these mathematical formulas:

x = r * cos(lat) * cos(lon) y = r * sin(lat) z = -r * cos(lat) * sin(lon)

Orbit Implementation

Satellites do not orbit in perfect circles; they follow complex trajectories that shift as the Earth rotates underneath them. The ISS takes roughly 92 minutes to complete one full orbit around the Earth. I captured this entire window by running two separate for loops. For these loops, i created 92 differed Date objects spaced exactly 1 second apart. here are the loops and how they work in a small nutshell:

• The Past: I looped backward from -46 minutes up to 0 (the current moment) and inputted the X, Y, and Z coordinates in each loop into THREE.BufferGeometry to draw a solid yellow LineBasicMaterial.

• The Future: I looped forward from 0 to +46 minutes. In every single iteration of those loops, and did the same thing.

Challenges:

• the hemisphere and orbit were originally flipped or were completely false so i had to wrack my brain and dind the cause. I spent more than an hour debugging this. Turns out the formula was wrong and i used sin instaed of cos.

In te end, I also double checked my orbit and position with official ISS trackers, and they matched!

OrbitLens Devlog #1: Rendering the Earth 3D

I just kick started this project, Orbit Lens, and my aim is to build a fully free, real-time 3D satellite tracker from scratch using Three.js and maybe some other libraries. Today was all about creating the core 3D arch. You can’t track a satellite without a planet to orbit, so Phase 1 was focused on rendering the Earth and setting up the Three.js environment.

What I accomplished in Phase 1:

• Set up my environment with Vite
• Built the Three.js scene, camera, and render loop.
• Rendered a 3D Earth utilizing maps from solar system scope.
• Enabled OrbitControls to enable camera panning

This is just the basic foundations of the project so there’ll be much more development in the future.