I was actually just sharing this site with some coworkers last week as an impressive example of 3d activity visualization done right!
Map nerd and FKTer here working in a very similar space, I have a ton of questions!
I'd love to hear a little bit about how the camera positioning works. It seems like there is some fairly clever stuff happening under the hood to (1) maximize the amount of trackline in view so that that it is not obscured by terrain and (2) smooth out the camera path so that it doesn't jitter around even when the gps track is irregular.
Is this a completely bespoke rendering implementation? From the look of things, you're definitely not using mapbox-gl-js or leaflet. Are you even using ThreeJS, or is it just all raw webGL under the hood?
Finally, where are you sourcing your DEMs? AWS Terrain?
(small nit: It seems like you may be missing imagery/data attribution on your map, or do you have a license that allows for un-attributed use?)
First, about the attribution: there's a small "Attribution" section in the About page, but it's all data I sourced directly from US gov sites. I actively wanted to avoid an attribution on the actual map page.
It is a bespoke rendering implementation, there are a few details in my original comment[1], but I'll add here that it does use three.js. I haven't used any three.js competitors but I love the level of abstraction it provides: high-level enough to get things done quickly and low-level enough that you can get right into the shaders if you need to.
Camera positioning turned out to be a little easier than I had feared. Up front, I'll say that I didn't do anything for avoiding the track being obscured by terrain. There are times, especially when descending a steep face, where the track does gets obscured.
The camera path itself is generated quite simply: I take a GPS sample every half mile (or as near as possible) and then create a 3D Catmull-Rom curve[2] from those points; that becomes the position track of the camera. Camera orientation is set to look at the current point. There are some offset tweaks here and there so that the camera leads the track (camera turns before the track does).
Amazing! Things have changed since Mike Hoover made "Solo".
Back in the early 70's there were no Drones, iPhone cameras, GPS or internet. Instead, you gathered your pals, a 10 lbs Bolex and as much film as you could afford. Then you hauled everything back to the editing room where you worked for days to cut and splice all that raw footage into a coherent package. If you were very talented, the results looked like this:
We have captured a ton of video of the project and they've done a bunch of amazing lines. Hopefully we can put together a few good videos coming out of this.
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.
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.
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?
I saw this when the Palisade Crest was the farthest point. Now there is a line almost straight down. It's been almost 15 minutes since an update, I hope that wasn't a tragic accident.
Can someone confirm if there is some type of speed descent down from the Palisade Crest?
Update: it rerendered, now it looks like a rendering artifact (I hope).
Probably just a GPS error. It's not uncommon to see large velocities and position shifts, particularly up in the mountains where multipath issues are common.
Wow that's really neat. The pinch zoom spins it vs. zoom.
Would be curious underlying tech for the topography. Will look into it more. I'm looking for a way to find high rises of land across the world although small elevation (like 100ft) thinking some satellite data dump.
Cool site. I’m from NorCal and enjoyed hiking in the Sierra Nevada, but I wasn’t familiar with the SPS reference. And it takes some digging on the Sierra Club site to get any definite reference. SPS is so specific and obscure. Why not a link to Wikipedia?
I put links to the official SPS site on the About page but your point is well taken. The link at the top of the site that says "SPS Peak List" really ought to take you somewhere that you can find out more substantive information than just the raw list of peaks.
While the project is ongoing (probably another month or so), it'll just be for the climbers. But, yes, when they are done I intend to release something that will allow anyone to put their own Strava activities on it. One huge caveat, and one of the main down sides of rolling my own mapping tech, is that I've only processed imagery and elevation data for the Sierra Nevada region.
Like others have said, it all depends on the ridge. In this case it is the southern half of the Full Palisade Traverse[1] which is a very technical ridge with long sections of 5th class climbing[2].
One way of looking at is that these guys have been moving 12 +/- hours a day in the mountains for a few months now and they've covered just over 2 miles of the ridge in 10 hours today so it better be pretty hard!
Hi, longtime long-distance hiker here. It depends on the slope. Sometimes, ridge elevation can be relatively flat for long sections. Such sections would fall into the "hike" category.
Yeah, I was on the fence about using an ephemeral link as the HN submission but in the end figured it was the most appealing to this audience.
Now that Nathan is done with his effort, he'll be loaning his inReach to Ashly Winchester during her FKT attempt on the John Muir Trail starting tomorrow and the submitted link will show that.
After she is done with her effort, I'll redirect to Travis' tracker.
qrohlf|3 years ago
Map nerd and FKTer here working in a very similar space, I have a ton of questions!
I'd love to hear a little bit about how the camera positioning works. It seems like there is some fairly clever stuff happening under the hood to (1) maximize the amount of trackline in view so that that it is not obscured by terrain and (2) smooth out the camera path so that it doesn't jitter around even when the gps track is irregular.
Is this a completely bespoke rendering implementation? From the look of things, you're definitely not using mapbox-gl-js or leaflet. Are you even using ThreeJS, or is it just all raw webGL under the hood?
Finally, where are you sourcing your DEMs? AWS Terrain?
(small nit: It seems like you may be missing imagery/data attribution on your map, or do you have a license that allows for un-attributed use?)
closedcontour|3 years ago
First, about the attribution: there's a small "Attribution" section in the About page, but it's all data I sourced directly from US gov sites. I actively wanted to avoid an attribution on the actual map page.
It is a bespoke rendering implementation, there are a few details in my original comment[1], but I'll add here that it does use three.js. I haven't used any three.js competitors but I love the level of abstraction it provides: high-level enough to get things done quickly and low-level enough that you can get right into the shaders if you need to.
Camera positioning turned out to be a little easier than I had feared. Up front, I'll say that I didn't do anything for avoiding the track being obscured by terrain. There are times, especially when descending a steep face, where the track does gets obscured.
The camera path itself is generated quite simply: I take a GPS sample every half mile (or as near as possible) and then create a 3D Catmull-Rom curve[2] from those points; that becomes the position track of the camera. Camera orientation is set to look at the current point. There are some offset tweaks here and there so that the camera leads the track (camera turns before the track does).
[1] - https://news.ycombinator.com/item?id=32001821 [2] - https://threejs.org/docs/index.html?q=cat#api/en/extras/curv...
morninglight|3 years ago
Back in the early 70's there were no Drones, iPhone cameras, GPS or internet. Instead, you gathered your pals, a 10 lbs Bolex and as much film as you could afford. Then you hauled everything back to the editing room where you worked for days to cut and splice all that raw footage into a coherent package. If you were very talented, the results looked like this:
https://archive.org/details/solo_20170221
Mike Hoover is still around, and I hope he is watching this
https://en.wikipedia.org/wiki/Mike_Hoover
closedcontour|3 years ago
We have captured a ton of video of the project and they've done a bunch of amazing lines. Hopefully we can put together a few good videos coming out of this.
closedcontour|3 years ago
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|3 years ago
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|3 years ago
tylerchr|3 years ago
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?
NyxWulf|3 years ago
Can someone confirm if there is some type of speed descent down from the Palisade Crest?
Update: it rerendered, now it looks like a rendering artifact (I hope).
AlotOfReading|3 years ago
ge96|3 years ago
Edit: I see the info below posted by OP thanks.
closedcontour|3 years ago
If you get into more specific areas you can generally find higher resolution data.
Good luck.
[1] - https://www2.jpl.nasa.gov/srtm/
xtiansimon|3 years ago
closedcontour|3 years ago
skunkworker|3 years ago
adnanc|3 years ago
I know relive.cc tried something similar with just a video playback before being shutdown by Strava.
Would you consider opening this as a platform for others to post their Strava activities?
closedcontour|3 years ago
While the project is ongoing (probably another month or so), it'll just be for the climbers. But, yes, when they are done I intend to release something that will allow anyone to put their own Strava activities on it. One huge caveat, and one of the main down sides of rolling my own mapping tech, is that I've only processed imagery and elevation data for the Sierra Nevada region.
oneoff786|3 years ago
closedcontour|3 years ago
One way of looking at is that these guys have been moving 12 +/- hours a day in the mountains for a few months now and they've covered just over 2 miles of the ridge in 10 hours today so it better be pretty hard!
[1] - https://www.pullharder.org/trip-reports/2012/07/02/full-pali... is a good account of this climb with some nice photos. [2] - https://en.wikipedia.org/wiki/Yosemite_Decimal_System
wyclif|3 years ago
andrewljohnson|3 years ago
xtiansimon|3 years ago
:(
closedcontour|3 years ago
Now that Nathan is done with his effort, he'll be loaning his inReach to Ashly Winchester during her FKT attempt on the John Muir Trail starting tomorrow and the submitted link will show that.
After she is done with her effort, I'll redirect to Travis' tracker.
And after that, I'll leave a note on the page.
ComputerCat|3 years ago
closedcontour|3 years ago