Thanks all for your comments! Please keep them coming!!
As I mentioned in the blog, we are ONLY thinking about it for now but if you folks have desires / ideas to improve, please use that post. I will gather all the data from there to inform our final decision
Some initial thoughts:
Babylon 8 (the next version then) will start some internal changes to move to a WebGPU first approach. This means mostly to decouple the engines (so far WebGPUEngine inherits from the WebGL engine). That will change nothing from the outside but it will allow us to move to next steps. WebGPUEngine will also be twice smaller
We may want to do the first stage of WebGPU first in Babylon8. This does not mean that we will abandon webGL But for now Babylon is built on top of GLSL shaders that are then transpile at runtime to WGSL when you are using WebGPU. That forces us to download 2MB of Wasm and this is not good. When I mention WebGPU first, what I really mean is that we want to only have WGSL shaders in the repo and compile the GLSL version at build time. So from the user standpoint: no difference. But that will allow us to not depend anymore on Tint to transpile to WGSL
For Babylon X (codename for the version of Babylon that will allow massive breaking changes), here are my personal thoughts:
We will have a military grade conversion documentation that will explain why we do every single breaking changes and how to port your code
Documentation will be updated accordingly. I want to have an archived doc for the previous version and an active doc for Babylon X
Playground NEEDS to be smart. I need to talk with Raanan about that but the idea would be to have a tool that can convert snippet content at load time (with the idea that most of the breaking changes can be automated.) At the very least, I want the PG to add a link to the correct conversion documentation when you load a pg that will break with Babylon X
We may want to start hinting to users during this release cycle that some features are likely to move (with the @deprecated flag) so you can already move code to a more stable path
Regarding size: Iām super interested if you can drop ideas on the other thread because most of the big offenders are a pain to reduce. For instance the math library is a 250KB stuffed baby and I have no clue how to break it apart without making it a pain to use. So feedbac / contribution / ideas are welcome!
RE: the playground, could be a good time to move to web containers to get more control over the whole dev environment in the browser. Would also make it much easier to load in external dependencies .
I think if not doing a compute raster, breaking things wouldnt be worth it imo. Another thing is multidraw indirect and indexable texture arrays aka bindless rendering. Wgpu (not dawn) has bindless capabilities in the native engine you can enable with a feature flag very easily. I think also, if ray tracing is going to be considered, it would actually be more like a 2x rewrite since you dont cull before light info you need the whole scene info.
Here is a video of unreals renderer refactor. Tons of good insight and actually a similarities to their old rendererās draw list and babylons current one. Ive watched it several times.
If it was me, i would approach a breaking rewrite first targeting dawn or wgpu first (wgpu is more managable as a dependency imo) or maybe even just using bjs native. It would be better than godot. However, that would almost mean not developing on the browser for an unforeseen amount of time and integration would be at the whims of apple and i dont think thats what you guys want. Its kind of like, its too early for a rewrite but also not great to do nothing yet. That said, i am all for a breaking rewrite
Im ok with breaking changes but I would really want Babylon 10 to maybe get its own very distinct name.
I donāt particularly care about the backwards compatibility, but I do care about having to field questions from people who are on Babylon 9 and upgrade to 10, and things are all busted and having to constantly have weird back-and-forth on the forums of people to identify what version of Babylon they were using when doing something.
Phaser 3 has this issue, where 3.5.x and 3.6.x have some insane breaking changes but because the names are so similar, and most of the code is the same people go back-and-forth on the forums and on discord quite a lot until they discover that the person that talking to is essentially on a different version.
However, most people would assume a whole version number would have breaking changes anyway, we are honestly quite spoiled in that regard.
Breaking changes happen all around the open source world, but maybe itās possible to maintain something like a ālegacyā version while keeping the mainline version, like the ālongtermā versions of kernel and vue2, the mainline version continues with rolling update, while the ālegacyā version receives minimal maintenance, maybe bug and security fix only.
While doing this, consider a migration layer like jQuery Migrate plugin that do the migration in runtime.
Thanks for your answer but I canāt see the warning in my code and if I use BABYLON.Mesh.Create in the playground, the meshes are shown in the inspector but not visible.
In projects that use semantic versioning (https://semver.org/) it is easy to spot breaking changes for developers, since they only happen on major versions. This is pretty different to babylons current versioning scheme, but might be an option from v10 onwards.
But looking backwards babylonjs does not really have many breaking changes and would be in that sense probably still be on v1
Iām not sure if WebGPU will be the future, personally Iād prefer an ES 3.1 version of WebGL instead but you can use the CL2 technique with WebGL2 to get a lot of the benefits that native apps enjoy, like using thousands of lights/probes/decals wizgrav/cl2: Compute-Less Clustered Lighting (github.com)
Performance first ! And a neat migration guide with some examplesā¦ sounds perfect to me.
Also maybe we could be taking advantage of that big refactor to clean up/harmonize some APIs like RenderingPipelines, PrePass, layers, PostProcesses etcā¦
