Implemented SDF-based font rendering for my "offline shadertoy", so that I can read console output directly in the program. I wrote a blog post about it.
https://unlitart.com/Blog/#Offline%20Shadertoy:%20Console%20Output%20in%20App%20and%20Font%20Rendering

I'm now using my static site generator to generate my CV. Had to implement support for multiple inputs in order to make it work. Further details on my blog.
https://unlitart.com/Blog/#Using%20the%20Static%20Site%20Generator%20to%20Generate%20My%20CV

&learningjam2024
Back on the PBR demo. Went off a tangent and implemented my own local "Shadertoy", so that I can use my preferred text editor without having to do additional copy-pasting. I've written a blog post about it.
https://unlitart.com/Blog/#PBR%20Demo%20WIP%20and%20Writing%20Offline%20Shadertoy

Finally I've released my new website!
It was made using my own handmade static site generator, a project that has grown to the extent that I'm almost considering registering it.
More information can be found in the showcase, linked below. There's also a blog post.
https://unlitart.com/Tech/#Static%20Site%20Generator
https://unlitart.com

&luggen-astro
7th and final day of the Wheel Reinvention Jam 2024.

Most of the day was spent on memory allocation and introducing more particles.
The particle allocator (linked free-list) was fragmenting a lot so I ended up re-implementing most of it.

Particles was the main goal of the day. I had difficulties coming up with a scheme that allowed parenting emitters to ships (trail effect). In the end I just wrote something that works without introducing any entity systems or what have you, which I'm glad for.

Somewhere around midnight I realized that packing the emitter array was causing bugs due to them now being referenced by "entities", so I had to implement a pool allocator. The packed array is still in use for iteration purposes but now it's an array of pointers to the pool data.

Green blocks show available particle memory. Orange blocks show available emitters.

What can I say? This jam was great. I feel like I've passed some sort of milestone. Big thanks to the Handmade team for organizing this! While I didn't quite reach my my goal of making a complete game loop I now have a foundation to work from. And some parts of the code will see their way into other projects.
It's almost 4 am now. Good night!

&luggen-astro
Day Six.
Made quite some progress today. I ditched the scene hierarchy since I realized I could do deferred removal with packed arrays anyway as long as I sort the indices (or pointers in my case).
The main feature of the day was code compression, introducing callbacks and making "entities" data driven so that now, for instance, emitters can run different particle "systems" based on profile selection.
And finally, enemies can now shoot and kill the player. It's almost starting to look like a game!

&luggen-astro
Day five.
Implemented a scene-hierarchy of sorts. Currently only used as a linked list for enemies since I needed to defer their deletion. Other types of entities are still in packed arrays but I anticipate at least some of them having to be part of the hierarchy eventually.
On a more fun note, the game now has particles! I'm going with the usual emitter-object scheme. Each emitter is assigned a buffer of packed particles of variable size, for which I had to write a new allocator. In general I'm sticking to arenas whenever possible.

&luggen-astro
Day four.
I required circles for debugging purposes so I went a ahead and implemented my very first sine and cosine functions. I don't know how the pros do it, but I wrote a program that generates a lookup-table spanning one quadrant of the unit circle. Then the functions themselves are just converting the supplied scalar to an index, and determines the sign of the value being read.
After that, refreshed my memory on the Minkowski difference and GJK algorithm. Current collision detection is just basic circle overlap test without taking movement into account.
https://caseymuratori.com/blog_0003

&luggen-astro
Third day of Wheel Reinvention Jam 2024.
Besides addressing some bugs in the shader code generator, most of the day I've been slowly building up the game state update routine and rendering pipeline. Entities are all instanced in one draw call. I was intending on textured quads but the triangles will have to do for now. The next major issue is going to be collision detection.

&luggen-astro
Second day of Wheel Reinvention Jam 2024.
Spent most of the day implementing the shader code generator, since I use my own flavor of glsl and also require include preprocessing.
After that I kept adding to the OpenGL wrapper and now I finally got the "hello world" triangle!
From here on I expect progress to ramp up.

&luggen-astro
First day of Wheel Reinvention Jam 2024.
So far I've only got the barest minimum to get a window with OpenGL context going, along with string formatting and other utilities. I decided to start completely from nothing, using previous code only as reference.

&learningjam2024
As an optimization I incorporated some ray tracing into the ray marching routine.
First we trace a bounding box covering the objects and also trace the ground plane. If we miss the box then there's no need to ray march anything and the results of the plane trace is returned.
In the case of a box hit, the ray march will commence from the entry point until minimum distance or the exit point has been reached. In the case of the latter, the plane trace is returned as well.

Unsure about the performance gain. In standard Shadertoy editor mode it seems to be over 10% (according to Psensor readout) but less than that in full screen. At the very least I got a clean trace of the ground plane now.

&learningjam2024
So I managed to implement raytracing (in Shadertoy). Gets expensive really fast but I'm quite pleased by the results. Rough materials are still too noisy, and I think the low sample count plays the major part unfortunately.
Sampling 4 times per sub pixel, sample count is halved for each bounce, 2x2 AA and 2 bounces. Last bounce always samples the environment light.

&learningjam2024
Seems like I've addressed the bugs I had. Also found an updated version of the paper about sampling the microfacet normal.
https://jcgt.org/published/0007/04/01/paper.pdf
Currently doing 8 samples per sub-pixel with 2x2 MSAA which effectively makes it 32 samples per pixel. The variance on rough materials are too high for my liking but seems like it could be improved with a more sensible lighting scheme.

&learningjam2024
Making progress! All the pieces in place and more or less working.
Next I'll be investigating the black spots that are most apparent in low roughness materials. Also reflections are scaled up a lot on low roughness flat surfaces (like the floor). I suspect that my sampling is biased in some way.

(The funky environment light is for testing purposes)

Found a very good introductory blog post about importance sampling that cleared up some confusion I had.
https://patapom.com/blog/Math/ImportanceSampling/

Also found a newer paper going into further detail about the sampling scheme I'm using. Haven't read it yet.
https://jcgt.org/published/0007/04/01/paper.pdf

Currently sampling 32 times per pixel.

&learningjam2024
Here's the demo in its current state, still using direct lighting.

&learningjam2024
PBR demo is taking its sweet time cause I decided that I wanted to reflect the environment (just some procedural sky sphere for now) thus needed to learn about importance sampling, so most of the time dedicated to this project has been spent reading a bunch, again. It's been the most difficult subject so far for various reasons but things are starting to converge in my mind.
Tonight I wrote a program to test a function for generating micro-normals as presented in this paper: https://hal.science/hal-01509746/document
Seems to be working. Next is to get the other parts of the routine working.

!til &learningjam2024
Just finished processing this paper. I found it very informative but also hard to follow since the math notation made the equations look the same. My notes are basically a condensed version of the whole text, including all the 131 equations of which I'll review and color code the variables.
https://jcgt.org/published/0003/02/03/paper.pdf

&learningjam2024
Recently finished reading through the paper [PM] I mentioned in my last post. It certainly clarified some things and my summary has some inaccuracies in it.
Until I get around to address that I'd like to mention that equation (3), which I got from the Disney paper [DS], also has to be multiplied with a "normalization" term which is shown at the top of page 25 (eq. 3, the left fraction on the right side). This wasn't made clear to me until it was mentioned in [PM].
This is my usual experience with reading papers of this kind. Often I need multiple sources in order to fill in the gaps of my understanding.

Testing in my Shadertoy demo, the specular highlight (D-term) now behaves more or less as I would expect. Still got aliasing at the penumbra which appears to be due to the G-term (which handles micro facet shadowing), so that's what I'll be working on next.

!til &learningjam2024 Linking to the paper I mentioned in the recap stream. The best resource on the subject I've found so far.
https://blog.selfshadow.com/publications/s2013-shading-course/hoffman/s2013_pbs_physics_math_notes.pdf

!til &learningjam2024 Got started on implementing a material demo in Shadertoy but had to realize that it's going to take its time, so a brief summary will have to suffice. I've put it up for download on my site.
https://unlitart.com/download/HMN_LearningJam2024_BRDF_Summary.pdf
Big thanks to the HMN team for arranging this event. To be honest the concept didn't excite me too much when it was announced but it turned out to be a great opportunity to check off something from the mental bucket list.

!til #learningjam2024 Moving on to this paper:
https://graphics.pixar.com/library/PhysicallyBasedLighting/paper.pdf
Surprised that raytracing wasn't the norm at Pixar in 2013. Interesting to note that both Disney and Pixar (same company at the time I guess) had to rewrite their rendering/shading pipeline since the legacy one had become overly complex, replacing their shading models with physically based ones because they where better in every aspect both from an artistic and production point of view. Needless to say, this rhymes with the handmade ethos.

!til &learningjam2024 Currently reading through this paper.
https://media.disneyanimation.com/uploads/production/publication_asset/48/asset/s2012_pbs_disney_brdf_notes_v3.pdf
The scope has shifted from understanding BRDF's to learn about material models based on the micro facet model, which are nowadays commonly employed in both games and films, what is usualy referred to as "physically based".
As mentioned before, BRDF simply denotes a function that returns reflectance based on view, and light direction, so to learn anything of substance we need to look at the models themselves. The time has come where I finally study lighting. I'm thankful for this jam giving me the incentive.

!til &learningjam2024 The concept of BRDF's turned out simple enough. It's a function that returns the amount of light being reflected based on a given direction pointing towards the viewer and a direction pointing towards the light source. Whether they are vectors or angles based on surface normal seems to vary between sources.
A BRDF is meant to be a self contained thing in the rendering algorithm that can be swapped at will. Basically it's an abstraction.
In practice a BRDF implements some material model. Apparently it's common to combine one for diffuse and one for specular. Any old material model you might have heard of (Lambert, Phong etc) counts as a BRDF. Nowadays BRDF's are usually based on the micro facet model, both in games and film.
This is currently my primary source, which I'm still reading through.
https://boksajak.github.io/files/CrashCourseBRDF.pdf

Getting stuck on my surface reconstruction project so I'm taking a break to work on a simple tool for generating textures via compute shaders, as well as making tiled versions of my noise functions.

Further progress on the widget. Evaluating each grid face in order to generate polygon edges like Cubical Marching Squares. Next up is generating geometry that preserves sharp features. I'm leaning towards dual contouring at the moment, where surface vertices are centered around intersecting cells instead of edges. Only problem is that up to four surfaces can intersect one cell, so need to figure out how to handle that in a less expensive manner.

In the process of learning how to generate a mesh from voxel data. I'm aiming towards something along the lines of Dual Contouring or Cubical Marching squares. At the moment I'm figuring out the "address space" of edges, faces and vertices of the grid, which to some extent I expect will be required in order to make triangles between vertices generated from neighboring cells.
As usual when dealing with new problems I make some sort of widget to test my algorithm.
C++, OpenGL, Linux, no third party libraries.