lisyarus

Hi! Blog post author here. I have heard the "Computer Graphics from Scratch" book before, but I haven't read it myself, so it would be quite hard for me to plagiarize it. I guess some similarities are expected when talking about a well-established topic.

Yep, it literally says that in the article

Amazing resource, thank you!

Amazing!

Yeah I've seen it, no worries! :)

Very cool! Based on the video you're also doing some hierarchical subdivisions?

It's true that it makes it more complicated on the GPU side in general, but specifically in this scenario everything works out just fine, mostly because all updates effectively ping-pong between flow & water height buffers, and you never change both in the same kernel.

Interesting, thanks! Is it kinda like the Gibbs phenomenon?

It's not as much about experience as it is about trade-offs. I've worked a lot with Vulkan and it's an incredible API, but when you're working alone and you don't have the goal of squeezing 250% performance out of your GPU on dozens of different GPU architectures, your performance becomes pretty much independent of a specific graphics API (unless your API doesn't support some stuff like multi-draw-indirect, etc).

See my answer to artemonster above.

I'm using WebGPU as a nice modern graphics API that is at the same time much more user-friendly and easier to use compared to e.g. Vulkan. I'm using a desktop implementation of WebGPU called wgpu, via it's C bindings called wgpu-native.

My browser doesn't support WebGPU properly yet, so I don't really care about running this thing in browser.

> It's a mega-kernel, so you'll get poor occupancy past the first bounce

Sure! If you look into the to-do list, there's a "wavefront path tracer" entry :)

> new origin should be along the reflected ray

I've found that doing it the way I'm doing it works better for preventing self-intersections. Might be worth investigating, though.

Nope, this project is desktop-only

Joker_vD obviously talks about the far plane, not the near plane

Yep, I've seen this problem when testing locally on chrome, but I've no idea what that is. Reloading the page usually works.

I will cover triangle clipping in part 5, and it's much less scary than it seems to be!

That's for efficiency reasons: most streams have way more logic than just filling the array, which can hardly be represented in terms of "getting the next value", and loops are good for optimization by compiler, etc. In fact, the actual sine wave implementation looks exactly the way you describe: it handles a generating function to a helper class that just fills the array https://bitbucket.org/lisyarus/psemek/src/master/libs/audio/...

True! But also my use case it quite different compared to GStreamer, and I don't really need all that metadata & introspection.

It pretty much may be!

std::vector would definitely be the wrong choice, since I typically want to pass random subsections of random arrays to be filled by audio samples. std::span would be a good choice, though (I actually have my own span in the engine, from before C++20). Why didn't I use it? No idea, just didn't come to my mind. Guess it might be the influence of the book I was reading, or of SDL_Mixer interface, etc. I may do some refactoring in the future and use spans instead.

The alternative that my older code used was int16, and it has way bigger precision issues (32-bit float has 23 bits of precision, and in16 has 15). Fundamentally audio samples are just numbers; the fact that they have to be in the [-1..1] range in the end is a hardware technical limitation (the speakers' membranes can only vibrate so much), but there's nothing in the audio itself that says it should be constrained to some range. So, floating-points are a nice fit. Fixed-point math like 16.16 might be a good alternative, but floats have hardware support, so here we go.