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.
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.
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.
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.
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).
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.
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.
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).
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.
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.
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.
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).
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.
The visualisation itself was cool, if a bit slow in Firefox on my laptop.