Viewing profile — 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 s…

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 pin…

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 …

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 Web…

> 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 al…

Nope, this project is desktop-only

This is a GPU "software" raytracer (i.e. using manual ray-scene intersections and not RTX) written using the WebGPU API that renders glTF scenes. It supports many materials, textur…

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 goo…

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!

Indeed, thanks!

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…

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 …

Adding a whole new language (meaning compiler, packaging, libs, ecosystem) into my engine just for the audio lib which I _wanted_ to implement myself in the first place? No, thanks…