Comments
It is very unfortunate that there are quite some wrong information and unprecise statements. As the author draws a major conclusion based on those, the whole article's quality lacks.
First of all, Unity already offers solution for video playback and networking in WebGL. They are freely available in the Asset Store. Besides that, Unity has a new networking solution that already works with WebGL.
And it is pretty obvious that Unity is not waiting for the arrival of other technologies. They are actively working on WebGL improvements. This can easily be found out just by having a look at recent release notes. Unity's WebGL heavily profits from improvements made in il2cpp as well, which is under very active development. That can also be seen in the release notes. This statement is unfortunately not correct.
Of course Unity is awaiting the arrival of improvements, because they will profit from those. E.g. WebAssembly will help to lower the memory consumption and improve the loading time. SIMD and multi-threading are already used in Unity and once they are supported by the browsers, Unity can use them without the need to implement them from scratch.
I'm not sure who the author is, but I have a concern about this post. It does not appear that he has any inside information or experience with NASA, Unity, or Blend4Web - although if he does, he should obviously say so. Assume that he does not, which seems highly likely given the way the post is written, then it appears the author has posted a title making a simple claim to basic factual and interesting information, without any such information. If he had simply titled it something else, such as "Why I think Blend4Web was a better choice for NASA" or "Unity WebGL support seems laking, Blend4Web is ready now" ... or any other title that didn't lead any reasonable reader to think there was some information related to NASA and their decision making.
Speaking on behalf of someone with whom you have no relations is simply unacceptable ... and for that reason alone I must request that this article be taken down until it can be re-titled appropriately. Everyone at gamedev expects an article titled "Why Blizzard Wrote Their Engine In House" ... to be authoritative, and most likely written by a key person involved in that process. Anything less completely blurs the difference between gamedev and reddit. I might give a pass if the author added (Speculation) to the title, and clearly said so in the lead paragraph.
Before any steps are taken toward censorship, I'd like to make some comments.
I'm not the author of the original article. Moreover, I don't agree with some things the author stated. However, I do believe that this post thoroughly expresses hopes and fears of a typical Unity developer who faced problems with the current WebGL implementation in Unity.
I think that I did a good job translating it because the article have got attention not only from Unity or WebGL developers, but also from the browser vendors, see this Hacker News thread for example.
I hope together we will eventually come to a mutually acceptable solution.
Before any steps are taken toward censorship, I'd like to make some comments.
I'm not the author of the original article. Moreover, I don't agree with some things the author stated. However, I do believe that this post thoroughly expresses hopes and fears of a typical Unity developer who faced problems with the current WebGL implementation in Unity.
I think that I did a good job translating it because the article have got attention not only from Unity or WebGL developers, but also from the browser vendors, see this Hacker News thread for example.
I hope together we will eventually come to a mutually acceptable solution.
Censorship would mean to eliminate uncomfortable or unwanted information. In this case, it is unfortunately unprecise and wrong information alongside with speculation. That's not really a good basis to draw conclusions and nevertheless the author does it.
It is obvious that there is a lot of emotions and frustration involved, but that doesn't excuse that lack of precise information. This article is structured like a serious technical article and will be recognized by many as such.
Justifying an article by the attention it is getting may work in the boulevard press, but is thankfully not a criterion for technical articles.
WebGL should work in all browsers on all platforms including mobile ones by default. It's not there. If you happen to successfully compile your game for WebGL, strike out mobile devices from the list. The reasons are clear: Unity's WebGL has catastrophically large memory consumption and bad performance. Yes, a top-of-the-line device can still manage to run the game at decent speed, but a cheaper one will run it as slow as a turtle.
True, some WebGL games are simply too ambitious for mobile, but there are some impressive WebGL demos such as this one on my iPhone 6 Plus at an intractable framerate. As far as large amounts of memory consumption: probably a byproduct of much of everything being in JavaScript --even if running as an IL/emscripten approach. WebGL's currently-supported implementation is the JavaScript equivalent to the OpenGL ES 2.0 API in C, which Unity's supported for some time now. They'd mostly have to use some sort of IL approach, such as JS.asm/emscripten to convert the code-base over to something browsers, even Node.js could run. It sounds like their own IL2CPP is their solution to that. If anything, just switch your platform and renderer to OpenGL ES 2.0, and you've got yourself a natively-written app. Now, your only hurdle is Apple's App Store review process. Sure, there are plenty of hurdles that Unity's got to jump, but their publicly-released efforts regarding WebGL look pretty solid so far.
The article fails to mention that many of the problems also stem from a poor WebGL implementation in most browsers and various limitations surrounding it.
It's just as likely that NASA as a government body have a policy in place to always prefer free open solutions over closed platforms.
This would be a big reason to choose Blend4Web (which is open source) over unity, which is a commercial product.
I think this very important reason for the choice may have been skimmed over or completely overlooked...
I think major reason to prefer blend4web for nasa is just chrome dropping NPAPI support that would make ~70% of unity web player users to stop using unity games on web, combine that with preference for NASA for open platforms.
Why do not browser vendors make an agreement on a language simpler than JS (but that can cooperate with it) that can be implemented in a more efficient way so that in future webGL platforms can just compile to that language ^^
Another speculation:
I just think Unity development life cycle is not well-suited for a programming team that has already its way of working, if you want to put many programmers together in unity you have to resort to frameworks like Svelto in order to make team work possible.
Hello Pierre Bezuhoff,
It would have been really amazing driving the rover around and wathing things from the camera in real time. Great read though.
Thanks.
PS: My Blog: xbox membership codes
A simulated Mars rover experience you can control, produced by NASA and developed with... Blend4Web??
Title is a bit misleading since the article is just your speculation.
Also, I would think the reason is more likely to be "Someone else eventually got the contract who preferred blend4web"