OrbitLens Devlog #9: implemented satellite filtering + earth connecting line and complete UI overhaul

Now that the website has a proper engine and everything was working
well, i decided to add some more stuff. I had two goals for this
session. One was to add a satellite filtering option where the user can
filter categories of satellites. The other is to change the ui because
there were many imprefectoins. Here is a breakdown of what i changed and
the challenges i faced:
Change 1:

I added a global filtering system to fiter satellites by categories.
To do this i first built a string-matching engine directly into the TLE
parsing loop. As the engine downloads the TLE data from the API, it
scans the satellite names and tags them each with categories. I didn’t
really know what to categorise them so i thought of some categories and i
asked ai to think of some categories. These are the categories:
StarlinkOnewebCommsNavigationWeatherand Other/Miscallaneous (which i impemented later; read below)
I then wired the HTML dropdown directly into the WebGL gpu loop.
Instead of deleting unselected satellites (which would take up too much
gpu memory), the gpu simply multiplies their matrix scale to 0, 0, 0,
which would just hide them.
But there was a challenge that i faced, though it wasn’t a big one.
When i first implemented the filter, I noticed that the total satellite
count dropped to around 12,000. It turned out that all the satellites
that didnt fit into any cateogry were not shown at all so i expanded the
categories to include an OTHER category.
I also had to make some changes in the raycaster or the users would accidentally be clicking on the hidden satellites.
Change 2:

I also added a line connecting the selected satellite directly to its
exact spot on the Earth’s surface directly beneath it. I did this by
first pre-allocating a THREE.BufferGeometry with exactly two vertices.
Inside the animation loop, i then took the satellite’s live 3D
coordinates and use a .normalize() math function. Because the Earth has a
radius of exactly 1, normalizing the 3d coordinates perfectly attaches
the bottom of the line to the planet’s surface.
But, i ran into a bug where the line would randomly disappear
depending on the camera angle. After some research (ai) i found out that
this was caused by Three.js’s “Frustum Culling.” The code calculated
the line bounding box once when the websited started up and when the
camera moved away from that initial box, the gpu assumed the line was
out of sight and stopped rendering it to save memory. So i just added a
line of code (frustumCulled = false) that just overrode that.
Change 3:

Lastly, i essentially completely rewrote the styles.css to change how
the ui looked cus i didn’t relaly like how it looked before. So this
was the third change.