I wasn’t able to find a lot of information on this…
Am I understand it correctly that this will do all the BabylonJS math in JavaScript and then call an OpenGL api rather than WebGL, so it’s pretty much still JavaScript doing all the heavy lifting?
What are the advantages to WebGL, will there be any performance improvements?
What will this give me that an Electron wrapper wont? (Except sway back-end friends who hate Electron on principle)
Here the Article on Med does explain a lot.
Yeah I read that one, but besides lowering the memory footprint it did not say much on performance unless I read it wrong.
It’s nice to have less tooling required ofc 
But perhaps there is a bit more info around since March 18 when it was written.
JavaScript doing all the heavy lifting?
Yes, for the business logic (i.e. the code that tells Babylon what to render, etc.). The actual rendering on the graphics API is handled by bgfx which will use DirectX, OpenGL, Vulkan, Metal, etc. depending on the device/platform.
What are the advantages to WebGL, will there be any performance improvements?
If you’re talking about frame rate, it depends on the scene, but probably not significantly if it’s CPU bound (e.g. bound by JavaScript if rendering a bunch of objects). We haven’t done enough profiling to know exactly the characteristics compared to using web browser tech.
What will this give me that an Electron wrapper wont?
As mentioned, memory footprint will be smaller without HTML DOM. You are free to use whatever native UI framework without the overhead of HTML. The package footprint is also likely to be significantly smaller.
I might start looking at this once Android path is actually up. Till then ExoKit is gonna be my path.
I did a couple of PR’s for Exokit, adding some missing WebGL2 wrappers. When I did Occlusion Query, I ran this example. The animation only progresses as the frames are generated, so the faster the animation, the faster the calls are being completed.
Running maiximized to get comparable results, Exokit just screams compared to Chrome & Firefox. This might a good start for eyeballing the relative performance of calls.
I think what other apis you are allowing needs more enumeration. WebAudio, WebXR are a must, but explicitly having what there is & planned would be helpful.
The ability to store local data for saving preferences seems very useful as well. I know it is a departure from a browsers, but this an app from app store. Exokit, I think, found a way to do this.
At this point, we don’t know yet. Babylon Native is not trying to be a browser so we probably won’t be implementing much of the browser APIs. We will only do so where it makes sense.
Hi @bghgary two questions:
What is the target market (XBox, AppStores, other) ?
Is it possible to import jQuery for 2DTXT HybridUI animations?
Because we leverage DOM for comic style bubble txt…
Thanks,
We are planning to support Win32, UWP, Android, MacOS, iOS. Others may come afterwards.
I don’t know what this is, but if it uses HTML, then probably not.
Cool!
Love me some Win32, iOS, and UWP!
We use DOM to overlay 3D with 2D extensively. Leveraging flexbox as a solid responsive layout solution (for our complex dashboards overlays). AND for a rich text animation system that we call 2DTXT. Which is a 2D BOOK (visual novel, captions and cartoon bubbles) that overlay a 3D MOVIE (and GAME). With the HybridUI concept that specifies a UI in both 2D + 3D dimensions. : )
So sounds like no BabylonNative options for my company 
Curious:
How does BabylonNative compare to wrapping BabylonJS in PWA?
Also wondering:
Was BabylonNative’s genesis, an innovation vector from within the team to access untapped processing power, or was it a request from corporate? : )
Thanks,
This is the same answer as above where @schoening asked about Electron. PWA and using Electron is similar. But since you are using HTML DOM, BabylonNative probably won’t help your scenario.
This is outlined in the motivations section in the blog:
What was the motivation?
- Lower the cost of developing and maintaining multiple cross-platform rendering engines
- Increase consistency and conformity of glTF rendering across various products
When you say without HMTL DOM, is document.createElement('script'); going to be possible?
It won’t be supported out of the box. Possible, yes, but it won’t be straight-forward. The app will have to implement the document object, the createElement function, the script element, etc. I would not recommend it.
Hello @bghgary,
With respect, I really like experimentation. And in that collaborative-spirit, have follow-up questions. : )
TLDR: can you explain the 2 guiding principles more please?
What are the “multiple cross-platform rendering engines”? I am not aware.
In your (well written) Medium article you mention, "We want to have open discussions and get some early feedback. Is this useful? Is there something we are missing? " - Babylon Native. What happens if I take a powerful 3D… | by Babylon.js | Medium.
So, here we are! Thank you for the open discussion. : )
How do we calculate lower cost, by adding an environment, and the maintenance of an abstraction layer?
With lots of experience with abstraction layers, back in C++ DLL, and FLEX days, (plus GIS libs).
“API abstraction layers” triggers reflexive red-flag memories of significant maintenance difficulties.
Maybe I’m not the only one.
Can you describe what “conformity of glTF rendering” means?
Does that imply WebGL does not conform to OpenGL enough, or…?
Apologies If I read that wrong.
Also,
How does adding another environment " increase conformity"?
Similarly,
How does an API Abstraction Layer “increase consistency” ?
Was PWA considered an OPTION to “lower cost of maintaining multiple cross-platform rendering engines”?
Or are they different somehow?
My honest hope was that an effort would be put into multi-threading PWA’s (like C++), not putting the JS into the C++ (but ah!).
I dont see how HTML causes “costs”, so I dont see how removing HTML “lowers costs”.
Respectfully,
aFalcon
Thanks,
These are all fair questions and we ask these questions also, so feel free to discuss at will. 
Does that imply WebGL does not conform to OpenGL enough, or…?
Conformity of glTF, not any rendering API. glTF must be rendered consistently (visually and feature parity) or people won’t use it. For example, the 3D commerce group from Khronos has been talking to the 3D formats group about visual consistency for the retail scenarios. Microsoft has multiple engines rendering glTF in different ways in different products (e.g. Office, Office 365, 3D Viewer, etc.). We want them to be more consistent.
I think the other questions stem from this? It’s not about the conformity of rendering APIs but the conformity of glTF. We try to make Babylon.js load glTF as best it possibly can. We maintain the glTF-Asset-Generator for Khronos for unit tests and join the Khronos 3D formats working group to discuss the spec and new extensions. With Babylon Native, we can take advantage of the glTF loader and also Babylon.js itself. When new glTF extensions are introduced, we will only need to write the code once.
PWA is an option. It can be the right option depending on the scenario. This is still an open discussion at this point.
Let me know if I’ve missed answering something.
EDIT:
I guess I didn’t answer the HTML part. Some people don’t want to use HTML. They want to use their own UI. For example, if you are in an XR device, HTML doesn’t currently provide you anything. There is also the performance of HTML (memory, rendering, etc.) to consider.