It's a desktop tool to generate video flybys from google earth. Not a website they expect people off the street to visit. How would you deliver such a thing in 2019?
In the past this would have been a standalone app like google earth itself was. With a big download and an icon on your desktop.
Or, they could simply bundle Chrome into the app as electron to give people the exact same thing but avoid snarky hacker news comments.
Or, better still, they could do what they did and ship it as is.
The correct response to this used to be "wow, that's pretty cool that they can make this work in a browser".
How about they make it work in multiple browsers instead of just their own? It’s cool that it works in a browser, but only if it works in browsers in general, not just one. And it’s not like this is charity work.
It looks like they are waiting on WebAssembly Threading. I agree with you though, Google should help develop WebAssembly vs just creating a Chrome only solution:
"Our 3D rendering engine currently uses a Chrome-only technology called Native Client to power Earth Studio. However, we’re closely tracking the evolution of WebAssembly (especially threading). Stay tuned!"
There is a clear difference between not giving a shit about browser divercity and standards and building a specific product on top of Chrome which is, also a web browser.
Lots of companies don't give a f*ck and only do it if the market share are big enough.
On the project on which I'm working, no f_cks are given about browser diversity, we're just supporting IE, because we need activX to communicate with a smartcard reader and there's plan to start next year on support both FF and chrome
That first scene in the bg video made me feel very un-easy.
Edit: This also reminds me that I'm still upset there is no easy way to have the satellite view on google maps without the 3d info. I've read articles describing how to use the old sat maps but nothing seams to work.
Getting the plain imagery in Google Maps without the falsified 3D models is pretty straightforward. After switching to satellite view, just open the sidebar that lets you select between regular map, satellite, and terrain views, and below it you'll find globe, traffic, transit, bicycling. Click the globe option to disable it, and it'll revert to the plain 2D view.
Thanks; I've found it. But really this ux is bad... its a 2nd level sidebar... The hamburger menu is only available after the places or location info menu is open. What ever happen to the map layer options you get with google maps on a 3rd party.
What platform are you using? In a web browser, it's not a second-level menu; the hamburger button is always accessible at the left end of the search box.
The search box with hamburger menu is visible by default. You deliberately hid it to get to the state in your screenshot. It is two clicks to disable 3D from the default state. This is entirely reasonable.
You do realize that I myself, and many people I know, do not even try to learn "two clicks deep" anymore.
Why?
Because in 6 months there will be another phone, another product, a redesign, to "freshen up" styles, and everything we expended effort to dig out from even one click (or tap) below the surface is upended, and moved somewhere else, because of territorial pissings and careers behind the curtains.
User Interface experiences actually haven't improved since 1999. It's really just that the best parts of that era have withstood the test of time, and remained constant.
People come in with amnesia and make the same old mistakes over and over again, and we're forced to unlearn and relearn nested menu trees because popularity contests must be won.
Case in point:
> Google still has a minus operator for exclusions, but the plus operator was destroyed in the name of Google+
And just like the headphone jack on iPhones, we’ll never get it back because to admit error is to court liability and damages in the corporate context, and smells like a recall to suits and share holders.
THANK YOU for pointing that out. I've also become extremely frustrated at the way the Google Maps UI has evolved. I also had no idea that 'globe' was toggleable. Particularly because there's a "3d" toggle over on the other side of the screen, which just does a silly rotation rather than actually toggle the map between flat/globe...
I'm not sure if this is the same type of un-easyness you're referring to, but the whole video made me feel physically un-easy. The video is rendered at a very low framerate, and that combined with the fast motion of the camera is almost nauseating.
Aside from the low FPS, at 14-15 seconds, when the camera zooms past two skyscrapers on its left, I very quickly noticed (without having to pause the video and examine it) that the the buildings had low-res textures compared to what you would find in a video game or compared to real life. Perhaps this, combined with the low FPS, is what makes the experience so uncomfortable.
But while this may not be good for close-up fast moving shots, it certainly does seem to have useful applications (see 0:27, 0:33, 0:45 in the video).
And it's still very impressive how far our technology has advanced - the first heavier-than-air flight was about 100 years ago, computers are also just decades old, and yet right now we are using algorithms to combine satellite imagery and images taken from the surface (street view) to make a 3D model of our world that is explorable in real time (the Google Maps website has this 3D view feature on it).
Here's hoping* that this eventually matures into a widely available (if not free & free) 'Scenario Pack/API' provided by Google and available to any Developers, - Not just for leisure, but for practical purposes.
We need Google maps and street view to become consolidated (through a combination of physical mapping with drones, and CG via Unity etc.).
Once this is seamless, and any 3d point in space + direction can generate a full 3D render (in real time), it will allow for 'Scenarios' - Instances of the Gmaps globe that are pulled into applications.
'Scenarios' might be used in games:
- a 'real world snapshot, no wipes' scenario hosted on a game server, where players undertake a FPS survival game in an exact replica of the entire globe.
- On another server, there may be a '1991 zombie apocalypse scenario, 2 week wipes' scenario being hosted, where 'filters' have been applied to the real world snapshot to make the globe appropriately aged and decimated, with appropriate models and characters for that world.
Or more importantly, it might allow for serious modeling when utilized by certain platforms:
- Used for traffic flow - This could be incredibly valuable for use cases such as '3-dimensional traffic theory over San Francisco low altitude airspace - What impact to delivery drones will there be if a new skyscraper is raised in this zone?'
- For city councils and architects that are measuring heat absorption of concrete from the sun on the hottest day of the year / to model the wind flow through a city street that is acting as a wind tunnel.
The key to its success would be a) accessibility (Google or a third party maintaining this as an easily accessible platform & api) and b) rapid automation/layers (Being able to quickly load template 'scenarios' and apply 'filters' to them, rather than manually manipulating the instance).
While there are plenty of academic and technical tools available now for modeling, there is nothing ubiquitous and simple enough that allows a layman to 'load up the world as of 15/12/2018, now raise the global temperature by 5 Celsius, now fast forward 20 years.' If Google provides the API, then industries will rapidly set itself up around it.
It will be interesting to see how security & privacy are handled in these spaces. How do you prevent (and should you prevent) someone mapping the inside of your own home? Presumably, the primary strategy will be simple obfuscation (3d zones are tagged with a certain privacy level, which forces them to be randomly generated with each instance, rather than allowing true mapping)
*And goes without saying, here's hoping Google practices change so consumers aren't taken advantage of with such a platform
Is there robust integration of google maps with arcGIS in general? If not, then I would not expect any unique integration of the two platforms strictly for the google earth studio context.
In New Zealand we have an annual 48 Hour Film Festival where amateur film makers make a short film in well, 48 hours. I can definitely see this being used heavily in next year's competition.
what do you mean good animators? How do you animate 3d maps otherwise? You seem to imply this is a competing solution for some existing products that will produce broadcast quality video files of flybys of 3d maps...
yeah it's called stock footage. people do buy aerial flyby footage you know, if you just need it for flavor(like in a youtube video about your area) this is an amazing solution vs either finding stock footage or buying a drone and creating your own
Getting somebody on-site with training and a drone and a flight permit and communicating what exactly you want and getting the right footage and hoping the weather cooperates sounds a lot more difficult than launching a piece of software.
A multi-scale pyramid of tiled images allows O(1) access at arbitrary scales at positions, independently of the size of the whole thing. It may be something like that.
> Our 3D rendering engine currently uses a Chrome-only technology called Native Client to power Earth Studio. However, we’re closely tracking the evolution of WebAssembly (especially threading). Stay tuned!
Sure, but realistically, that makes no difference when (A) only one browser ever implemented it, and (B) its continued use by its originator company _despite_ deprecation last year (after its team was destaffed two years ago) still stinks of an attempt at lock-in, open source or not.
There are still things you can't do with the web platform alone. WebAssembly is still in its infancy, and not everything is really figured out yet. In this case, it looks like they're held back by the lack of proper threading:
>However, we’re closely tracking the evolution of WebAssembly (especially threading). Stay tuned!
It seems reasonable to get this program out and running today and move it over to WebAssembly in the future. One of the alternatives would've been to deliver a native app to every platform, but Chromium is already a native app that runs on many platforms that you can compile yourself, and then you get a security sandbox for free. Seems a better to me, frankly, especially in a world where many "desktop" apps just ship with Chromium anyways.
You've made a bit of a logical leap in the way you've interpreted my post.
So, because I think Google shouldn't use a technology that they themselves marked as deprecated, leaving it only supported in their own browser using their own technology that only they implemented, it shouldn't exist in any way shape or form — despite the fact that wasm is already supported in Chrome and other web browsers?
Obviously, they should have just waited until they'd finished porting to wasm. The world would have survived without the NaCl version of a tool they never had before; bloods wouldn't run down the streets if we'd have had to wait a little bit longer for the only version of the tool that should have released.
> It's like saying because an app using the Mac touch bar is Mac only is a terrible thing
It's really not. The touch bar doesn't purport to be a standards-compliant technology available for every platform to access in an equitable way; apart from the fact it's only on Macs, nothing about it was ever advertised as being explicitly designed for cross-platform use.
The analogy to Chrome, a browser that is advertised as standards-compliant and even advancing standards, to the extent that it already includes wasm support, utterly falls apart.
> It's how platforms work
Chrome is not a platform, and I find myself shocked when anybody thinks so. It's as though the lessons of the past (IE, ActiveX, plugin lock-in) remain unlearnt; a new generation of people who don't know how good they've had it for so long.
Chrome is __not__ a platform; it is merely the window through which we consume the real platform: the open web.
When Google tries to push Chrome as a platform, we need to all push back. We've had one browser as a platform, and it was not good, it was unhealthy for developers as well as advancements in web technologies, and I and anybody who still has to support IE5 and IE6 do not want to see that again.
There are some differences between Chrome and previous browser incumbents:
- Most of Chrome is open source. This would surely run in Chromium.
- It's cross platform.
- It supports web standards. WebAssembly for example.
Are things really full circle? I mean the situation could be better but the amount of things that work seamlessly between multiple browsers has never been larger. Very advanced web apps are now assumed to work across at least Chrome and Firefox, and probably Edge, with only a handful of exceptions, when in the past most things beyond basic pages simply didn't or required Java or Flash binary blobs. I don't think anyone in the browser space is intentionally making things worse, things have mostly just gotten better. NaCl may be a notable exception, but prior to WebAssembly it seemed like a good idea, and frankly the technology itself still seems pretty useful. NaCl also still has a lot of things WebAssembly doesn't yet.
I see no bad intentions. Just people making the best out of a rapidly moving platform. Someone else in this thread mentioned a WebAssembly port is coming eventually, no reason to doubt it given NaCl is deprecated.
Also, P.S.: The NaCl situation is unideal, but frankly I'd rather boot up Chrome to run something than, for example, installing and using an NPAPI plugin that has full privileges and code I can't inspect. (I am, actually, a Firefox user at home.)
(Disclaimer: Google employee, but nowhere near the Chrome team.)
It doesn't take bad intentions to end up destroying an open ecosystem, just a lack of effort to create standard solutions while being the majority market share gorilla.
Microsoft employees likely thought they were doing good by adding non-standard features to IE as well given that "standards couldn't keep up" for them either.
Sorry, I just don't see that pattern repeating here. Nothing like JScript or MSJVM, no ActiveX or BHO or COM.
NaCl solved real problems people had. NaCl allowed secure native code inside Chrome extensions and webapps, before Asm.js and before WebAssembly. It helped with removing insecure NPAPI usages (in the past, a Chrome extension could contain an NPAPI plugin![1])
Nowadays, NaCl is a lot less necessary. Many apps can run just fine in Asm.js and WebAssembly. This is definitely due to cross collaboration from the browser vendors, improving JavaScript performance and solidifying the idea of a cross-platform, safe, portable binary format that could be implemented by all browser vendors. That seems like a fantastic outcome to me, as an end user.
Other browsers could've implemented NaCl if they pleased. I recall Mozilla pushing for pure JS and later asm.js instead. In the end, the solution we really ended up with is a lot like a mix of NaCl and Asm.js. You could argue we would've gotten here without NaCl, but I think the end user is certainly better off without things like NPAPI plugins.
> Most of Chrome is open source. This would surely run in Chromium.
That's neither here nor there. For the purposes of this discussion, Chrome and Chromium are the same browser, and the design and development of the Chromium platform is very much dominated by Google, sufficient to call them the owners of the platform.
I signed up. I've been waiting for years for a way to animate Google Earth. Don't care that it's Chrome-only, good to see they addressed this in their FAQ.
