Any Advice for Porting Babylon.Js Project to Mobile

Hello, I am developing a voxel engine that uses Babylon.JS.

I got my first issue for the project yesterday:

is DivineVoxelEngine support android and ios

They asked me if I could make a version for mobile. Currently I have only developing the engine inside an electron dev environment and the experience has been sublime. But I know mobile can be a whole separate beast.

Could anyone give me any advice or show me the best tech to use to do this.

For the engine itself it needs things like web workers, shared array buffers, and webgl 2 features like 2d texture array.

I was considering Cordova but seen many complaints about the performance.
I also looked into Babylon.Js React Native but React Native itself does not have those features I need.

Is there any tech that I am not aware of or projects that I could look at?

Thank you!

1 Like

The simplest might be to wrap your code in a webview ? but not sure workers and SABs are available there.

cc @bghgary

Hi thank you for the reply.
I believe cardova is a wrapper for Web View.
But you’re right.
I am just trying to provide an answer for the person requesting the feature.

I feel right now that the tech is not at the point where I could easily do this.
I would have to practically re-write the entire engine in a different language or framework.

But I want to stick with Babylon.

Would be cool if electron made a version for mobile. Cause chrome on mobile supports all of the features I need. So, some type of app wrapped in a mobile chromium instance would be the ideal way.

Babylon React Native might be a good candidate too cc @bghgary and @ryantrem

2 Likes

So, I did kind of think of something.
If React Native has a way to do multi threading and shared memory then I could make a port to it and just use the methods that they do. So, no need for SAB or web workers.
Cause most of the engine exists outside the main thread but it just generates and store data. And most of it is just raw number data for meshes and so on.
The engine itself is does not fully rely on web workers. If there was another way to do multi threading and shared memory then I could port it and just add a few settings to the engine in order to allow for the different mode of inter thread communication.
But that leaves 2d texture arrays. Which are awesome and I hope WebGPU supports them in the future. However, I am not sure if whatever native render library has some type of polly fill or an alternative.

Let me clarify the engine use of SAB. The engine itself does not currently use them (though I do plan to use them very soon). But for the examples I made I used a SAB to pass the player’s position and camera direction to the world data thread. In that thread some math is run to get what voxel the player is looking at and standing on. But I let Babylon handle all collision detection.

In the next few updates I am planning on loading all the needed chunks to a SAB and all entitles/players will exist in their own thread and use SAB to update their rendered representation.

But if I kept babylon.js collision detection and just used postMessage to send the updated player information then it may work without the need for SAB.

AFAIK, React Native doesn’t have official support for web workers. I found this, but it hasn’t been updated in 6 years.

I’m sure we can add this support to Babylon Native if needed.

Perhaps Ionic would work?

With React Native and thus Babylon React Native, you are free to do what you want on the native side, create threads, etc. If you can build the multi-threaded part, in say C++, and compile it for native for React Native and compile for WASM for web, that might work well.

I also noticed in the GitHub thread:

But Babylon.Js Native is only right now for windows and macOS.

Babylon Native supports Windows, macOS, Android, iOS, and Linux. Our documentation is probably a bit out-of-date on this and will be fixed in the coming weeks. Babylon React Native supports iOS, Android, and Windows.

1 Like

Hello and thank you very much for your reply.
I do agree with everything you said here.
Also for react native I found this neat project:
react-native-multithreading
Like if this project was fully supported it would be perfect.

But ultimately I am not a C++ programmer. And if I am going to write C++ plugins I might as well re-write the whole engine in C++ lol. When they ported Minecraft to mobile they re-wrote the whole game in C++. I feel that would be the ultimate solution but at that point it loses all usability and simplicity. So, either I need a “Jeb” or about 5 - 10 years.

What is annoying is the Chrome on Android supports all the features I would need. But Web View uses the native browser on devices. Would practically have to beg Google to release a chromium for android so they could make electron mobile. Or ask them to finally add SAB to their stock Android browser.

So, I told the person who opened the issue that for the time being I am not going to worry about it. I will keep my eye out for new tech and advances and as soon as I can I will port it. Maybe in a year or two something will come along.

The rendering engine itself does not need SAB. But for the physics engine I am planning to build with it , it will need it. So, maybe I should just separate the projects and keep the physics engine as a separate plugin.

But really I just want to build this project and use JavaScript’s full capabilities without worrying about mobile right now.

But thank you all anyway for the help and feed back.

I have a feeling that things will get better in the future and that this tech is just still very fresh and not matured yet. But as soon as it is I will do what I can.

1 Like

I think the best way to do it, is using capacitor. I recently made a tool for compiling HTML5 to a Mobile App (Android and iOS) online. Feel free to use it.

Please read and follow this topic.

Well with the current iteration of the voxel engine I think it may be impossible right now to port it to mobile.
Since it is using Shared Array Buffers and not all web view browsers support that.
What may be possible is generating a scene in the engine of a desktop and loading that scene on a mobile device.
But at this point I am not concerning myself with mobile right now at all.