Draedon

Implemented the Next Event Estimation (NEE) algorithm. If you look at the previous devlog, you'll see how it's super dark and relatively noisy, as it's pretty rare for a random ray to hit the light. What NEE does is in addition to shooting out a ray on every intersection (simulation bouncing), it also shoots out another ray at a random light source. This brightens the scene a little and reduces noise as it's proactively seeking out the lights instead of waiting for a ray to randomly hit one. Or at least, it's meant to reduce noise, but it doesn't really do that here. I'm almost certain that my implementation is a little broken.

Lighting, finally. Lighting should've been a quick implementation, but it required me to completely change the material system. Honestly, I should've done that ages ago, since previously, all objects simply had a colour attached to it. But now, they have a material index, which points to a material in a materials array, passed to the GPU. Also fixed many bugs along the way, such as normals facing the wrong way for planes, sometimes. Finally, I changed the scene to the famous Cornell Box.

Made the rendering loop progressive. I already gave a brief explanation of what that is, but basically, before, 30 rays were being shot out per pixel, per frame. But since that's really expensive, it now shoots only 1 ray, but accumulates the results across frames to effectively increase the frame rate. Now, instead of the <4 fps, I'm getting 80-100fps, although it does take longer for the image to converge. There's also the issue of floating-point precision issues, but I'm mostly avoiding that by limiting the number of rerenders.

Implemented rendering of quads. Even though the entire point of this project was for me to learn the maths behind path tracing, I don't think I want to learn the entire derivation behind ray-quad intersections. Fortunately, quads are just a general 2d primitive and it's really easy to change it to other 2d shapes, most notable of which being the triangle. But on the flip side, with 30 samples per pixel at a screen resolution of 1920x1080, I'm getting below 4fps. Next up is probably progressive path tracing (rendering one sample per frame and averaging the result with the last frame). If that isn't enough, then I'll have to optimise properly.

Added some basic performance metrics. These include the time per frame spent on the GPU ONLY, and the fps as calculated by 1/frameTime. These aren't super useful now but will come in handy later, when I start optimising. As you can see from the screenshot, with 30 samples per pixel, my crappy laptop is struggling to reach even 40fps on 1920x1080. But to be fair, over 62 million rays are being shot out per frame.

Shading is now ray traced! Currently, it just uses a basic Lambertian BRDF to determine how the rays bounce. Also took the the time to add in anti-aliasing (currently at 30 samples per pixel) and gamma correction (gamma = 1.5). Gamma right now is hardcoded because I can't be bothered making and binding another buffer.

Implemented some ray traced spheres. Don't get me wrong - rays are being shot into the scene and there is maths calculating the nearest collision, but the lighting isn't ray traced at all, but rather, just computed with a basic diffuse model, where the sphere's colour is multiplied by the dot product of the the surface normal and the light direction. Even though the shading technically isn't ray tracing, it was still useful to implement as proof that my surface normals are correct.

Technically have some actual ray tracing now! Rays are being shot out of the camera into the (empty) scene and returning the sky colour, which is a gradient depending on the vertical direction of the ray. Already ran into so many bugs though, including my worst nightmare: memory alignment issues in the shader. Next up is adding some spheres into the scene

Here we go. The start of my second path tracer. Not much to say about this first devlog. All that's happened is a boilerplate really. A framebuffer rendered to by a compute shader, which is displayed to the screen. People familiar with computer graphics will recognise the classic UV gradient that's being rendered.

Added horizontal displacement vectors! How the simulation worked before is that it calculates the height of every vertex in the mesh and moves them up and down accordingly, but you can see that it looks almost static. However, if we move all the vertices horizontally a little bit too, it looks far better. Normals still broken though.

Not much of an update this time. Just changed the skybox texture and updated the README to include all my references for the project. Normals are still broken because I haven't gotten around to fixing those yet. Unfortunately, I'm going to be busy for around two weeks so not much work (if any) will happen in that time.

Massive improvement boost and basic code clean up. This pushed my performance from around 30fps to >60fps. Honestly, I'm not sure how it was this much of an improvement. All I really did in terms for performance was implement workgroup sizes across all my compute shaders

Hacked in some half-broken normals according to various papers. At first glance, it seems to work fine, until you look into the vertex shader and see that the slope vector is multiplied by some arbitrary value of 20. Basically, the shape of the slopes in my texture holding them looks fine, but they're ridiculously small. Probably because in the final phase of the ifft, it normalises every value, dividing them by the square of the texture size. And my texture size? 512x512. So every value is smaller by a factor of 512*512=262144. Yeah. No idea how to fix that properly.

I can't believe it took me that long to find the bug. It wasn't in the wave spectra or the IFFT algorithm, which I spent hours inspecting, but the random number generator. And I should've fixed this ages ago, considering that my old height map wasn't complete nonsense, which would've happened if either of those were broken. Tessendorf's paper literally says that different random number distributions will result in different stylised waves, which hinted at my broken random number generator. And the bug was in my method of preventing division by 0.

The final step of the gaussian random number distribution was to return v/u, and my check for u was to set it to 0.0001 if its absolute value was less than that, which definitely skewed my result. The fix? Just discard it and try again if abs(u) is less than some threshold.

Now I can finally start coding the interesting things, like accurate normals, wave caustics, sea foam, subsurface scattering, and all the other pretty things I haven't gotten to yet

IFFT still not working, but I took a slight detour to put in some finite difference normals, which suck. I'll probably implement exact normals with more IFFTs and then fix the waves properly. Not sure if it's the IFFT algorithm which is broken (I swear it's correct but idk) or my wave spectra

Spent ages on the ifft algorithm, and it half works. Basically, it's giving some values (which kind of make sense but don't). Better than having it completely broken at least

This isn't really a devlog, but I thought that I should mention it. This took a lot longer than 3 hours to make, and majority of it was made before the Summer of Making. I just used this time to clean up the code and make it look good.

Spent far too long implementing the ifft from Jerry Tessendorf's Simulating Ocean Water paper. And the funny thing is, it's still broken, I'm still using an idft instead of ifft, and I don't know what's wrong

Honestly, most of the maths is flying over my head. Simulating Ocean Water by Jerry Tessendorf isn't making much sense to me. It defines the Wave Spectrum as a function which takes in a 2d vector, but all the spectra I can find online (even the Phillips spectrum in the paper) just takes in a frequency. This is going to take me a lot of reading to figure out

Wasted hours trying to get an ifft algorithm...
All that hard work and all I have right now is a half-baked random number generator
Here we go...

Just a really quick settings tweak and loading screen. Made the ocean mesh 10x bigger without increasing the number of vertices, which didn't seem to affect the quality. Hopefully the other small tweaks made it looks a little bit more like an ocean. Fine-tuning the settings was a pain so I might make a little configuration panel sometime.

Skybox and Fresnel reflections implemented! Water now looks a lot better, but still looks like plastic/acrylic. Not quite sure how to fix that though. I wish I could have a skybox with a slightly brighter sky though

Did the code clean-up. Honestly surprised that it didn't take too long, and there were surprisingly few changes. Not complaining. But did implement a browser popup which would happen in any errors were thrown

Added a skybox to replace the boring black background! As much as I'd love to make it look even nicer with stuff like reflections of the skybox on the water, the code is such a mess from trying to hack together the skybox that I'll definitely have to spend an hour or so just cleaning it up.

Finally added specular highlights to the water! Instead of making it look better and more realistic, it just made it look even more like plastic. Maybe I'll turn down the shininess coefficient in the shader and apply Fresnel Reflections later.

Just some typical code clean-up and optimisation. Nothing much. But for some reason, the waves changed a little bit. Not catastrophic; just different. I wonder when I'll deal with the tiling issues. Not now, because there are more important things to do, like Specular Reflections and making the environment look nice.

Waves actually look okay now. Fixed the incorrect lighting direction and implemented a fBm (Fractional Brownian Motion) thing to the waves, which decreases how much influence the later waves have. This adds finer details to the waves and increasing the number of waves won't make the ocean look like Miller's Planet.

Lighting! Took long enough to get here. It was hard enough looking at flat colours on my screen and trying to figure out if it was working. Also, the purple is finally replaced with a more ocean-like colour, blue.

Just some general code clean-up. Most notable of which was actually splitting the shader into multiple .wgsl files and concatenating them at runtime. Honestly not sure why I didn't do this earlier, when the functionality was already built-in to the Shader class.

Got some basic wave moment! Currently it's using the Sum of Sines approximation proposed by GPU Gems 1, with 3 randomly generated waves. Without lighting, it's a bit hard to see the waves, but that will be fixed soon™

Subdivided the initial square. That's it. It will be used later though :)

I lied. Camera movement is NOT a silent update! Got some basic movement and camera rotation in place, which should make debugging incorrect meshes later on easier. And it's just cool being able to explore the world.

Added a basic perspective camera! No input handling yet, but that might be a silent update. Also changed the square colour to purple. Finally don't have to look at that ugly yellow!

Basic square rendering! Well, it's not actually a square because its size is dependent on the aspect ratio, but it's a start. Pretty much just a WebGPU boilerplate with a little bit of abstraction. Honestly, I'm not sure why I made the square yellow. Yellow sucks.

Fully styled now, with not-default buttons and sliders. Responsive design added to. This might be the last devlog before it's ready for release!!!

Basic styling 1. Added some very basic colours and styling to the project