BabylonCpp - A port of Babylon.js to C++

[Sam82]

Hi Babylon.js community,

It is my pleasure to announce BabylonCpp, a port of Babylon.js to C++, facilitating the creation of lightweight, cross-platform 3D games and applications with native performance. This port is a manual translation from the thousands and thousands of lines of Babylon.js TypeScript code into C/C++.

Some history
In 2015, I was looking for an interesting pet project. Due to my interest in 3D and modern C++, I stumbled upon Babylon 3D (C#/native port). I used this project as a starting point for mine and started updating the code with the latest code of Babylon.js. In beginning of 2017 - after a long time of porting, frustration and testing - I decided to publish the code on GitHub. Since then I kept updating the code and adding examples on daily basis.

The Good
TypeScript makes it really easy to port to C/C++ compared to JavaScript. For most parts, it is basically copying the code, updating to the proper syntax and updating the header.

To get a good overview of the current state of the project I refer to the screenshots on the samples page. Not really a surprise, but if you look at the samples code you will see that the API looks very similar to the one of Babylon.js. Not all functionality is supported yet, but this a work in progress.

I am really pleased with the performance of Babylon.js and the speedup of BabylonCpp. I am aware that I am comparing apples and oranges but I can give you some numbers. On my Intel NUC NUC7i5BNHX1 (Intel Iris Plus Graphics 640 GPU) I am getting the following numbers for the relatively simple Grid material example for a resolution 1680x1050 on Fedora 28:

• Babylon.js engine (v3.3.0-rc.3), Firefox 62.0: +/- 15% fluctuating CPU load, 270 MB RAM usage, fluctuating fps between 45-60 fps
• BabylonCpp (library size is 7.6 MB): constant 2% CPU load, 16 MB RAM usage, constant frame rate of 60 fps

Some possible use cases of BabylonCpp include:

• Native apps development on iOS, Android
• Using the library as a WebAssembly module
• Using the library in existing desktop applications or integrating third-party libraries (i.e. Recast & Detour, Bullet Physics engine, etc.)
• Technical exploration (i.e. testing functionality that is in OpenGL and not yet in WebGL, supporting Vulkan API)

The bad
Most of the time goes into keeping up with all the Babylon.js code changes. Every month I take a snapshot of the latest code and port the changes into my version. As a result, the code is always very up-to-date but code on which people are still working or that might be thrown away in later versions is also integrated. An alternative I am going to follow for Babylon.js 3.3 is sticking with the stable version and focus mainly on features and stability. Porting will be done in a branches and less frequently.

Not all code can be easily ported. For instance, C++ does not have reflection. There are third-party libraries available to support this, but this means introducing a new dependency.

...and the Ugly
Linux is my main development platform. The code compiles on Windows (MSVC 2017) and OS X but is not really tested and buggy. On Linux I am also getting different behaviour between the debug and the release version. So the library is for moment only really usable on Linux in debug mode...

Looking forward to hear what you think about the project or where you want to use it. If you have some suggestions for improvement or want to contribute or help resolving some of the issues described above feel free to contact me any time or let them know in this forum, it certainly would help a lot!

Cheers,
Sam

[babbleon]

Hi @Sam82, would this enable me to render stuff on a headless Linux server without a GPU.. or have I missed the point?

[Milton]

That's probably not why he did this 

You can emulate the GPU with. xvfb (+ mesa). You could likely do this with BabylonJS (and a browser), but OpenGL will obviously help.

[babbleon]

Thank you @Milton, I have been able to render successfully on a headless server.. but I'm always interested in anything that will improve speed.

[Guest]

Impressive work!! I hope you'll get some help!!

[Sam82]

Hi  @babbleon, yes you can render on a headless Linux server without a GPU like @Milton explained but this will be emulated so the performance will be not that great compared to rendering on GPU.

I am not aware of any offscreen rendering method that runs very fast on CPU like you want to achieve. In case your headless Linux server has a GPU then looking further into VirtualGL might be interesting.

[dimous]

You know, there was successful attempt to port BJS to Haxe but it seems @gamestudiohx cannot keep up with BJS and stopped trying. He probably got demotivated by Armory3d ?
What I'm getting at is that it's awesome that you ported BJS to C++. Haxe allows to extern native code. We have js-externs, now someone would make hxcpp-externs for your port and babylon projects will become cross-platform with a native speed.

[Sam82]

Hi @dimous, indeed BabylonHx is a very successful attempt to fully port BJS to Haxe. Unfortunately @gamestudiohx stopped improving the project and nobody seems to be taking over...

I can understand why people choose Armory3D for developing games in Haxe (even if it is still in development), it already looks amazing and you have the full blender integration for development.

I cannot comment on how much effort it will be to create the hxcpp-externs for this port, because I have no experience with Haxe . Hopefully someone will look further into supporting this!

[dimous]

That someone would be me if I can master ANTLR StringTemplate, because it's too tedious to handcraft those bindings. I'll definitely try.

[Sam82]

Wow, that is amazing, thanks! Let me know if I can help from my side

[kurhlaa]

Big job done!

How long it took to port from day 0? Github repo is ~2 years old.

Also potentially it will be great if you let developers easily to have server-side without node.js completely, so for the multiplayer games they can use BJS on a client-side and a compilable version on the server-side (physics only). I mean for performance of course. From the comments above I see it's already possible somehow, but that could be a vector to concentrate on to improve server-side performance significantly

[Sam82]

Thanks!

Getting from zero to something very basic (like rendering a cube) took about 7-8 months. I did not work on it full time, only when I had time available.

Yes, that sounds interesting. So you could choose to render to a texture or use OSMesa for software-based off-screen rendering; both focus on the rendering aspect. Running server-side physics calculation is another option, but might be challenging due to network lag. Do you know of any game framework that supports server-side physics?

[kurhlaa]

Server-side physics calculations are necessary for multiplayer games to prevent cheating. Network lag - yes, but that's on a different layer than physics calculations; partly solvable with methods like prediction and correcting of wrong predictions. But that doesn't depend on the framework's language, you can implement server-side in Javascript or even Assembler and still have issues with the network lag  that's just another task.

I'm not very experienced in game frameworks, but most tutorials I see talk about taking a javascript engine, add node.js plus some magic and run in on a server-side, but I still believe javascript is not for the server-side for fast performance games like FPS. So somewhen you could say "hey, I have a C++ project which allows you to run thousands of simultaneous games on a single server".