The state of the art in open source 3D mapping right now is CesiumJS[0]. From browsing their docs, it looks like it's in a similar place, capabilities-wise. Unfortunately, the limiting factor for most projects isn't the JS library, but it's the availability of high-resolution DEMs (digital elevation models). These won't become widely available until we do something about the price of lidar.
Fortunately, there's a lot of interest in reducing the cost of lidar right now for self driving cars, so maybe the situation will improve soon. I've seen really high resolution scans of small areas (Boulder, Colorado had the entire town scanned a couple years ago), and it truly blows you away. Every detail down the the shape of trees is available.
With all due respect to the folks at AGI and the amazing work they put to CesiumJS, Melown is a very different product tailored at different use cases. We developed Melown bottom-up as a platform for interactive rendering True3D (photogrammetric or lidar based) data, at street-level detail and planetary scale. Cesium on the other hand, is essentially a 2.5D (DEM) rendering library with some interesting add-ons.
Melown now natively supports 2.5D data and Cesium has incorporated support for True3D data through its "3D tiles" standard. This makes the two systems look similar in appearance, though they are by no means similar by design and there differences show once you work with anything more complex than simple demos.
As one of the authors of Melown (and a person with only very limited knowledge of Cesium) I tend to see many advantages in Melown data model, such as support for multiple reference frames (see [0] and [1]), powerful data integration capabilities, state of the art geodata rendering (complete with styles similar to the ones used by Mapbox), and most importantly, performance when dealing with large scale True3D data. Cesium users would probably point out to its support for temporal datasets and wide-array of connectors for various GIS formats.
In the end the choice depends on where your priorities are. I sincerely doubt you could base a website such as the one at [2] on Cesium due to some important data integration issues. Perhaps some people more knowledgeable of Cesium might prove me wrong.
Of course, there is one more important difference between Cesium and Melown. Melown, at this time, is not yet fully open-sourced yet. But that difference is not going to be there much longer. We at Melown will be open-sourcing not only the JS library, but much of the server-side data management software, hopefully providing web and desktop/mobile software developers with whole new array of choice when dealing with the challenges of modern 3D mapping application development.
DEMs: how high-res do you really need the DEMs, how many petabytes will you sacrifice for sub-meter accuracy? Unless the app is for mountaineers, what's out there for free in lower-res (to be interpolated by varying to-be-experimented-with smart algos/heuristics throughout academia) and affordably handle-able on a global scale [1] should be a perfectly sufficient starting point until users actually complain about minor inaccuracies. Whether we're talking 30m or 90m resolution.. it's not "high" but for all sorts of startups but the most exacting surveying/etc pro-level b2b offerings, a fine starting point.
(Of course I'm only talking DEM here, since you mentioned them, whereas Lidar proper kinda covers details such as houses and other structures as 3d points.)
[1] http://viewfinderpanoramas.org/dem3.html seemed to be the best in the "free" (for prototypes / MVPs and such) space when I last played in this space on-and-off from 2011 through 2014~ish.
We use Cesium in a couple applications. We actually generated some imagery and terrain datasets using open-source tools in 2014.
In late 2015, I spent a couple weeks researching GIS data conversion utilities, Cesium's formats, and potential improved source datasets we could use to generate higher-quality imagery and terrain data. I can't haul out the relevant writeup atm, but I concluded that the EarthEnv DEM90 dataset appeared to be highest-quality free terrain source I could find ([0]), and the TrueMarble collection was the best free imagery source ([1]).
I generated our earlier terrain dataset using the Cesium-Terrain-Builder utility ([2]). It generates Cesium's "heightmap" format, but does not yet support the "quantized-mesh" format. I have seen a couple other tools that appear to deal with quantized-mesh tiles, though. On my list to dig into at some point.
As a related note, using the MBTiles format ([3]) for storing and moving tile datasets around is great. Multiple gigabytes in a single SQLite database file (or possibly a few files split by zoom level), rather than trying to move around millions of individual 10KB images on disk. Highly recommended.
I feel like Multi-View reconstructions from a combination of high resolution ground and aerial photography are the only way we can hope to do better than Google Earth. Earth still suffers a lot on reversing lighting. Maybe a sunlight raytracing model could reconstruct neutral diffuse textures from a combination of time information, position information, and surrounding geometry.
Maybe some day we can get angular and spectral reflectance, normals, refraction, and subsurface diffusion maps. Each of these would be essentially the same optimization as the diffuse maps.
> Unfortunately, the limiting factor for most projects isn't the JS library, but it's the availability of high-resolution DEMs (digital elevation models). These won't become widely available until we do something about the price of lidar.
You can cheaply generate approximate DEM from drone imagery. E.g. DroneDreploy.
From this press release https://www.melown.com/blog/official-launch.html - it seems that 3D exploration in-browser is only part of their innovation; the other is the ability to create detailed 3D maps of entire cities simply from simultaneous-localization-and-mapping of aerial imagery feeds.
I'm not sure if Google's been able to do something similar, but I recall at one point that in order for buildings to appear as 3D in Google Maps/Earth, they'd need to be added manually by the community in their 3D editor. There are certainly glitches, and it's hard to know how much manual cleanup was required for these examples, but it's clear that not every building here was manually modeled. Regardless, it's quite an accomplishment to be able to do this type of thing from photographic data alone.
Something is wrong with navigation on my machine. Mouse movements are opposite my expectation (I guess just a preference), and the movements are so sensitive it jumps around a lot and I can't really navigate where I intend to. I'm on an iMac w/magic mouse.
Linux with a touchpad, here, and yes the movements appears to accelerate at a ridiculous rate for me. It's by far the worst navigation I've experienced on a map.
>As for the direction of the movement, think of it as pushing a globe and not moving a camera.
It's not the style of navigation that feels weird. It feels like they're doing the usual arcball but with some weird multiplier attached to rotations so it doesn't feel 1:1 but something like 1:4.
It's really obvious if you zoom out enough to see the entire globe and grab one horizon then drag it 180 degrees to the other. The globe rotates almost twice in that span instead of ~1/2 rotation.
That issue has actually been fixed. Google Haps is completely useable with a magi mouse (before, it was approximately 50x too sensitive, because of the magic mouse's higher resolution).
It's difficult to see how the magic mouse is responsible for the problems here. If I click and drag a point on a map, I expect that point to remain under the cursor. But – as described above – the map moves too fast.
It's not specific to any particular mouse. The clicked on point doesn't stay under the cursor as you drag, even slowly. There is too much easing applied after releasing the button.
I noticed that when using the touchpad on my laptop (Thinkpad E545, Slackware64-current, Firefox 50.something). The trackpoint + physical mouse buttons seems to be less sensitive, but still registers direction really weirdly.
For Jollyturns (https://jollyturns.com) I'd like to overlay my users' ski tracks data, as well as various ski resort objects (lifts, runs etc) on a 3D Earth, to be displayed inside a browser.
Why would I use Melown instead of CesiumJS (https://cesiumjs.org/)? Especially since the latter appears to be free?
This is, sadly, a total clunker on my Macbook Retina Pro 2015. The loading was slow, the rendering seemed to be just a couple of frames per second.
Using the touchpad the actions seemed to be inverted (zooming in the opposite way to what I expected). I couldn't find any way to tilt the view, but didn't spend much time looking because the frame rate was so painfully low.
Google Earth is a native program, you linked to Google maps, their web based map app. While it's pretty good, it's still not as good as a native program, although I'd be very surprised if Google ever updates Earth again.
Fortunately, there's a lot of interest in reducing the cost of lidar right now for self driving cars, so maybe the situation will improve soon. I've seen really high resolution scans of small areas (Boulder, Colorado had the entire town scanned a couple years ago), and it truly blows you away. Every detail down the the shape of trees is available.
[0] https://cesiumjs.org/