Here is a demo with FPS counter: Wave Equation (as you saw in the other article you found, AssemblyScript is comparable to Clang and Emscripten).
AssemblyScript is using WebAssembly/binaryen
ās optimization pipeline (by Alan Zakai, same person who made Emscripten).
That may be one way to do it, but Iām aiming for a great end-developer experience (everything being in a single easy-to-use language like AssemblyScript).
Bullet (Ammo) in Three.js is a black box, and developers can not simply fork it and update things they need (for sake of example imagine someone needs to customize something in Bullet).
With a simple system in place for all code (f.e. AssemblyScript), the end user can easily fork any part of the code, and even be more likely to make contributions back to the project.
Replacing hot paths might be āenoughā, but I donāt think it will lead to the developer experience that Iām imagining.
AssemblyScript now supports threads. The WebAssembly GC spec will give us the ability to reference āhost objectsā such as DOM and JS objects inside WASM is underway (this includes WASM modules directly importing ES Modules, and vice versa). With these advancements weāll be able to make optimizations by avoiding the current cost of WASM-JS communication needed to access a canvas, and by placing different parts of the system on separate threads ( ), all while maintaining a developer experience that web developers are familiar with.
AssemblyScript is simply easy to use and it works great with existing TypeScript tooling (VS Code Intellisense, Prettier, ESLint, Webpack, etc) as long as we donāt use the few features that are AS-specific, which is what weāre doing in glas.
This is a possibility. If we did this, Iād want to port the tool over to AS too, with the goal of having everything in the single-language and with the best end-dev experience.
This is true, but in Firefox theyāve already made huge improvements:
Calls between JavaScript and WebAssembly are finally fast
The WebAssembly GC features I linked above will allow us to totally bypass this problem when that comes out.
Yep! So the design in glas will be that all code runs in WASM (all code is AssemblyScript), and for every frame the WASM module will send the JS a single command queue with a single WASM-JS call, to minimize this issue for the time being.
If we were to replace only various hot paths with WASM, this would mean weād need to call into WASM multiple times.
Interesting! Thanks for pointing that out. In glas weāre using only top-level classes and keeping it simple like Three.js (weāre not changing the structure except as needed to make it work in AS).
Nice! Thanks! Thatāll come in handy once we get to WebGLRenderer.
This is true! It probably depends on the specific application (f.e. @looeeeās scene is more CPU heavy on his laptop, and use of a lot of physics would increase CPU, etc).
At work, one of the bottlenecks we have is rendering many of the same thing, and each individual mesh causes one expensive GPU call.
I have some plans with InstancedMesh
to reduce the number of GPU calls by automatically instancing meshes in a subtree, so that we can use the scene graph tree the way we do now (organizing transforms in a hierarchy) instead of having to manage separate lists of instanced objects (this is spread across two issues, sorry):
Iāve imagined how to do it, I just need to implement it.
You can try to measure CPU/GPU load by yourself with this tool.
Niiiiiiiice! Thanks! Thatās neat!
On a different note, WebAssembly can be compiled to native assembly which means that eventually we can have an OpenGL ES target, not just a WebGL target. Here are some tools to do that:
I guess Iām ambitious.
Plus, if they already have big applications written in JS, and they have business needs, they perhaps donāt want to afford the cost.
But in my case, Iām doing it for free, becauseā¦ hack yeah !
Because, it takes time and effort. Most people want to use what exists to make products. Most businesses use what exists so they can make money, not so they can invent a free tool that no one will pay them for. This is why, despite that WebGL is now in every browser, big companies still use 2D HTML for UIs, and no big companies write WebGL UI because they donāt need to, and game companies use existing native tech for games, because they donāt need to port to WebGL (and some tools compile to WebGL). When you look at business needs, this all makes sense.
When people take passion, and put business needs aside, then the best things come forward; things like Three.js, AssemblyScript, NeoVim text editor, and many other free projects that business-oriented organizations are less likely to create.
And then, once those amazing free projects are released into the wild, suddenly businesses realize they can use these tools for their own profit. Many companies started using Three.js, for example, but no companies wrote their own engine because, they didnāt need to. Theyāve started using AssemblyScript, because they see its potential after its creation.
Well, companies donāt start using NeoVim, thatāll always be from passion for passion. But Before NeoVim, no company was willing to make a next-generation version of Vim. And before Vim, no company was willing to make a next-generation version of Vi.
Look at Linux.
True innovation often comes from the non-business side of things, where true passion can be found.