[HN Gopher] Show HN: 3D live tracking two climbers attempting a ...
___________________________________________________________________
Show HN: 3D live tracking two climbers attempting a Sierra Nevada
record
Author : closedcontour
Score : 71 points
Date : 2022-07-06 14:48 UTC (8 hours ago)
(HTM) web link (www.sps2022.com)
(TXT) w3m dump (www.sps2022.com)
| skunkworker wrote:
| This would be incredible for multiple types of racing as well,
| bike, offroad etc.
| closedcontour wrote:
| 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/
| tomduncalf wrote:
| You've done a great job - it's super smooth! Congratulations
| tylerchr wrote:
| 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 wrote:
| 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.
| 0x00000000 wrote:
| 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.
| NyxWulf wrote:
| 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).
| AlotOfReading wrote:
| 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.
| closedcontour wrote:
| Yeah, unfortunately this comes with the territory, especially
| with this Garmin inReach data. We are running in "expedition
| mode" which gives us updates about every five minutes but
| still, you will occasionally get badly spurious points. This
| is in contrast to the GPS track data you see in the activity
| viewer. That is collected from their watches which tend to
| not be quite as bad (although they have their issues too).
|
| They are now on a narrow, somewhat technical ridgeline, so a
| few things will accumulate into some annoying errors:
| - the quality of the digital elevation model (DEM) isn't
| great in the Sierra Nevada (new data is slated to be captured
| this year, though!) - the overheard imagery is okay
| (0.6m), but not amazing - they will likely be hopping
| from side to side on the ridge, blocking sky view and making
| GPS quality decrease and frequency of updates decrease
|
| All of this combines into what you see now: jumpiness, not
| registering with the ridgeline, and the summit points (where
| they are manually indicating they are on top) not lining up
| with the labeled points.
| AlotOfReading wrote:
| I hadn't even considered the DEM error. I can totally see
| it now that you've pointed it out though. The data is
| impressive either way.
|
| I've had luck in the past with simply averaging the
| positions from multiple receivers, since horizontal
| multipath error on its own is typically under a couple tens
| of meters and it's so hyperlocalized that multiple
| receivers can experience totally different conditions.
|
| On an unrelated note, do you know if they plan to continue
| with the half palisade traverse after they complete the
| rest of the crest?
| closedcontour wrote:
| Assuming everything goes to plan[1] for Nathan's list
| finish:
|
| Today, Wed, July 6: A five-peak, north-to-south traverse
| of the southern Palisades: Palisade Crest, Norman Clyde,
| Middle Palisade, Disappointment, and Thumb.
|
| Tomorrow, Thurs, July 7: A seven-peak south-to-north
| traverse of the northern Palisades: Temple Crag, Gayley,
| Sill, North Palisade, Thunderbolt, Winchell, and Agassiz.
|
| [1] - https://www.sps2022.com/post/nathan-finish-plans
| AlotOfReading wrote:
| That's one hell of an itinerary.
| nradov wrote:
| The Garmin devices that they're using have built in GNSS
| receivers. There's no practical way to average the
| positions from multiple receivers for real-time tracking
| updates. Once the climb is finished, though, someone
| could download the recorded tracks from multiple devices
| and average them together.
| ge96 wrote:
| 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.
|
| Edit: I see the info below posted by OP thanks.
| closedcontour wrote:
| If you're looking for something worldwide, your best starting
| point is likely SRTM[1].
|
| If you get into more specific areas you can generally find
| higher resolution data.
|
| Good luck.
|
| [1] - https://www2.jpl.nasa.gov/srtm/
| ge96 wrote:
| Thanks for the rec
| ryandrake wrote:
| Also consider ETOPO1 [1]. SRTM is kind of old and is
| treetop instead of groundlevel which may matter for your
| application.
|
| 1: https://www.ngdc.noaa.gov/mgg/global/
| ge96 wrote:
| Yeah I'm specifically looking for slopes/cliffs so a
| generally flat area then a sharp rise.
|
| Hopefully 100 ft is not too small vs. thousands of feet.
|
| I'll check that link out, thanks.
| ComputerCat wrote:
| Wow this is awesome!!
| closedcontour wrote:
| Thank you!
| qrohlf wrote:
| 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?)
| closedcontour wrote:
| Thanks! Happy to answer questions.
|
| 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...
| qrohlf wrote:
| Appreciate the response.
|
| One thing I've struggled with in threejs is what coordinate
| system to use when pulling in data sources. Obviously UTM and
| lat/lon are inappropriate when you're dealing with a slice of
| terrain like this, and from my experience using the 1x1 unit
| tile dimensions of something like a web maps tile coordinate
| system does not play nice with ThreeJS at all.
|
| Do you just project to Mercator/Web Mercator and then
| arbitrarily pick something like 1km = 1000 units to work with
| the data in ThreeJS space, or is there some kind of an
| established coordinate transform that is commonly used when
| bringing geospatial data into a non-projected xyz coordinate
| system?
| morninglight wrote:
| 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:
|
| 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 wrote:
| I wasn't aware of this -- very cool. Thanks.
|
| 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.
| adnanc wrote:
| Awesome, this is amazing and really presents the information in
| such an innovative way.
|
| 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 wrote:
| Thank you.
|
| 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.
| adnanc wrote:
| Excellent, look forward to it.
|
| That means I'll have to do all my cycling in the Sierra
| Nevada region ;-)
___________________________________________________________________
(page generated 2022-07-06 23:01 UTC)