[closedcontour]

Hi HN, I built a website for tracking an attempt by two climbers to set the fastest known time (FKT) on a well-known list of 247 peaks in the Sierra Nevada.

While I hope you'll find the whole site interesting[1], the part most likely of interest to this community is the interactive 3D live tracking (the main link) and activity playback[2]. Here's a post describing its capabilities/controls[3].

I rolled my own 3D terrain renderer based on open aerial data (USDA NAIP), elevation data (USGS NED), and named locations (USGS BGN). A few points of difference from what you might see from Google, Mapbox, or Cesium:

- Fixed scene size. The scene is only big enough to capture the area of interest (the track) plus some contextual buffer.

- No incremental loading. This was the motivation behind the fixed scene size… once the imagery and elevation model are loaded, the scene runs at 60fps on just about any device. I want it to feel _fast_ and terrain, imagery, or feature data loading and unloading breaks that feeling.

- Compressed textures for imagery. In order to successfully load some of the larger scenes and to reduce imagery file sizes, I use basis_universal[4] texture compression. It's perfect for this sort of imagery: the reduced quality isn't too discernable and you get 8:1 reduction in on-GPU memory usage against standard RGBA images.

- Hand coded DEM compression. I hand rolled a DEM compression algorithm based on the ideas behind QOI[5]. It turned out to hardly be necessary because the poor quality of DEMs available in the Sierra Nevada make their size immaterial compared to imagery. That said, it was a successful effort insofar as it achieved better than bzip2 compression with O(n) encode/decode times.

- 3D-scene rectified photos. For the first third of the project I was manually hand rectifying photos into the 3D activity view[2], but, in the end, this was taking too much time day-to-day.

This has been my passion project for the last six months or so and, as someone who has climbed 89 of these peaks over 20+ years, it has been a real joy chronicling these guys' amazing efforts.

I hope you enjoy it. Any and all feedback welcome… thanks.

[1] - https://www.sps2022.com [2] - https://www.sps2022.com/activity/7016024405, let it load then hit the play button! [3] - https://www.sps2022.com/post/3d [4] - https://github.com/BinomialLLC/basis_universal [5] - https://qoiformat.org/

[0x00000000]

This is very impressive. This may actually be the only 3d web application of this type I can recall that has ever worked completely correctly on my phone.

They always have one or more of these problems: zooms the page when trying to zoom, can’t rotate, can’t move, moves extremely slowly or quickly, jumps around when trying to zoom, randomly freezes or goes black, takes up either a quarter of the page or has 3/4ths cropped out, has the wrong aspect ratio, unusably slow, or something else.

[tomduncalf]

You’ve done a great job - it’s super smooth! Congratulations

[tylerchr]

The terrain renderer is really impressive. Have you written anything that goes into detail on how you created it? I would find that fascinating.

Also, do you mean that you are _automatically_ rectifying photos against your 3D terrain model to determine the direction and angle they were taken from? Or do they come with additional information that is useful in simplifying that task?

[closedcontour]

Thank you. Unfortunately I have not yet written anything detailed about the renderer. As is typical with this sort of project, I had grand ambitions about many features and articles to write but have really only been able to focus on the daily updates.

Oh, how I wish it was automatic! I have a script that pulls EXIF data out of the photos and initially places them in the scene but then I manually rectify it. In fact, all the keyboard shortcuts are still there if you want to see the process. Select a photo then play with these keys:

B (toggle white background), 1-5 (image opacity), QEWSAD (camera orientation), HNIKJL (camera position), [] (camera FOV), and / (console.log the variables). Shift does smaller increments.

In theory, the iPhone has enough metadata to make a decent first guess (GPS, phone orientation, and compass direction). In practice, that wouldn't be enough to do it automatically, you'd have to do some sort of additional fitting. Video and photo georegistration is an important problem in many domains with active research -- perhaps some day this will trickle down into a library I could use.