5 ms·

Ah, Javascript-based VR. That's easily five years away from being a pleasant experience with anything but the most modest of scenes. And by then we'll be using

by dleslie 10y ago

Ah, Javascript-based VR. That's easily five years away from being a pleasant experience with anything but the most modest of scenes. And by then we'll be using WebAssembly. It's all well and good, in a sense, so long as your main loop does little more than queue some buffers, shaders and materials before handing over the work to the GPU; but as soon as things become dynamic JS really starts to show its limitations. To wit, I checked out the cannon.js demos and giggled as their examples screamed along at a sweat-inducing 3 fps, showing little more than a small stack of low-resolution spheres failing to tumble to the ground. The machine I'm using isn't a beast by any stretch of the imagination, but this is ludicrously poor performance even for it.

vomitcuddle 10y ago
Definitely not a beast by any stretch of the imagination, as I got smooth 60fps in all the examples with an i7 4790k and GTX 970 on Windows (Chrome).
- dleslie 10y ago
  Hence five years, when that machine is no longer a beast. ;)
  - croon 10y ago
    That computer was a beast 2½ years ago, to be fair, so we're already half way there!
pjmlp 10y ago
WebGL is cool for prototyping shaders without spending time on Android Java/C++ builds. But I am yet to see web pages that are as fluid as the games I have on my devices.
avaer 10y ago
The problem isn't JavaScript, it's singlethreading. If your main loop does little more than queue the drawcalls you're doing it wrong. Web workers work. And ideally your physics engine doesn't live in the browser context, for the same reason you don't draw geometry on your CPU. It's a specialized computation suited for a specialized environment. It's easy enough to run actual native Bullet Gpu-accelerated outside the browser and bus diffs to your renderer. 90FPS in Javascript-based VR is happening today. I'm doing it. I'm nonetheless excited for the optimizations we'll make in the next 5 years, though it has less to do with wasm and more to do with cutting out the fat on the path to the GPU, both at the scene graph and webgl layers.
- azeirah 10y ago
  Do you have some more in-depth information on how to build these high-performance javascript-based VR applications? I work a lot with canvas2D and run into performance problems quite quickly, I'd like to know a bit more about the structure of a highly performant application.
  - avaer 10y ago
    I've been meaning to blog about all of the stuff I'm learning here (doing it fulltime and there's a lot to write). Drop me an email if you want to be added to the mailing list; email in proifile. But quickly re: canvas2D and JS based VR, you really want to keep your textures (canvas) small, and your updates minimal. Texture uploads to the GPU kill you because you have a per-frame bandwidth budget, and with current THREE.js and WebGL that budget is quite low. You also want to avoid some gotchas like y-flipping. This is all going to get better though, with faster WebGL and more intelligent THREE.js optimizations with e.g. subtexture updates [0], which currently require you to know your WebGL hacks and OffscreenCanvas [1], which is a very nice for squeezing things out of the main loop, but isn't yet available in most browsers. As they say the future is already here, it's just not evenly distributed yet. I'm trying to distribute it. [0] https://developer.mozilla.org/en-US/docs/Web/API/WebGLRenderingContext/texSubImage2D https://developer.mozilla.org/en-US/docs/Web/API/WebGLRender... [1] https://developer.mozilla.org/en-US/docs/Web/API/OffscreenCanvas https://developer.mozilla.org/en-US/docs/Web/API/OffscreenCa...
- frozenport 10y ago
  A modern GPU has 720 GB/s of memory throughput. To achieve even a fifth of that in the environment typical of an AAA game titles, you need to efficiently invoke the host ogl drawing commands. Nvidia has some discussion of this in their bindless texture white papers. Essentially, the bind/unbind steps in OGL and similar have started to degrade performance. This is not going to be easy to do in javascript, although VR/4k is not the limiting factor, rather it is the complexity of the scene.
  - avaer 10y ago

by dleslie 10y ago

vomitcuddle 10y ago

Definitely not a beast by any stretch of the imagination, as I got smooth 60fps in all the examples with an i7 4790k and GTX 970 on Windows (Chrome).

dleslie 10y ago
Hence five years, when that machine is no longer a beast. ;)
- croon 10y ago
  That computer was a beast 2½ years ago, to be fair, so we're already half way there!

pjmlp 10y ago

WebGL is cool for prototyping shaders without spending time on Android Java/C++ builds. But I am yet to see web pages that are as fluid as the games I have on my devices.

avaer 10y ago

The problem isn't JavaScript, it's singlethreading. If your main loop does little more than queue the drawcalls you're doing it wrong. Web workers work. And ideally your physics engine doesn't live in the browser context, for the same reason you don't draw geometry on your CPU. It's a specialized computation suited for a specialized environment. It's easy enough to run actual native Bullet Gpu-accelerated outside the browser and bus diffs to your renderer. 90FPS in Javascript-based VR is happening today. I'm doing it. I'm nonetheless excited for the optimizations we'll make in the next 5 years, though it has less to do with wasm and more to do with cutting out the fat on the path to the GPU, both at the scene graph and webgl layers.

azeirah 10y ago
Do you have some more in-depth information on how to build these high-performance javascript-based VR applications? I work a lot with canvas2D and run into performance problems quite quickly, I'd like to know a bit more about the structure of a highly performant application.
- avaer 10y ago
  I've been meaning to blog about all of the stuff I'm learning here (doing it fulltime and there's a lot to write). Drop me an email if you want to be added to the mailing list; email in proifile. But quickly re: canvas2D and JS based VR, you really want to keep your textures (canvas) small, and your updates minimal. Texture uploads to the GPU kill you because you have a per-frame bandwidth budget, and with current THREE.js and WebGL that budget is quite low. You also want to avoid some gotchas like y-flipping. This is all going to get better though, with faster WebGL and more intelligent THREE.js optimizations with e.g. subtexture updates [0], which currently require you to know your WebGL hacks and OffscreenCanvas [1], which is a very nice for squeezing things out of the main loop, but isn't yet available in most browsers. As they say the future is already here, it's just not evenly distributed yet. I'm trying to distribute it. [0] https://developer.mozilla.org/en-US/docs/Web/API/WebGLRenderingContext/texSubImage2D https://developer.mozilla.org/en-US/docs/Web/API/WebGLRender... [1] https://developer.mozilla.org/en-US/docs/Web/API/OffscreenCanvas https://developer.mozilla.org/en-US/docs/Web/API/OffscreenCa...
frozenport 10y ago
A modern GPU has 720 GB/s of memory throughput. To achieve even a fifth of that in the environment typical of an AAA game titles, you need to efficiently invoke the host ogl drawing commands. Nvidia has some discussion of this in their bindless texture white papers. Essentially, the bind/unbind steps in OGL and similar have started to degrade performance. This is not going to be easy to do in javascript, although VR/4k is not the limiting factor, rather it is the complexity of the scene.
- avaer 10y ago