Comment Fragmentation Is an Issue (Score 2) 153
Dusting off my old Slashdot login, as I might have something to offer for once. I have an ongoing project which is a 3D walkthrough of Earth history--a virtual museum in which each "step" you take represents a million years. It's been on the back-burner as I wait for clarity on which direction to go, tech-wise (and because of a film). Here are the bullet points:
- All modern browsers support WebGL 1
- It's good, but you'd have a hard time mistaking performance for a native app
- WebGL is very low-level (think 30 lines of code to get a triangle onscreen)
- As such, most developers use frameworks to abstract the drudgery, as with other 3d libraries
- The two big ones are Babylon.js and Three.js, but there are several
- WebGL 2 allows faster exchange of data with the GPU
- It gets you closer to native app performance, but still noticeably below it
- Firefox and Chrome support it, Safari/Webkit does not
- Webkit is skipping straight to WebGL's successor, WebGPU
- WebGPU promises pass-for-native performance
- WebGPU will be supported by all modern browsers, but remains experimental/off by default
- However, WebGPU's shader language seems to be a sticking point in standardization
- WHLSL is source-readable and compiled in-browser
- SPIR-V is semi-compiled, and not human-readable
- Basically, WHLSL is what the web was, SPIR-V is what the web's becoming
- If there's progress on breaking the loggerhead, it's not happening publicly
- Frameworks will abstract most of this, but if you're doing anything interesting you're writing shaders already
- WebGPU offers very tangible benefits, but all your shaders will need to be rewritten
- But into what? And when will WebGPU be ready for production?
- Meantime, we're stuck with either partial browser support or WebGL 1
- It's fine for me, as I'm only doing a spare-time art/education project
- But now imagine you need to make a living off this stack...