
Why NASA Switched from Unity to Blend4Web - felhr
http://www.gamedev.net/page/resources/_/technical/apis-and-tools/why-nasa-switched-from-unity-to-blend4web-r4150
======
ndepoel
It's very simple: Unity was never designed with a target platform as radical
as HTML5/JS/WebGL in mind. It's stuck with an older version of the Mono
runtime for its scripting language, and they've pulled off some crazy tricks
to get it to work on WebGL: Mono IL code is cross-compiled to C++, which then
gets cross-compiled again to JS/WebGL using Emscripten. That it works at all
is nothing short of a miracle. However, compatibility and performance will be
really hard to get up to a decent standard, especially when compared to
engines that were built from the ground up for WebGL, such as Blend4Web.

Long story short: if WebGL is your primary target platform, Unity is not
exactly the first place you should look.

~~~
jebblue
I doubt WebGL will be a serious competitor to any platform 3D engine for at
least another decade, probably two.

~~~
lisivka
I exported my home from SweetHome3D into Blender, then into HTML5 using
blend4web and it looks surprisingly good both on my fresh $100 smartphone and
on my $600 notebook. I just added another source of light to make shadows
softer. I reading book about Blender because I want to add walkability to
home, but I have no idea how. :-)

~~~
codewithcheese
Sounds like you really love your home :-)

~~~
lisivka
I hoped that I will start building of my home in 2014, but revolution and war
with Russia delayed it. I bought plan of "Starboard Solar home" built in
Boulder, Colorado 30 years ago. It uses Trombe wall to heat and/or cool home.
I will also use G.R.E.B. technology to build "Passivhaus". Unfortunately, I
spent all my savings at revolution, so now I am waiting until I will have at
least $15K in savings to build enclosure, so I am spending my time to make
building plan detailed and SweetHome3D is perfect tool for that, except that
it is hard to share 3D model with others. Export to HTML5 solved my problem: I
can just display home levels on my cheap 5,5" smartphone or share it using
Google Drive.

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.

~~~
codewithcheese
Just saw this comment now. Interesting to hear your story. Do you have a link
for your home HTML5 model?

------
azakai
The article puts too much blame on Unity and not enough blame on browser
vendors.

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/webgl-issue-on-
chrome.336871/)

[http://forum.unity3d.com/threads/bugs-in-chrome-
stuttering-a...](http://forum.unity3d.com/threads/bugs-in-chrome-stuttering-
and-javascript-error-on-reloading-page.337880/)

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...](http://www.winbuzzer.com/2015/07/28/asm-js-only-benchmarking-
asm-js-javascript-performance-of-microsoft-edge-vs-google-chrome-44-vs-
firefox-39-xcxwbb/)

~~~
justinschuh
I want to be clear that I fully intend to spend my weekend with my family, and
not arguing this with you. So, I'll avoid rehashing any of our past
discussions regarding technical concerns with asm.js. However, as the person
responsible for Chrome's NPAPI deprecation, I just want to set the record
straight regarding Unity.

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...](http://answers.unity3d.com/questions/574054/can-i-use-native-
client-nacl-in-unity-43.html)

~~~
com2kid
> However, as the person responsible for Chrome's NPAPI deprecation, I just
> want to set the record straight regarding Unity.

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.

~~~
tedmielczarek
> 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.

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.

------
thearn4
Just a quick note: NASA is not a unified entity marching in lockstep. This was
one org-unit's decision made for their own work. I work with a lab at NASA GRC
that uses Unity engine pretty extensively for scientific visualization.

------
simonz05
We have a product which used to run on Unity Webplayer. After the Chrome NPAPI
deprecation we lost about 50% of our users. WebGL wasn't done and still isn't
really working. Our experience is the same as described in the article. Memory
usage and multi million lines of compressed JavaScript will cause most of our
users computers to freeze or lag out. Any user with less than 4 GB and on
Chrome will have a pretty bad experience. FireFox is far ahead here and runs
much better.

Edit: Direct to one of our games using WebGL and websockets.
[http://www.kogama.com/games/play/68818/?webgl=1&da=0](http://www.kogama.com/games/play/68818/?webgl=1&da=0)

~~~
exodust
That's pretty cool. So that's not the Unity webplayer, so what is it? Good
draw distance. Crazy stuff in there!

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!

~~~
simonz05
Didn't formulate myself very well. It's the Unity WebGL export using
WebSockets for the network component.

------
Aardwolf
Good. Anything that goes away from Unity is good. I dislike Unity because they
refuse to make their web player for Linux. So several Newgrounds games don't
work for Linux users due to Unity.

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 :).

~~~
Dantus
Unity's goal is to improve their WebGL builds, such that the experience is
basically what you got with the WebPlayer, with the exception that no PlugIn
is needed. This means, you are going to get the Unity WebPlayer experience on
Linux thanks to WebGL.

------
zimbatm
Blend4Web homepage with nice demos:
[https://github.com/TriumphLLC/Blend4Web](https://github.com/TriumphLLC/Blend4Web)

------
deproders
What about Unreal 4? I read that they support HTML5 pretty decently by using
Emscripten. I really do not know what is their current status on that subject.

~~~
daredevildave
It's a push to call the Unreal 4 support decent. Unity at least have it as
part of their product feature set. Unreal seem to do it only as a
demonstration piece.

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](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](http://tanx.playcanvas.com) (~1MB)

[http://mmx.playcanvas.com](http://mmx.playcanvas.com) (~3MB)

[http://swooop.playcanvas.com](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.

------
exodust
To be fair, the previous Unity version he links to is obviously a beta design.
It actually says "beta" at the top. For me, the Unity version loads and runs
smoothly.

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!

~~~
efnx
But isn't Unity required when using the Unity plugin? Blender is at least open
source!

~~~
exodust
Yeh true. I was responding more to his criticisms of that version based on the
quality of the product...

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.

------
eggy
I wonder how big the deliverable is compared with Unity, UE4 or other similar
solutions? I am a long-time Blender user, but I have never used this in any of
its previous versions. It seems it supports a lot of the things from Blender -
materials, lights, and others. I will have to see how much can be directly
used in the transition. I am not very clear on GPL. If I use it for my
company, but I choose to release the source, do I still have to pay for a
commercial license or is the open source license adequate? I know the
commercial license comes with a lot of support material.

------
sandworm101
Is nasa doing this stuff in-house? I've never thought of nasa as experts on
software beyond control systems. Have they brought in some gaming people to
help with media relations?

------
jimmaswell
Was it that necessary to keep it in the browser? Why not just give it to the
user as a normal Unity build download instead of redoing everything to keep it
on the browser?

------
mschuster91
Hmm, about networking, could not WebSockets be used for client-server comms?

~~~
simonz05
WebSockets work for Unity WebGL. Not sure if there is an official
implementation, but we use it in a multi-player game. We specifically run
Photon Game Server with WebGL and WebSockets.

