Why NASA Switched from Unity to Blend4Web(gamedev.net) |
Why NASA Switched from Unity to Blend4Web(gamedev.net) |
Long story short: if WebGL is your primary target platform, Unity is not exactly the first place you should look.
If one main goal is WebGL then the best option is to adopt a WebGL native engine, instead of trying to cram a native experience into the browser.
Of course, if a lightweight WebGL engine is enough - and it might well be the case for this NASA app, which doesn't need sophisticated AI, physics, scripting, effects, etc. - then that is the better route.
There are also middle grounds between a native WebGL engine and a full native engine like Unity. There are lightweight native engines, like Cube 2,
https://developer.mozilla.org/en-US/demos/detail/bananabread
and there are even lighter than that. There isn't a dichotomy between native and compiled game engines. In fact, some native WebGL game engines use compiled portions, like PlayCanvas which uses ammo.js, a compiled native physics engine,
WebGL does have to do some validation, but most implementations are built on top of ANGLE, which for the most part is _NOT_ an emulator. It does have slow paths for things that exist in WebGL such as the TRIANGLE_FAN drawing mode that don't exist in D3D11. For an interesting read, might I sugguest: https://books.google.com/books?id=6crECQAAQBAJ&lpg=PP1&pg=PA...
This is hinted at in the article:
> Browsers are the programs which eat all of a computer's free memory, and the half-finished Unity WebGL build often causes crashes and closes browser tabs (especially in Chrome).
The main problem is that Chrome has deprecated NPAPI before it is capable of running content like Unity well.
If you look at Unity's forums, you can see lots of posts talking about Chrome-specific issues, for example
http://forum.unity3d.com/threads/webgl-issue-on-chrome.33687...
http://forum.unity3d.com/threads/bugs-in-chrome-stuttering-a...
As those threads say, many Unity games run well in other browsers, but since Chrome is dominant in the market (over 50%), poor Chrome performance makes Unity look bad. But this isn't Unity's fault.
Chrome decided to deprecate NPAPI now, before it has a good-enough solution for running large asm.js codebases. For example, on the Massive asm.js benchmark, Chrome is well behind both Firefox and Edge,
http://www.winbuzzer.com/2015/07/28/asm-js-only-benchmarking...
Edit: Direct to one of our games using WebGL and websockets. http://www.kogama.com/games/play/68818/?webgl=1&da=0
Edit.. The loading experience was a bit clunky for me btw. I'm assuming it's not the Unity plugin you're using here, but I think Unity would have done better with loading!
The Blend4Web Mars Rover demo here works perfectly for me in Linux btw, and guess what, the linked old Unity version says "unsupported platform", so, thank you NASA for thinking about more users :).
The problem with taking a engine like Unity or Unreal and compiling to javascript is that 1) they end up with very large blobs of javascript (Unity is around 5MB of JS for the webplayer alone) 2) It is impossible to optimize, debug or inspect any of that code in the target setting. Neither of these engines have ever demonstrated code running on mobile browsers for good reasons, they can't.
Meanwhile, engines designed specifically for the web, for example, PlayCanvas [https://playcanvas.com] let you create content that works on every device, down to the likes of the iPhone 4S and comes in much smaller download sizes. e.g.
http://tanx.playcanvas.com (~1MB)
http://mmx.playcanvas.com (~3MB)
http://swooop.playcanvas.com (~10MB)
All of which work on mobile browsers. The future of Web 3D is not compilation of desktop game engines. It's engine's designed to be web (and mobile) first.
Dont bother. Its lightyears worse than unity, and thats saying something.
The Blend4Web version seems more polished because it is more polished. They've toned down the lighting, completely changed the interface, and reduced the map area.. you're confined to quite a small space. The Unity version you can drive further, only the ground texture needed work. Zoom out though and you'll see why the ground texture is more blurry than the Blend4Web version.
I'm sure Blend4Web is great, but what isn't great is that Blender is required!
Bezuhoff says: "Honestly, it looks like an unfinished game. The scene loads slowly (especially the terrain), functionality is primitive – you can only drive, the overall picture is of horrible quality."
I think that's a bit unfair considering it only looks like an abandoned game because it is an abandoned game.
Unity previously had a high quality NaCl port (long before asm.js ever existed) and I fully expected that they would continue to support it. Plus, long prior to NPAPI deprecation the Unity NPAPI plugin was on our security blocklist due to a rash of vulnerabilities. So, I don't know why Unity chose to drop support for NaCl, but it occurred well after they became aware of our plans to remove NPAPI. And if you want a public record, you'll notice that Unity 4.3 was released (without NaCl support) months after our NPAPI announcement:
http://answers.unity3d.com/questions/574054/can-i-use-native...
The 1.5 year notice you gave before depreciating the NPAPI in Chrome was way to short. 5 to 10 years would have been realistic to allow existing games to reach their natural end of life. Both NaCl and HTML5 are not appropriate porting target for an existing, complex PC game that's already running for several years. They are only a realistic target platform for starting new projects. What we do now is simply moving our users out of the browser into the standalone client, thankfully our users don't mind that much since most are 'hardened' PC players that don't mind the scare popup dialogs browsers put up when downloading a native installer. But it can hardly be in the interest of browser vendor to move gamers out of their platform I would think.
And for NaCl vs HTML5:
- NaCl was never allowed in the wild, only through the Chrome app store
- PNaCl simply came too late and had very long compilation times at first start, this has become better but is still a lot slower than FF's asm.js AOT compile pass
- performance differences between PNaCl and JS on Chrome are pretty much negligible, especially for a 3D game where WebGL overhead is much more important
- emscripten puts much more effort into supporting standard APIs for games then NaCl (e.g. SDL, glfw, OpenAL, ...)
- from personal experience, bugs in Chrome on the HTML5/JS side are fixed much more quickly than bugs on the NaCl side, very likely because the HTML5 side has much more resources available
From my experience, the PNaCl implementation in Chrome doesn't provide any real-world-advantages over the HTML5 way, and both platforms are a 'hard' porting target. Of all existing platforms (iOS, Android, OSX, game consoles), the web is definitely the hardest to port an existing PC game to (starting from scratch is much easier though).
Why? You have regressed a feature that your users want. I realize that plugins aren't sexy, but Unity is something that both developers and users want. Entire development studios are based around creating online games in Unity that have active user bases who enjoy those games.
For better or for worse you have removed the ability for people to enjoy using a part of the web. But hey, an idealized vision of software perfection won out over what users wanted, so you got that going for you.
I'm a bit bitter that those in charge of browsers have en-masse decided that being pragmatic is worthless in comparison to creating idealized castles in the sky. This just as much applies to Mozilla as it does Chrome. Mozilla's response to why they won't implement Pepper is just as "pie in the sky, who cares what users want" as Chrome removing NPAPI is.
Plugins are something that users want. Ignoring how Adobe has managed to completely drive Flash's overall quality and performance into the ground, plugins are useful. They may not be useful to Developers who are doing Serious Developer Stuff at Serious Companies, but for a lot of users, my mother, my grandmother, my nieces and nephews, they are very useful.
On the other side, browser developers have content developers as customers. Those content developers prefer alternative toolchains. Flash and Unity have far better tool chains than WebGL does. Debugging problems is far easier when you don't have to go through multiple translation layers. And less layers in the stack means less places for something to go wrong. If you are writing against Flash then Flash may have a problem. If you are writing against 3 different browser's implementation of WebGL and/or ASM.js you now have 3 different sets of bugs and implementation quirks. (Not that Flash works the same across all browsers, but at least it is from one vendor!)
But all of that is thrown away in the name of "web standards".
Users care about what works. As developers we have a responsibility to make users happy, our own sense of happiness is sort of not the primary concern.
I don't know anything about why Unity stopped supporting NaCl.
But the fact remains that Chrome has left Unity no good option. Chrome's asm.js performance on Unity (and large asm.js codebases in general) is lagging. NPAPI is gone (again, a good thing by itself). NaCl exists, but would require Unity to maintain support for a platform only for a single browser.
If your product runs poorly on the dominant market platform, then that _is_ your fault. Especially as Chrome provides source, a reasonable community centered around that source, and strong developer tools to allow third parties to achieve superior performance on their browser.
It's understandable, but the Unity developers made a guess as to the future state of the market and that guess was wrong.
This seems like an unfair comparison. "Remove existing functionality that we no longer want to support" and "support a large technology with a single implementation and no specification" are not even in the same ballpark.
IMHO, export of 3D models to HTML5 is superb technology and will be used everywhere. For example, clothes shop can use it to display clothes on model of customer, in dynamic (walking, dancing, running, etc.). Car shop can use it to provide virtual test drive. Constructions shop can use it to let customer practice with tools and materials. Anybody willing to start SaaS startup in that area? I am working for outsource firm, so I cannot start a software startup, because I will be fired immediately and I have not enough savings, but I can be hired. I have more than 25 years of experience in programming and more than 30 of successfully finished projects (and 2 failed), I participated in few startups (e.g. Bazarvoice), I saw my code spread, e.g. in BashFAQ, etc.
Getting back to your point, pragmatically speaking, maintaining a port is a distinction with less difference than implied. First, any reasonably complicated NPAPI plugin needs to handle a range of browser-specific quirks, meaning that significant porting is unavoidable even if it's bundled into one binary. Second, Unity supports ActiveX in IE, so they're clearly already comfortable maintaining a browser-specific port that doesn't offer any of the security or platform portability benefits of NaCl.
Outside of that, there's just the one-sided nature of the argument. As a creator of asm.js you are obviously a huge proponent. However, you must appreciate that not everyone perceives it the way you do, and not everyone agrees with the path you chose for adding support into Firefox. So, the technical burdens on another browser are just not the same, and in the specific case of Unity in Chrome have to be balanced against the fact there was already a tremendous past investment in a high-quality implementation.
So, no, I completely disagree with the framing that "Chrome has left Unity no good option". Independent of any work in Chrome on better supporting asm.js, the fact is that Unity had at least one other good option. So, I'm sure Unity had their reasons for the path they chose, but it was and continues to be a very explicit choice.
But the more important thing is that I disagree on the effort it takes to optimize asm.js. As you can see in those forum posts, out of the 4 major browsers, mainly Chrome is presenting a problem to Unity developers. Yes, it takes some work to optimize huge compiled codebases well, but Google has talented engineers and massive resources. I refuse to believe that Chrome cannot match the results of the other 3 browsers - it would be insulting to the v8 devs to assume so. Since the ability is there but the results are not, I can only guess that the Chrome developer's focus is elsewhere.
And of course there are many other important things to optimize on the web. But Unity and other high-quality 3D games are very important too. Chrome is holding back this part of the web, right now - I hope not for long.
But they haven't optimized it well enough yet. The main issue Unity (and other big asm.js codebases) are seeing is OOMs and crashes in Chrome. The v8 and JavaScriptCore approach can avoid those, by not compiling everything at once, more efficient in-memory data structures, and so forth. This helps overall JS performance as well. It's just engineering work that needs to be prioritized and done.
(AOT, as in Firefox and Edge, does have an advantage in startup speed that I think v8 and JavaScriptCore will have a hard time approaching, but that is not a blocking issue the way that crashes and OOMs are.)