I recently tried Metal a bit. Some features are only available for visionOS (the headset) and not iOS or macOS and vice versa.
Here are some questions that came up:
- Do I use Next.js or Vite.js or CRA (is that still used these days)
- With Vite.js do I pick React or go with TypeScript template?
- But what if I don't want to write GLSL files in raw text, and use GLSL file extension?
- Oh now you want to import GLSL files directly, well you can't do that
- Oh, I needed to install a Vite plugin but then TS throws errors saying it can't read files that end with .glsl
- Wait is my TS server running? No, I thought this always starts up in VS Code
- Okay so I can't even find the button to restart TS server, so now I need to... okay figured that out
- That still didn't fix it the TS errors
- After some more research, ah so you can import text files like this a.glsl?raw extensionWhat you have produced is wonderful, but has nothing to do with the web. That’s like comparing apples and oranges.
The web was built for images. All the glsl you have is rendering to that image. Cpp or whatever, your problem domain is pixel shader. A program, run on a gpu, for a single pixel and ray marching through a dataset on also on a gpu. It’s a hardware problem why debugging is so hard. Unfortunately, this is the reality of graphics programming in general.
Vite, React, Typescript, etc etc are all faff exterior to what you are doing.
If you want debugging tools and a good graphics programming experience, and a simple view with some interactivity something like Unitt, Godot, TouchDesigner or if you want lower level, OpenFrameworks, Processing, etc. would be leaner.
sounds exactly like every other dev pushing JS libraries. that's not necessarily a bad thing, but it does get messy on the bleeding edge of things
Also, your project, Shademap, is really cool btw! I remember seeing it just around the time I was getting into Three.js and graphics programming - well before the time I fully understood what a shader was.
E.g. Vite is handy for bootstrapping and hot reloading (don't really need it for build anymore given remote imports, etc). Do you really need typescript? If it saves you time in the long-term, sure add it in (it requires a build step). If you are building a big UI then OK - add a CSS / JS framework. But best bet is always to keep complexity down to a minimum. Last thing you want to be doing is debugging / working around peculiarities of other people's code.
I tend to demo in a single HTML file (you can even embed your shaders in the HTLML!), which can then be easily shared / hosted.
On the demo. Not sure if you referenced it, but I remember being wowed by a similar (official) demo back when Three was first rolling out WebGL2 support. The first commit I could find was 2018, but I'm sure it was actually earlier than that - might even have been a pre-release demo (I'm certain cross browser support wasn't there when I tried it).
https://threejs.org/examples/webgl2_materials_texture3d.html
They used the "NRRD" format, which I haven't heard of (but sounds pretty close to your 1x1x1 raw files ... x-array style thing). Did you look at this approach? Have things moved on since?
Edit: maybe the real tutorial here is around pre-processing of common volume data formats for use with e.g. three / webgl2