Babylon 10 Poll

Announcements
21

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 :slight_smile:

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 :wink:
  • We may want to do the first stage of WebGPU first in Babylon8. This does not mean that we will abandon webGL :slight_smile: 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!

Thanks team!

11 Likes