Spector.js VS threeify

Author of the WebGL volume rendering tutorial [0] you mentioned in the readme here, great work!

Working in WebGL/JS is nice since you can deploy it everywhere, but it can be really hard for graphics programming as you've found because there are very few tools for doing real GPU/graphics debugging for WebGL. The only one I know of is [1], and I've had limited success with it.

WebGPU is a great next step, it provides a modern GPU API (so if you want to learn Metal, DX12, Vulkan, they're more familiar), and modern GPU functionality like storage buffers and compute shaders, not to mention lower overhead and better performance. The WebGPU inspector [2] also looks to provide a GPU profiler/debugger for web that aims to be on par with native options. I just tried it out on a small project I have and it looks really useful. Another benefit of WebGPU is that it maps more clearly to Metal/DX12/Vulkan, so you can use native tools to profile it through Chrome [3].

I think it would be worth learning C++ and a native graphics API, you'll get access to the much more powerful graphics debugging & profiling features provided by native tools (PIX, RenderDoc, Nvidia Nsight, Xcode, etc.) and functionality beyond what even WebGPU exposes.

Personally, I have come "full circle": I started with C++ and OpenGL, then DX12/Vulkan/Metal, then started doing more WebGL/WebGPU and JS/TS to "run everywhere", and now I'm back writing C++ but using WebGL/WebGPU and compiling to WebAssembly to still everywhere (and native for tools).

With WebGPU, you could program in C++ (or Rust) and compile to both native (for access to debuggers and tools), and Wasm (for wide deployment on the web). This is one of the aspects of WebGPU that is most exciting to me. There's a great tutorial on developing WebGPU w/ C++ [4], and a one on using it from JS/TS [5].

[0] https://www.willusher.io/webgl/2019/01/13/volume-rendering-w...

[1] https://spector.babylonjs.com/

[2] https://github.com/brendan-duncan/webgpu_inspector

[3] https://toji.dev/webgpu-profiling/pix

[4] https://eliemichel.github.io/LearnWebGPU/

[5] https://webgpufundamentals.org/

For debugging, spector.js helps sometimes.

If you want to know what the browser supports, webglreport.com will tell you. If you want to know what a specific page is using, https://spector.babylonjs.com/ can probably tell you. Alternatively, you can go into dev tools, select the canvas in the inspector, and run $0.getContext('webgl2') to see if it's webgl2 or not.

I'm actually not sure. Here is the implementation. The extension can capture single frames of WebGL animations, I think it's something to do with getting the timing of that frame (finding its start and end).

As someone who has written math libraries over and over again for the last 25 years (no joke - wrote this in 1997: https://github.com/bhouston/BezierCurveDemo1997/blob/master/... and just recently wrote the Threeify math library: https://github.com/bhouston/threeify/tree/master/packages/ma...), I find that operator overloading works only for the simple cases but that for performance and clarify, function names work best.

Function names let you clarify that it is an outside product or inside product (e.g. there are often different types of adds, multiplies, divides), and I can not stand when someone maps cross product onto ^ or dot product onto something else. Also operator overloading often doesn't make clear memory management, rather it replies on making new objects constantly, where as with function names, you can pass in a parameter that will take the result. Lastly, function names allow you to pass in how to handle various conditions, like non-invertible, NANs, etc.

I find word based function more verbose but significant less error prone and also they are more performant. Operator overloading is only good for very simple code and even then people always push it too far so that I can not understand it.

Fun fact, a lot of it is open source, just not where you would expect it. During the creation of Clara.io I created over 200 PRs to Three.js:

https://github.com/mrdoob/three.js/pulls?q=is%3Apr+author%3A...

The problem with open sourcing it wholesale at this point is a challenge because parts of the tech stack became parts of Threekit.com. Threekit.com is VC funded and an ongoing business operation.

I do what I can with open source still, see:

https://github.com/bhouston/behave-graph

https://github.com/threeify/threeify