Comment by SuboptimalEng | Hacker News Reader

Comment by SuboptimalEng | Hacker News Reader

Parent Full thread

Yea, that's what I love about the web. Though I do consider myself to be pretty experienced on the JS side as I've worked with it for a while. I think the main reason I ran into these issues is because I've been trying to use the Web for something that it's not fully built for (graphics programming). And also, it's been a while since I started setting up a new project.

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?

- Okay now I need Tailwind (because quite honestly, I'm terrible at CSS which I admit is my own doing)

- 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 extension

>I've been trying to use the Web for something that it's not fully built for

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

Nice Demo! Definitely agree with the lack of familiarity / tangential aspect comment. IMO your best bet is starting off with vanilla HTML + JS and then adding tooling as required / only if necessary.

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

I don’t really get the “I’ve been trying to use the web for something it isn’t meant to do (graphics programming)” sentiment or the question.

What 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.

Similar to my experience coming from JS into WebGL. I always use a framework (currently Vite + React + TS). It helps keep code organized as your project grows (and it will). I don't think there's any overhead as the GPU processing is independent and React does all its magic on the CPU as far as I'm aware. Typescript errors sometimes come from VSCode and sometimes from the node scripts and I can never seem to get my VSCode TS settings the same as my cli settings so errors will appear in the IDE that my build tools ignore or the build tools will error when the IDE says everything is fine but usually I just use some ignore flag because at the end of the day it's just tangential to what I'm trying to do

I need to do what you did and sit down and make a perfect Vite + React + TS boilerplate that I can use for all my web graphics experiments.

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.

Reply on news.ycombinator.com