Ok, I must admit that the objective of the title is to catch attention, but I do sincerely believe that BabylonJS has a good shot at that title!
That being said, I wanted to list what would be some of the characteristics that, using currently available web technologies (so WebGPU is put on the sidelines for the moment), I think would be part of such an engine:
- The API of the engine is accessible for the main thread and is simple to use.
- The CPU usage of the main thread is left to the user and used as little as possible by the Engine.
- The available web technologies are used to the maximum of their capacity to make the Engine as performant as possible while shielding the user from their inherent complexity.
I think that by its nature, a 3d engine should not run on the main thread (CPU intensive…).
BJS is pretty good at respecting requirement 1. and 3. and I think has a good start for 2. with the offscreen canvas, but unfortunately the usage of the offscreen canvas does not meet 1. and 3.
offscreenCanvas clearly demonstrates the power of webworkers but at the same time says:
The main caveat of using Babylon.js with an offscreen canvas in a worker thread is that you will need to do special work to communicate with the engine from the main thread. You will have to use the same messaging API we used before to communicate between threads.
The reality is that WebWorkers are inherently hard to use well and the technologies to make them useful is complex (messaging, sharedworkers, sharedarraybuffers, etc.), although some tools like ComLink(GitHub - GoogleChromeLabs/comlink: Comlink makes WebWorkers enjoyable.) can make life easier. So a lot of casual web developers don’t have easily access to using this technology (you likely need a team of dev or lots of time on your hands…).
It would be great if BJS could have a special engine mode that fully handles the webworkers and the messaging associated to them and present a simple API to the users. That way web users could benefit from a great 3d engine without having to fall in the complexity of webworkers, respecting points 1, 2, and 3 that I mentioned.
A good first step could be to have a playground option that makes the code execute inside a webworker using an offscreen canvas and make parts of the API gradually supported by that webworker playground. And then eventually finding a clean way to make it directly accessible to users. (a good stackoverflow on this)
Of course WebXR support would be a must!
Oculus Quest, 1 & 2 and Hololens 2, are mobile technologies and WebWorker are especially useful in there. These technologies are mobile but at the same time are the ones making the most use of 3D, covering the full vision of the user. So a web 3d engine working at maximum capacity would be incredible, and I think BabylonJS is the best candidate!
I know this is a hard a complex feature to do well, but if somebody can pull it off, the BJS team is the one I bet on!