• Content Count

  • Joined

  • Last visited

About Sam82

  • Rank

Profile Information

  • Gender
  • Location
  1. 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?
  2. Wow, that is amazing, thanks! Let me know if I can help from my side
  3. 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!
  4. 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.
  5. 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