Y
HN Search
Hacker News Search
new
|
comments
|
top
|
jobs
mourner
searching PlanetScale…
1.
▲
2.
▲
3.
▲
4.
▲
5.
▲
6.
▲
19 ms
·
151.
▲
by
mourner
7y ago
Wow, what OS / device is this on? Looks fine on Firefox 68 / OS X for me.
152.
▲
by
mourner
7y ago
Good point! I'm coming to this in the context of interactive maps, where pretty much all data is tiled. So we can use tiles for loading the terrain mesh & adjusting level of detail too while avoiding frequent GPU memory updates. Bu
153.
▲
by
mourner
7y ago
Haven't seen this, thanks for sharing!
154.
▲
by
mourner
7y ago
That's surprising. Does it help to do a hard reload? Are any other WebGL demos working?
155.
▲
by
mourner
7y ago
All the code is there — browse to the bottom and click on the left side of ThreeJS sections to expand them.
156.
▲
by
mourner
7y ago
The easiest method would be downward "skirts" as mentioned above. A little more complicated one I'm thinking about is reconciling error maps on the border when an adjacent tile loads so that they split at the same point, and
157.
▲
by
mourner
7y ago
Oh yes, quadtree-like structures come up all the time when you're dealing with maps. E.g. check out this algorithm I came up with for finding pole of inaccessibility of a polygon: https://github.com/mapbox/polylabe
158.
▲
by
mourner
7y ago
Just open https://studio.mapbox.com and have a go! It's a really powerful tool with a ton of customization options, including ones related to textures & patterns. Also check out one of the recent tutorials for a texture
159.
▲
by
mourner
7y ago
Author here — thanks for checking this out, everyone! Happy to answer any questions in comments.
160.
▲
by
mourner
7y ago
Thank you! Someone just forked the notebook, adding satellite texturing — that's a really cool aspect of Observable (and I'll probably merge it back): https://observablehq.com/@rzoller/martin-real-time-rtin-te
161.
▲
Martini: Real-Time Terrain Mesh Generator
(observablehq.com)
339 points
by
mourner
7y ago
|
65 comments
162.
▲
by
mourner
7y ago
I read the title as "Facebook Outrage Root Cause", got disappointed :)
163.
▲
by
mourner
7y ago
That's awesome! Works great on my Pi digits calculation demo :) https://observablehq.com/@mourner/calculating-pi-digits
164.
▲
by
mourner
7y ago
Hey Justin, we miss you very much! Happy to see you chime in here. > it takes a real commitment from the leadership to fully integrate remote team members This is so true. I thought this would only be manageable for relatively small comp
165.
▲
by
mourner
7y ago
Welcome to Ukraine! Lard and Salo [1] are pretty much the main national dishes here. A healthy delicacy that's welcome on any table and is sold on every meat market. [1] https://en.wikipedia.org/wiki/Salo_(food)
166.
▲
Sun Position in 900 Bytes
(observablehq.com)
1 points
by
mourner
7y ago
|
1 comments
167.
▲
by
mourner
8y ago
That's not true, at least not in areas where Telegram is prevalent (Eastern Europe). Here, it's quickly becoming the default 1-1 messenger.
168.
▲
by
mourner
8y ago
It's a fantastic service from an engineering perspective. Fast, lightweight, reliable, simple, with low battery drain and data usage, and open source clients. A real joy to use.
169.
▲
by
mourner
8y ago
I love the Bullet Journal system [1], writing yearly/monthly/daily goals in an old-fashioned paper notebook. Somehow it makes it much easier to reason about compared to keeping digital to-do lists. [1] https://bulletjou
170.
▲
by
mourner
8y ago
No, just slides — I don't have a video of the talk. Perhaps there will be one someday if I'm invited to some international JS conference :)
171.
▲
by
mourner
8y ago
Note that the hilbert function wasn't written by me, just merely ported from C++ — here's a post about it by the original author: http://threadlocalmutex.com/?p=126
172.
▲
by
mourner
8y ago
No, it's single-threaded (it's pure JavaScript after all), but you can index data on a worker thread and then transfer the index instantly to the main thread for search queries. I don't think the algorithm needs parallelizati
173.
▲
by
mourner
8y ago
Good point, thank you! I'll interlink those.
174.
▲
by
mourner
8y ago
The most critical thing is avoiding unnecessary work — that usually means estimating algorithmic complexity and trying to reduce it where possible (e.g. by sorting + binary search, caching, using basic data structures like a priority queue,
175.
▲
by
mourner
8y ago
Awesome — let me know how it goes!
176.
▲
by
mourner
8y ago
I think kdbush should always be faster for points — it uses more than 2x less memory, because when you encode points as bounding boxes, you basically duplicate them. Indexing and search is faster mostly because you operate on less data.
177.
▲
by
mourner
8y ago
You're right! In my experience, today JavaScript is so fast on careful code like this that even ports to C++ or Rust aren't much faster, and any gains would likely be offset by JS <-> WebAssembly communication overhead (alth
178.
▲
by
mourner
8y ago
Basically, yes. I wrote a long article about this [1] which goes into depth on how algorithms like this work — hope it helps! [1] https://blog.mapbox.com/a-dive-into-spatial-search-algorithm...
179.
▲
by
mourner
8y ago
Hey, author of the library here — feel free to ask me any questions! Very happy to see this trending on HN.
180.
▲
Visualizing street orientations on an interactive map
(blog.mapbox.com)
3 points
by
mourner
8y ago
|
0 comments
More ›