Why NASA Switched from Unity to Blend4Web • Hacker News Board

Re: Why NASA Switched from Unity to Blend4Web

#21

Post by stcredzero » Sat, Aug 15, 2015, 6:17 PM UTC

colordrops wrote: post #17

jebblue wrote: post #7

Earlier quoted context omitted.

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

In most cases I believe time estimates for technological advance to be far too short, but in this case I believe the estimate to be far too long. We've already got decent 3d engines running in the browser - it's not theoretical. With the current pace of web tech advancement and the advent of web assembly, it could easily happen within five years.

In terms of presentation, you're dead on. In terms of tooling and development environment, not sure that that's going to be.

Re: Why NASA Switched from Unity to Blend4Web

#22

Post by exodust » Sat, Aug 15, 2015, 6:27 PM UTC

simonz05 wrote: post #12

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 ex…

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!

Re: Why NASA Switched from Unity to Blend4Web

#23

Post by exodust » Sat, Aug 15, 2015, 6:32 PM UTC

efnx wrote: post #20

exodust wrote: post #19

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…

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

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.

Re: Why NASA Switched from Unity to Blend4Web

#24

Post by sandworm101 » Sat, Aug 15, 2015, 6:57 PM UTC

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?

Re: Why NASA Switched from Unity to Blend4Web

#25

Post by azakai » Sat, Aug 15, 2015, 7:04 PM UTC

pjmlp wrote: post #4

ndepoel wrote: post #2

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,…

Quite true. 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.

It depends on the functionality you need. Unity does a lot more than lightweight WebGL engines do.

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,

https://github.com/playcanvas/engine

Re: Why NASA Switched from Unity to Blend4Web

#26

Post by z3t4 » Sat, Aug 15, 2015, 8:29 PM UTC

jebblue wrote: post #7

ndepoel wrote: post #2

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,…

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

webGL is very low level, so you should be able to get good performance. But the problem I think is that the specifications/standards move too fast. If you start to build a game with the latest technology today, those technologies will be deprecated once your release the game :P

Re: Why NASA Switched from Unity to Blend4Web

#27

Post by ndesaulniers » Sat, Aug 15, 2015, 8:39 PM UTC

jebblue wrote: post #7

ndepoel wrote: post #2

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,…

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

I think you're conflating low level rendering API (WebGL) with Game Engine (built on top of low level rendering APIs such as WebGL, OpenGL ES, OpenGL, Direct3D).

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

Re: Why NASA Switched from Unity to Blend4Web

#28

Post by ndesaulniers » Sat, Aug 15, 2015, 8:40 PM UTC

z3t4 wrote: post #26

jebblue wrote: post #7

Earlier quoted context omitted.

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

webGL is very low level, so you should be able to get good performance. But the problem I think is that the specifications/standards move too fast. If you start to build a game with the latest technology today, those technologies will be deprecated once your release the game :P

This really isn't the case on the web. There are no "take backs-ies".

Re: Why NASA Switched from Unity to Blend4Web

#29

Post by justinschuh » Sat, Aug 15, 2015, 10:07 PM UTC

azakai wrote: post #14

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…

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

Re: Why NASA Switched from Unity to Blend4Web

#30

Post by azakai » Sat, Aug 15, 2015, 10:28 PM UTC

justinschuh wrote: post #29

azakai wrote: post #14

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…

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 expe…

Not sure what I did to deserve that hostility. I respect you and your work, and I agree that deprecating NPAPI is a good thing.

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.