why babylon.js if unity export webgl??

[GameMonetize]

evolution of webgl (current version is 1.0) but support is really early so far.

Key points we can use from webgl2: more precise texture format for shadows, completely GPU processed particles, etc...

[JCPalmer]

How about Uniform buffers that are in WebGL 2.0?  This would allow many more than 128 than uniform variables mobile platforms have.  With each bone taking up 4, this causes cpu skinning when you have more than 25ish bones.

Might be faster assigning a single buffer, than 30 uniforms too.

[GameMonetize]

Agree as well!

[NasimiAsl]

back to Post :

BJS  Have ShaderBuilder TOO

[Pryme8]

3 hours ago, NasimiAsl said:

back to Post :

BJS  Have ShaderBuilder TOO

ohh yea! I forgot that, right out the box you can do powerful shaders and post process effects.  Something you have to have Unity pro to even think about. They even block you from using them even if you wrote it yourself.

[away168]

Bablyon.js, Three.js, and any JS frameworks are open and we are able to code with JavaScript directly and extend them, but not Unity and Unreal.

For example, putting a JavaScript code in your gameplay code in Unity and Unreal where the only feature exists in JavaScript is a pain in the ash-tray.
Things like, why use C# or C++ for simple XHR request that is converted to JS when you can just do it easily with JS?
You also easily add a <div> on your JS application to open up a new web layer (for web news, guide, or anything else), when in Unity and Unreal you need to setup a whole new object to display web contents.

The other reason would be some people just want to stick with JavaScript environment. Adding libraries through <script>, load them right away in the web without getting through the builds from Unity or Unreal. It's like Flash in web all over again, and it's not always easy to embed JS codes from web to Flash; so are Unity and Unreal.

These are the things that will never change in the future when you are using Unity or Unreal for web.

Web itself is simple. You can just add chrome engine here and there (Like Crosswalk and Cocoon) or through chrome browser directly, and you can just put your whole JS environment with (almost) no change of code.

[adam]

9 hours ago, alectora said:

but not Unity and Unreal.

To be fair, you can extend Unreal Engine 4.

https://www.unrealengine.com/ue4-on-github

[meteoritool]

+1: When a bug is discovered, it is fixed within a few hours  !
BABYLON.js can evolve and work the way YOU want ! It is still young but very welcome to evolution !

[Entropy_86]

Hi all

Just wanted to drop in to add few words. Babylonjs sounds good, but 

the tools Unity provide outmatch babylonjs. Babylonjs looks to be in babyshoes and if you are trying to create a competitive game 

from scratch... I'm afraid babylonjs falls in short. I looked at the documentation and examples. Features like machine learning

advanced multi threading framework(no webgl support currently at Unity and they are working on it) are missing. But yea you could use babylon js to create anything. 

 

Look at the Unity's  c# jobs system and the 120 000 skinned soldiers they are bombarding with magic and tell if babylon js can achieve similar performance.

Advanced camera tools like intents Unity provide? Scriptable rendering pipelines?  How about vr tools? Downsides of Unity? I think that it's that you have to know what you are doing since not all the goodies are supported on all platforms.

Build size was mentioned too. Webgl is not that greatly supported on Unity, but people who go to Unity usually don't care about that. Not when you need to create high performance desktop vr game of whatever you are developing. Build size can be optimized on Unity and content streamed with the help of asset bundles. You could think of webgl as nice addittion for game development since how many actually plays webgl games purchased on steam?

I think the question more likely is is there are business for webgl games can webgl run it?

All the Best

[Wingnut]

Hiya E86, welcome to the forum.

I think you are talking about 2 different subjects... BabylonJS and webGL. 

On the subject of BJS lib:  Believe it or not, BabylonJS is the fastest webGL framework to be found... because its core programmers are performance junkies.  They LIVE to shave off cycles and remove logjams.  And, they try to farm-out as much as possible... to the GPU, leaving the CPU free for us game/art proggers.  BJS is ahead of the game, but not by much.  Other webGL libraries are right on our tail, perf-wise.

On the subject of webGL/browsers/JS:  BJS is handcuffed by the limitations of the browsers/dom, by sandboxes, by threading models/JS, etc.  ALL the webGL frameworks suffer from these same handcuffs.

Can webGL browsers do games?  You bet.  Can it get insane perf?  You bet, if you follow the (SIMD) rules.  Can webGL scenes be asked/expected to perform similar to machine language/low-level code?  Not a chance.

Unity games are different... you can't run them in a standard browser until they are converted to webGL, right?  (I don't know much about Unity).  A user named @MackeyK24 is spearheading a Unity-to-BJS project, and he is dedicated and motivated beyond belief.  Perhaps he will visit and provide his insights.

Ok, that's my take on it.  Others will comment soon, I'm sure.  Be well, nice to have you here, and you have asked good questions, but you have your subjects blurred together a bit. (that's common and understood/done by all of us)

[Guest]

You cannot compare Unity and Babylon.js as @Wingnut said.

You can compare Unity export for WebGL and Babylon.js though. And with the incredible work done by @MackeyK24 there is no problem to use Unity env to work on your game while exporting to Babylon.js for the final rendering environment

[HoratioHuffnagel]

I have to ask though - I work in a studio that uses both WebGL and Unity - (Unity only for native at the moment) and if you have been watching the recent Unity press releases on 'unity for small devices' - you'll see a massive shift in the way their engine works. Making it's prospects for high performance WebGL export a reality. So once this is released, what value do engines like Babylon offer?

Unity seems to be promising performance improvements, tiny export sizes and a studio quality editor. So now you have a viable pipeline in Unity, with AMAZING tooling, and improved performance... the reason to use standalone 3D engines becomes harder to justify from a commercial point of view.

To me - this is the biggest hurdle for open source engines - how to compete with tooling and asset pipelines like those offered by Unity. Once the performance issue becomes less of an issue, and bundle size is no longer an issue - the evaluation now becomes, performance vs tooling. And most studios, unless they are really pushing the platform, will probably pick tooling. And if you are indie - time is valuable - so again - tooling would likely win out.

[inteja]

I've used Unity for a few projects in the past but, at the time, export to WebGL was buggy and file sizes were monstrous (unjustifiable for web deployment - users wouldn't have the patience to wait). Sure, stability has and will continue to improve but I doubt they'll be able to make a significant dent in the actual engine file size or memory requirements for WebGL deployment, at least not until web assembly is available everywhere.

Having said that, I think there's plenty of room in the market for the likes of Unity, Unreal, Babylon, Three etc, just like Blender can thrive in the face of heavyweights like 3dsmax and Maya (I switched from 3dsmax to Blender myself). Diversity is strength. I've been around long enough to know that defacto commercial monopolies and proprietary technology never last. It's always good to have viable alternatives that leverage open standards.

What I value most about Babylon is the ability to capitalise on the web stack of standard web technologies I'm most familiar with e.g. javascript, typescript, html5, nodejs etc. Tight integration with standard web technologies and rapid prototyping, testing and deployment make a big difference to me. Yes this can be done with Unity to a certain extent, but it's many steps removed and the process is obfuscated by the compiler.

Call me crazy but another thing I like is truly writing once and deploying everywhere. Unity promises this, but as a content author you still need to make allowances and compromises and test, test and retest for every target platform. I know that if I develop with Babylon I don't have to worry so much about platform capabilities because WebGL (version 1 at least) is almost universally supported. It may seem like we're targeting "the lowest common denominator" but sweet baby cheeses have you seen what can be accomplished with WebGL 1 and 2 these days!? I'd argue that if you're aiming to target web deployment then all those extra bells and whistles that Unity and Unreal offer don't matter so much. I like having clearly defined constraints as it forces me to come up with novel solutions.

Anyway, that's just a few random thoughts. At the end of the day you've got to choose what works best for you.

[Guest]

Even if they are fast, small or whatever, they will not generate a 3d engine that you can use inside other JS code.

They will dump a complete ready to use game that you can host on a page. Keep in mind that it will generate webasm code that you can poorly (if possible) interact with from JS.

 

[JCPalmer]

1. Not everything is a game.  While BJS is "tuned" for a game, there are many non-game reasons for a native webGL framework.
2. I saw mobile gaming revenue surpassed other streams last year (cannot remember where).  Current priorities for commercial games is probably going to tie use of Unity Light to how it works for mobile, not dev tools.