Reconsider supporting a HTML5 + WebGL Javascript API Exporter

I've been keeping an eye on the upcoming technology (HTML5 + WebGL Javascript API) and I must say, I've never seen so much activity surrounding any one technology in my entire life such as WebGL. Microsoft IE is rumored they're now onboard.

http://webglstats.com

I strongly recommend the Unity 3D group reconsider supporting a HTML5 + WebGL Javascript API exporter for the near future. I'll be relieved to know directly from the horses mouth that at lease you'll reconsider this fabulous technology.

Thanks
CSDG

 

There's a feedback section
Unity Feedback.
Btw, welcome to the forums.

 

It would make 0 sense from unity, it's just not possible to port to that as it's not just "not the same technology", but even "not the same type of technology". You can't just "port mono to html5" and be done with it.
Doing anything in that scale is probably more work than ALL the other platform ports combined, and in exchange you get pretty much nothing (unless you expect triple A source code included games with 100M+ of JS download on the web requiring unity lv graphics and being paid for 50$ to actually be viable).

 

Fallibilism! Does the Unity group actually hold such attitudes? Our little world is constantly evolving and I hope that this is true for the Unity Company. Lets discuss the Pros and Cons on the WebGL technology. As with any "experiment" such as many are doing with WebGL today, Unity can do a feasibility study and apply it in some corner of their R&D labs. This does not require incorporating it into the present unity technology but a "unit" that can by incorporated later.... Of course I could go on... Please, open you minds.

Thanks
CSDG

 

There's 0 need to do a "feasibility study", it's painfully obvious how feasible or not it is, as i said it's not comparable to porting to another platform, i can tell you exactly what this would involve to port the core at least

1) Write a C# to JS converter and port ALL of the supported mono subset to javascript, including marking any native feature as not supported or redirecting those to html calls (you're talking man years just for that)

2) Write a C# and js assembly parser to raw unmanaged javascript converter to export the actual games

3) Write a additional renderer for webgl (this is the easy part most likely, and what already needs to be done when porting to other platforms)

4) Port all the C++ parts of the engine to raw javascript too, rewrite all the C++ / C# interop to work for ported js (from C++) to ported js (from C#/unityscript)

5) Get rid and write compatible versions of all the runtime middleware (or licence it for source and rewrite it from scratch) for javascript

It's just so painfully obvious that it's not feasible that it doesn't require a feasability study.

If you see a car and ask "could we add a wing to the bottom of this city car without changing mileage much because it is cool?" this requires a usability study, if you see a car and ask "do you think we could toss in a spaceship behind it, and have the car unmodified haul it while it weights 200 megatons because it looks cool?" it doesn't need a study at all. This falls in the 2nd category and i went very lightly earlier, i'd actually guess the proper estimate is closer to "this would require more work than the sum of all work unity employees have produced since unity exist just to port to this if simply supporting it as a compatible platform"

 

@Ronan

(1) What has the Unity Company done so far with WebGL?

(2) WebGL, a javascript API where WebGL is less but similar to OpenGL which Unity is presently using!

(3) Not once have you spoken (written) about WebGL, OpenGL or DirectX.

(4) Your Cons have no correlation to the WebGL technology, not even OpenGL...(http://www.khronos.org).

(5) Why is your mind so closed, to the future of modern commerce.

Thanks
CSDG

 

It's not that impossible, they say they did a port "in 4 days" (although it's a marketing press release):

http://news.softpedia.com/news/Mozi...al-Engine-3-to-the-Web-in-4-Days-340946.shtml

 

My mind is not closed to anything, i'm just telling you that it's not possible, it's not about the pro cons, it's about technology limits, it's physically not possible, there's no need checking pro and cons when the main con is "it's not possible".

The issue is NOT webgl, webgl is perfectly capable and you'll probably see many 3D engine for webgl, but what is not possible is it take a generalist engine like unity that is based heavily on native code and mono, and expect to add webgl as a platform, it's not possible that's all, at least not withought absolutely insane amount of ressources

 

This has nothing to do with webgl html5, they ported the engine to the browser is all, unity can already run in browser.
Porting unity to firefox like unreal did is a thing, exporting native code to JS including the whole very large (millions of lines of code) frameworks and re providing the native (os specific) functionality to native JS with dom+HTML5 is a whole other thing.

Once again the issue is "not" webgl, it's "just taking a unity project and porting that to JS + html5 + webgl", webgl is a capable technology, it doesn't mean you can automagically port native code / managed code / middleware to it.

 

They already did that for the Flash export (porting everything to Actionscript, well most things anyway), so it's far more possible than you seem to think.

It has everything to do with it...read the article again, specifically the second paragraph. It's not a web plugin like the Unity web player.

--Eric

 

Doesn't sound in the same difficulty league to me at all, and honestly they're very far from having done it, i mean just check the limited not supported list! Buggy shadows, Unityscript language not well supported, no GUI at all most .net features missing etc etc, it's a really limited port very far from "taking a unity project and just pushing it to flash".

Hell when i tried it first i couldn't even get a simple terrain + basic water with a character controler working in flash! So think how it'd be with something where you'd need to test a dozen web platforms before release

edit: hell it doesn't even support terrain! sounds to me like it supports pretty much "nothing" most everyone uses : http://docs.unity3d.com/Documentation/Manual/flash-whatssupported.html
I'm not trying to undermine the effort, it sure is a great effort, but to me it sounds much easier to port to actionscript than to js+webgl in browser, and it's already not looking quite bright.

 

RONAN - You are so closed!

DONT USE THE UNITY ENGINE. START ANEW, A SEPARATE UNIT THAT CAN BE ADDED LATER!

Use what you can already with OpenGL,then scale down to WebGL.

CSDG

PS - You're faster at the keyboard.

 

No, i'm informed, you come here, ask if something is possible, seemingly have no technical clue, and when pointed to reasons why something doesn't sound possible, do not reply with technical information but diss people as closed.
Either you know better than i and you should explain your thoughts in technical terms, or you don't and you should try and understand what i'm saying. Sure it'd be nice to support more platforms, i just don't see how they can reasonably (in terms of budget) support that one, it sounds massively complex and expensive, pretty much impossible to support, and IMOH is unlikely to generate much revenue short term.

 

I didn't read everything in this subject that is out there, but in theory, since Mono runs as managed code on top of a CLR, it would be a matter of translating the CIL (pseudo-machine code) to AsmJS.

They already ported hard-coded C++ UE3 to it, and, like the marketing guys like to say, in 4 days.


From http://asmjs.org/faq.html
"Q. Can asm.js serve as a VM for managed languages, like the JVM or CLR?
A. Right now, asm.js has no direct access to garbage-collected data; an asm.js program can only interact indirectly with external data via numeric handles. In future versions we intend to introduce garbage collection and structured data based on the ES6 structured binary data API, which will make asm.js an even better target for managed languages."

 

What has the Unity Group done so far with WebGL?

Dr. McCoy: My God Man, the technology is out there, just use it.

CSDG

 

This has nothing to do with MONO but HTML5 (OUTPUT - EXPORT - INTERNAL)

 

Again, it's far more possible than you think. It's not trivial by any means (or it would be done by now), but you're over-exaggerating the technical issues. As I pointed out, they've essentially done it already for Flash. Not all features are supported, but the groundwork is done, so they could expand on it if there was more interest in the Flash export. Read the article about Unreal on the web again for some technical details as to how it's done.

--Eric

 

They didn't port hard coded C++ UE3 TO THIS AT ALL, they ported it to firefox, by making something custom for firefox, that is firefox specific and has nothing to do with javascript.
I'm not talking about managed being harder than unmanaged, both are hard to port to JS in a web browser, i'm just pointing that unity needs to port both as it uses both, so twice the work.
And not it's not like that at all, the CLI isn't "pseudo machine code", it's the runtime engine and associated components, but it's not remotely thinkable they'd do that for speed reasons, they'd have to convert code to native JS, not to .net in JS. The CLR works by jitting MSIL code, you can't do that in JS as you can't generate native code there to run, so you'd still have to export as raw JS, which is very diferent from just porting mono to another platform and having everything based on it automagically work (like it's possible for pretty much any native platform be it a console or pc os or even phone)

 

I actually can't find any details about unreal on the web, i find many articles about it "saying it works in firefox but not stating which tech it uses" usually correlated with "oh look at game X too, tiny web game done in webgl", but none stating how it's done for unreal, since it only supports firefox i'm assuming it's not exporting to JS+html5+webgl however, else it'd work on all modern browsers.

 

Like I said before, there is a lot going on, for example,
the Goo Engine: http://www.gootechnologies.com ,
the CopperCube: http://www.ambiera.com/coppercube/ ,
the Chrome Experiments: http://www.chromeexperiments.com/webgl/ ,
the AWWWARDS: http://www.awwwards.com/22-experimental-webgl-demo-examples.html ,
MANY MORE LIKE: http://www.webgl.com

And lots and lots of rumors..., for example:
http://news.softpedia.com/news/Mozi...al-Engine-3-to-the-Web-in-4-Days-340946.shtml

Unity: Its too hard. ( I'm not sure if I inferred correctly that this is Unity's response or position on WebGL, so I apologize if it is not.)

More importantly (review the entire site): http://webglstats.com

CSDG

PS Ronan out does me again on the keyboard.

 

Of course there is, no one is downplaying webgl, as i said engines made for webgl is one thing, it's completely diferent to port an engine to it is all.

 

http://asmjs.org/faq.html
"Q. Is asm.js a new language?
A. No, it's just (a subset of) JavaScript. An asm.js program will behave identically whether it is run in an existing JavaScript engine or an ahead-of-time (AOT) compiling engine that recognizes and optimizes asm.js—except for speed, of course!"

Friend, you are confusing CIL with CLI. Think twice. You're boldly correcting too many things when you're actually wrong.

 

I'm not confusing them at all, i just misread sorry, i come from the time when MSIL was used most when CIL was meant so i missred

I know very well asm.js isn't a new language, i hear that it can be accelerated by browsers wishing to do it too, this out of the scope of html5/webgl and implementation dependant, but it still doesn't solve the non native porting, much less the native to non native bridge (here you have both way interop of native non native and third party native and non native and user provided native and non native code, that's quite more of a mess than just C++ in the engine + a scripting language on top for unreal).

Edit: also note that the llvm to js tool they use is exactly one of the large point i named, it just happens it's already done by someone, so you don't have to redo it, but unless it's done for .net too then it still leave a lot of the work, even without the bridging issues. I'm not saying it's impossible, but it seems damn huge compared to other ports.

 

They haven't commented on it that I'm aware of.

--Eric

 

Hey Ronan

"Mozilla and Unreal Engine are Unlocking the Power of the Web as a Platform for Gaming"

http://www.unrealengine.com/en/news...unlocking_the_power_of_the_web_as_a_platform/

CSDG

 

I've already seen that, it doesn't go against anything i've said, i maintain that you can't compare porting unreal to porting unity.

 

Hey Ronan

Are you employed with the Unity Group? If not, I apologize to Unity!

CSDG

 

No, no one who posted in this thread is, unity employees have it clearly marked, hell i even have my name title company info in my signature, it should be pretty obvious i'm not affiliated with unity

Edit: Also why are you saying "unity group", there's no group, this isn't an open source group or anything, it's unity not unity group, their full company name is Unity Technologies

 

Hey Ronan

You're funny, dogmatically.

CSDG

 

You're really confusing lol

 

Hey Ronan


Obvious, perhaps, your company operates as one of Unity's rival or worse, an affiliate, because you are so against any kind of bond between Unity and WebGL. So the question I ask is WHY!


Cliché, it is you who has been confusing.


Please, you are creating games, right!? And for what ever reason, you have nothing better to do than knock the WebGL and Unity bond.


For myself, I am creating games but also experimenting with new technologies such as WebGL and HTML5 for commercial gain along with the Unity Web Player also for commercial gain. The way that WebGL is advancing without any plugin mind you, I'll choose WebGL. WebGL can be mixed in with HTML5 technology. It's cleaner and faster than waiting for a player content download. I am fighting for Unity so they'll get on board because they have an affordable game engine that can be used to export HTML5 - WebGL content.


CSDG

 

Well this is getting trolly, but i'll bite

My company has neither shared nor opposed direct goals with unity, we're just end users of it that's all. My main market isn't even video games atm it's still line of business applications, so i have 0 direct interest in this. I find it ironic someone with pretty much 0 history comes up brandishing a tech as if it's the holy grail and refutes my technically backed arguments with "you must be biased".

I've been giving you technical backed answers to your technically uninformed comments of "why not try, omg! good! it rockz". Basically you seem to have no idea of what it would involve to port the engine, just talking about it because you seem to think this new tech is cool.

I haven't knocked either tech once, and there is currently no "bond" whatever that could mean between them, just stating raw harsh reality that it is far from easy to do such a port, and very costly. I've said it multiple times in this thread, WebGL is proven to be quite capable, that's not the issue, the issue is it possible to do. You seem to miss one key thing, the pros don't matter if the cons make things unfeasible, here i think it is the case, it's very costly to do such a port.

It's a matter of finances not of technical limitation, if this was an easy port it would be a no brainer, since it's not it's an investment + support cost vs expected revenue, and IMHO it's a horrible ratio in the case of html5+webgl because the cost would be huge.

It's not about whether i want it or not, i don't care, i have 0 interest in such a plugin, nothing will change for me whether it exists or not, I'm just telling you, in technical terms, why i think it's very hard to do and why it's very unlike unreal engine (because unity is very different from unreal technically). Unity supports 10s of platforms i don't care for, but it was obvious each of them would be easy to port (except for flash) because it's os/architecture level port and .net/mono is meant to be retargetable by design, here it's a technology change, it's not comparable.

So yea my take on it is, if there was a clear demand for a flash export and (no offense intended, it's already pretty good compared to the work, just comparing it to the other unity platforms there) in the end, it sucks even now that it's matured, supporting only the most basic things and pretty much none of the things used in 3D games, then why do you expect it would be easy to port to something that is awfully slow, incompatible between each browser, not accelerated the same way, dependent on JavaScript libraries being accelerated by the browser, needing to explain to end user the exact browser and browser version they need, and if perfectly done will end up being far from full featured and 50% slower than the web player in the best case where you actually have the latest firefox nightly?

 

OK Ronan

What do you know about OpenGL much less WebGL? Again you talk like you know your business but you talk nothing, not one iota, about WebGL.

Unity uses OpenGL! It can use WebGL. WebGL like OpenGL runs on the GPU not the CPU.

WebGL is not a plugin, it is an API. Specifically, a javascript API and everyone knows that Unity uses a javascript scripting language so they have knowledge about javascript.

Thus the output is HTML5 and WebGL Javascript API Libraries (source code).

CSDG

 

Once again, you do not understand, the problem IS NO WEBGL
BEEP BEEP RED ALARM READ READ ---- i repeat , i repeat, there is NO PROBLEM WITH WEBGL
The issue is porting the engine, changing the RENDERER (webgl vs opengl or directx) isn't the problem, and unity already supports multiple renderer, no one in this whole thread has once mentioned webgl is the issue, if you do not have the technical background to follow the discussion, then ask, don't claim.
The engine is not just a renderer, it's the whole lot of (cpu side) code that exists, all the third party middleware (umbra etc) the terrain engine the mono framework etc etc, all of that needs to be ported to javascript and this has absolutely nothing 0 zip niet nada to do with webgl, hell it would be the exact same issue if you wanted to port it before webgl even existed!

 

As a side note (on webgl this time) webgl is much less available than you could think when you check the stats on webglstats that you quoted, it's taken from a very small sample of websites that are heavily biased toward technical users.
If you want a more realistic view of WebGL support check out larger scale browser stats and keep in mind that internet explorer doesn't support webgl (IE all versions together = 30-50% of browsers). That's one of the things that doesn't help the pros as as long as IE doesn't push webGL support (and quite a while after that, probably a few OS iteration after that for people to migrate to latest IE) this means no webgl for 30-50% of your users.

 

Ronan Seriously

The renderer in unity uses OpenGL so it has everything to do with WebGL. AGAIN what do you know about OpenGL?

CSDG

 

God are you for real? There are multiple renderers in unity, OpenGL, DirectX 9 and DirectX 11, i'm not into mobile but i assume they have a custom path of OpenGL ES or something too? What you don't get is that the renderer is a tiny tiny tiny tiny TINY TINY TINY piece of unity.
AND IT IS NOT THAT PIECE I AM SAYING IS HARD TO PORT, going from openGL to webGL is easy, that doesn't help you port the 99% of code that remains once you've ported the RENDERER

 

Hey Ronan

Isn't "OpenGL ES" WebGL? The only difference between the two is that WebGL is a javascript API.

CSDG

 

It's the same base spec (i don't know if it was changed), but you don't seem to get it still, you're the only one talking about webgl the renderer, from the start i've been saying the issue is not webgl, hell if it was exposed out of browser webgl could be added to unity in 2minuts, the problem is porting the unity engine, not writing an additional renderer, even more so if they support opengl es 2.0 already.

 

Ronan

Quoted earlier:

As with any "experiment" such as many are doing with WebGL today, Unity can do a feasibility study and apply it in some corner of their R&D labs. This does not require incorporating it into the present unity technology but a "unit" that can by incorporated later

CSDG

 

Renderer in this context is the part of the code "in unity" that serves as a unified api, basically a graphic engine will usually have multiple renderers (say one for DX 1 for ogl) offering the same interface so that they can be called the same way.
But the rest of the engine is renderer INDEPENDANT, it works the exact same regardless of what you're using (webgl opengl directx, your custom raytracing engine, a software renderer, this changes nothing). But here's we're talking about having to port the ENGINE to js, and you keep mentioning the renderer but the renderer IS NOT the problem, the problem is porting EVERYTHING ELSE!

 

Hey Ronan

Sorry not intended to post that...

READ the previous reply....

Added: YES - port a subclass of the engine in javascript code... Hey I believe you got it.

CSDG

 

Ok here's a very very simplified view of what i'm trying to get across, here's a guesstimate of a very high level separation in unity (not even going into the subsystems there)

What you're commenting on and keep saying is easy to port is the very tiny deep blue block, what i keep trying to tell you is, yea, how does that help you port the huge red block and green block (keeping in mind that if they don't have source licences for it, the green block may not even be portable at all, and that i grossly simplified the red block)?

 

Ronan

Finally our heads are sore but yes, it will be possible and I believe Unity should create a WebGL exporter. May it be easy, NO; it will be difficult but it will pay off.

Sorry: Reading between the ones.

CSDG

 

How would it pay off? How many licences do you think they will sell? The market penetration for this is too small i think, considering the investment required i very much doubt they'd do it, the only upside with having done flash before is that actionscript javascript are similar so it should ease the porting but it still is a huge load of work for something which isn't wildly spread.

I just don't see the point really. IMHO they should even drop the flash export instead of adding more options of that kind, i really doubt the flash export will pay for itself

 

Ronan

They will need the Unity Engine to export the HTML5, remember that the WebGL is built into the browser. There are many ways to Obfuscate JavaScript code like https://developers.google.com/closure/compiler/ ... "a tool for making JavaScript download and run faster. It is a true compiler for JavaScript. Instead of compiling from a source language to machine code, it compiles from JavaScript to better JavaScript. It parses your JavaScript, analyzes it, removes dead code and rewrites and minimizes what's left. It also checks syntax, variable references, and types, and warns about common JavaScript pitfalls."

Unity can Obfuscate their subclassed engine and patent the engine as well. By doing this, it will be hard to read but anybody can reverse engineer any type of code.

So thus anyone using Unity Javascript Engine. an engine exported with the HTML5, would need a license to export the "game" from the Unity Compiled Engine as we use today to build games...

CSDG

 

That's not the problem, you keep focusing on the details but that's a second step (but yes, you're pointing a fair point against, this means the source for unity would be downloadable even if it's in optimized JS code). The problem is porting unity "to" javascript to begin with, i think you don't understand how absolutely huge a task this is. And as i said you may not even be able to do it at all for the parts in green in my diagrams if unity doesn't own the source (for exemple if they don't have a source licence to umbra, they won't be able to port it to JS etc). On top of the licensing restrictions it would pose.

I see a host of technical, architectural and legal reasons against doing this, i don't see much market share to gain by doing it, which is why it sounds obvious to me they won't do it. Now they could prove me wrong but i very much doubt that.

 

Ronan

It wont be easy as I said before but from my perspective unity's capital will increase at least 10 times. This does not require incorporating a HTML5 exporter into the present unity technology but an "exporter module" that can by attached later. So don't port unity, START FROM SCRATCH... THIS CAN BE DONE.

Start with:

Code (csharp):

1.  
2. <HTML>
3. <HEAD>
4.       // Code (javascript.js file)
5. </HEAD>
6. <BODY>
7.      // Tags
8. </BODY>
9. </HTML>
10.  

CSDG

 

I'm done feeding the troll lol.

 

The day IE supports webgl, it should be a consideration, not a day before.

I can't believe people are arguing over html5, go make html5 natively if that's what you want, I do, we use it at work and we also use Unity for much cooler stuff that runs much faster.