You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
So far the whole WebGPU thing is just an experiment. In order to determine whether it's an actually viable approach, some of the trickier elements that come "for free" (not really, but that's another story...) in a WebView and especially with BJS should be evaluated:
HTML/CSS based UI: An alternative would be RML, for which I've yet to build a prototype - consider animations, events, blending
Performance evaluation: Rendering a complex scene with many objects, e.g. the old BJS sprite instancing benchmark
Rendering ambient and directional light sources: This may not be too difficult, but who knows... dynamic shadows also, maybe?
Networking via TCP vs WebSockets: Not actually needed if there's no browser involved, but it might be easier to use uws anyway
Particle effects: These might benefit from Compute Shaders, though BJS can also make use of them nowadays (AFAIK)
Skeletal animations: Built into BJS but kind of icky to use (docs have improved though!) - simply pass bone weights to the shader?
Audio: How difficult is it to reproduce the old AudioTrack-based JS API in raw WebAudio (LabAudio, presumably)? Very? No idea.
Multithreading: This the browser can't do, but it's multithreaded itself (and the performance/complexity trade-off is questionable)
I would expect this list to grow as I discover more nasty things. Perhaps it might make sense to also gather the benefits here:
No more JavaScript and Electron/Browser craziness, anywhere. Good riddance, I say, to all the thousands of npm modules
Performance of LuaJIT seems to be higher, although it might be because the old JS code sucked (TypedArrays vs cdata?)
Much simplifies the overall architecture, as there's no more need for microservices just to load files via RPC calls
No dependency on browser engines, at least if WebViews were made optional in the runtime (in favor of WebGPU)
Can actually implement proper testing for more than just the backend (much easier than with electron-mocha etc.)
Can reuse all the code between modules and no need to store data tables as JSON (or duplicate them)
All of the technical debt from the four or so JS/TS versions is just gone - such a rewrite might in this case be a huge win
I will have to learn a lot more of the low-level details, by necessity, which I would consider a win even if I dread certain areas
Obviously, using WebGPU means reinventing many wheels.
But it might still be worth it (and I'm curious to learn more about graphics).
So far the whole WebGPU thing is just an experiment. In order to determine whether it's an actually viable approach, some of the trickier elements that come "for free" (not really, but that's another story...) in a WebView and especially with BJS should be evaluated:
I would expect this list to grow as I discover more nasty things. Perhaps it might make sense to also gather the benefits here:
Obviously, using WebGPU means reinventing many wheels.
But it might still be worth it (and I'm curious to learn more about graphics).