Hacker News new | comments | show | ask | jobs | submit login
Show HN: Interactive WebGL visualization of all 47K buildings in Manhattan (tbaldw.in)
151 points by taylorbaldwin 89 days ago | hide | past | web | favorite | 42 comments

Both scrolling and panning (dragging) feels inverted to me! Specifically, it behaves the opposite way to for example Google Maps. (Scrolling away from the computer, towards me, takes me closer to the map. Dragging doesn't keep that map pixel under the cursor, but drags the "camera" around.)

The visualisation itself was cool, if a bit slow in Firefox on my laptop.

The camera works exactly like it would in a 3D editing software. Felt 100% intuitive to me.

Think of it as grabbing a model physically moving it vs. you controlling camera across a 3D scene.

Edit: Or perhaps, you being the city in third person vs. you being the camera in first person.

No, it doesn't. If you "grab" a point closer to yourself than the axis of rotation, then yes, it kind of acts like it should, but if you grab something far away then the rotation direction doesn't flip as it would in other software. This breaks the illusion that you're grabbing the model. It would probably be fine if they went with the opposite model ("grabbing the viewport"), as long as they kept it consistent, but they don't and it makes it feel out of place.

Where you click doesn't matter.

You need to double click somewhere to recenter.

How are the controls any different than say, the 3D viewer on this website: https://www.tinkercad.com/things/9D6rDxE5U3Z-delorean-dmc-ti... ?

I was unable to control it properly and gave up.

I second this. I'd also add that the inputs are way too sensitive. Moving my mouse only a couple of pixels completely inverts the visualization! It's basically impossible to exert any fine-grained control.

Scroll zoom direction preference is basically a toss up, but the panning seems natural to me.

Seemed perfectly intuitive to me. The sensitivity could be a bit lower tho.

Seems unhappy about something in Chrome 67 (OS X).


Hmm, this actually runs surprisingly slow (I have a top of the line 15" MBP with discrete graphics and it's not hitting 30fps). What's the deal with that? Is WebGL just so inherently slower than "proper" OpenGL powering games? Lack of optimization? What are the bottlenecks?

WebGL is great for most use cases, and generally pretty comparable to OpenGL in terms of performance.

This vis is rendering ~11 million vertices which is quite a bit for any GPU to render. There are some optimizations that could be made — chunking, frustum culling, LOD, depth testing, etc — but probably not trivially. It would change the look & feel of the demo (things "popping" in and out or lack of overlapping buildings, etc) and probably take a significant effort to code.

You can see Taylor's code here, though: https://twitter.com/taylorbaldwin

You can compare this with Google Maps, since IIRC Google Maps also uses WebGL, and renders all of Manhattan with far more detail and without a snag.

For static geometry like this, the entire scene should be uploaded to the GPU in a few calls when you open the page, and then never again. Only the transformation matrix, a 4x4 matrix which transforms vectors from world space to display space, needs updating. There's no reason this shouldn't run at 60fps on any machine that supports WebGL (excluding CPU-only implementations).

The geometry in this demo already is static.

The app is vertex bound since the geometry has 11 million vertices, which is not trivial for any GPU to render.

I set a breakpoint at drawArrays to verify this, and it's indeed rendering 10,965,264 vertices. It's using neither indexing nor triangle strips, so it uses no post transform cache, and the vertex count is needlessly inflated by at least 3x. But that's still a lot higher than I thought it'd be.

How does that number compare to for example Cities: Skylines which renders cityscapes smoothly on the same hardware?

I don't know Cities: Skylines but I imagine each city rendering engine has its own set of challenges and performance considerations.

Generally my point is: graphics programming isn't always trivial, and it takes time/practice to debug and optimize a WebGL scene with millions of vertices. Comparing this WebGL side project to a full-blown city-scape game engine is apples and oranges.

I'm guessing the largest cause of the performance not being great is the large amount of data, and the approach to render it is not optimal. If the same rendering algorithm was implemented using OpenGL instead, I suspect the performance would not be significantly different from this WebGL version.

If you want a random example of a well-optimized demo that uses WebGL for rendering, try the demo at https://www.funkykarts.rocks/demo.html and see how well that performs.

does anybody remember messing around with VRML browser plugins in Netscape in about 1997?


I really appreciate the confirmation modal in the beginning. This is _very_ cool

Indeed. Also no three.js [1]. Only some d3 [2] bits.

[1] https://threejs.org/ [2] https://github.com/d3/d3-scale

regl (http://regl.party/) instead of three.js. For such relatively static scenes (the 3D model doesn't change, only the vertex colors), regl is simpler IMO. You have more control over when stuff (buffers, shaders) are allocated. And no scene graph means you don't have to traverse it during each render (to update the world matrix etc).

Didn't work in Firefox for me, maybe I have something disabled.

Reminds me of Escape from New York a bit :-)

I suspect this is the reason:

> Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at https://tbaldwin.nyc3.digitaloceanspaces.com/bin-to-bbl.csv. (Reason: CORS header ‘Access-Control-Allow-Origin’ missing).

Crashed my browser (but on mobile, so maybe expected for intensive webgl).

Chrome Mobile Version: 65.0.3325.109

Second launch didn't crash but gave the error: webgl hit a snag with the option to reload or ignore.

Reload: always gives the same error.

Ignore: if no "loading" visible then no further response. If "loading" visible then loading bar continues to load until ~95% complete then no futher response.

Crashed mine on desktop too, on 66.0.3359.117.

Locks up for a few seconds, slowly reaches ~75% loading progress, then "Aw, Snap!"

That was really cool.

I zoomed in until I was essentially at ground level and looked around. I have to say that to me, it was depressing. I can't imagine living in a place where 90%(?) of the sky is obscured. It's great so many people like living in the city, but I personally could never do it.

Very cool, small quality of life suggestion is allow movement with WASD or the arrow keys.

Doesn't seem to work in Chromium 62 or Chrome 63. Occasionally the browser says "Rats! WebGL hit a snag. [Ignore] [Reload]", and neither action helps. Occasionally WebGL doesn't hit a snag, but the visualization only loads partly, with some buildings, sometimes with color but sometimes not, and just overall appears broken.

Why are you running chrome/chromium 62-63? 66 is the current version, isn't there a ton of vulnerabilities in older versions?

Slightly off-topic: As the majority of Central Park front property seems to be Co-Op owned, can anyone explain to me how this can be?

(In Europe Co-Op housing AFAIK isn't for the poor, but not that luxurious either)

i might be grossly wrong, but canadian/british-derived legal system perspective: these properties probably pre-date modern legal systems for what we know as a strata-title property in british columbia, queensland or new south wales?

to the best of my knowledge the NYC cooperatives are corporations where the individual residents own shares, so it's functionally equivalent to a strata title condominium. the main difference being that people cannot just buy a unit in the coop, they need to be approved by a board vote. apparently even celebrities and senior business figures occasionally get turned down for coop memberships in nyc because other members of the board consider them undesirable for some reason. whereas in a fee-simple strata title system any person or corporation with sufficient money can buy a condominium (unless it's an age 55+ building).

The camera should move when zooming in, for example if I'm pointing at the Empire State and I zoom in, the zoom should center on the building.

Very cool data visualization. Are there any particular reasons you chose not to a library like THREE? Bundle size perhaps?

I left it running in a background tab and forgot about it, and suddenly my computer got REALLY slow haha.

Yes that's still the case with most WebGL demos I click. I clicked this one, and played around for 10 seconds. Then I heard the fans of my Macbook Pro spinning up.

Although I agree that this seems badly optimised, I too have a Macbook Pro, and the fans spinning up is quite normal when using 3D applications. Ie. Although webGL, I think most of the work load is the "GL" part not the "web" part.

Is it just me? The colormap doesn't seem correct for the height.

Other than that it's nice.

"tends to work best with Chrome" - back to 2000s with new tech.

It's all white and light grey, very hard to see anything :/

Am I misinterpreting something or are the height colors meaningless?

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact