raych

To finish up the first pre-release of the project, that being version v0.1, I created a file named DEMO.md (link). It contains various images and clips that showcase the shaders in this project. I also finally filled up the changelog (link) with thorough descriptions of each version of the project (you can check out the commit history to see the tags with version that associate it with commits). I also renamed the project from raymarch to raych, as I thought the original name was too vague. I updated the Makefile to be able to package an archive with the binary within. I also added Windows support, via the UCRT64 shell.

As I mentioned in my previous devlog, I wanted to add a 3d camera; which I did in this one. I had to implement a bunch of vector and matrix mathematical functions to be able to have a 3d camera. I am far too tired to set up video recording on my system, so I provided a photo of the Menger sponge from an angle that I could get only by moving my camera.

Finally some fun, shader stuff, eh? I, first, created a very simple camera system, which allows you to move on the X and Z axis. It’s a very simple implementation, without any transformation or rotation matrices. That is the plan in the future. You bind the camera movement to a shader struct inside the main while loop, which then lets you change the shader’s camera position, and in the shape render function, it gets passed as a uniform to the fragment shader. After getting that done, I worked on implementing an infinite (in theory) 3d fractal named Menger sponge, which I was able to do after learning up on shader concepts and math from some very helpful online resources. I was able to create a function inside the fragment shader that lets me render a Menger sponge of desired stage (see images, where the stage is 5). In the future I’d really like to make the Menger sponge infinite, so you would just fly in Menger sponges forever.

And for the cherry on top of the up-’n-coming v0.0.1 (pre)release, some actual ray marching shaders. I draw a quad covering the whole viewport and then apply shading in the fragment shader to draw a deformed sphere with simple diffused lighting and curious colors. I spiced it up a bit by passing time to the shader so it glows periodically (based on sin()). In the future I reckon its entirely possible to make the camera movable and light not hardcoded.

PS: For the curious, v0.0.1 update will be out when I add windows compatibility.

Another OpenGL thing that I implemented this devlog is some basic shape rendering. I added nice functions for rendering a triangle and rectangle to the screen. It’s kinda inefficient but I tried to focus on first having something work and then improving it later if necessary. Data is passed to the functions via a structure that contains the position info and the shape’s color.

First of the things required for rendering are shaders, and this devlog/commit I added a simple shader abstraction layer. The file, for now, it exposes a simple CreateShader(..) function which takes in paths to vertex and fragment shaders, and returns a structure which, as of right now, contains just the program ID. I also fixed the odd bug, which was simply caused by not initializing (malloc-ing) some internal variables. It all should work correctly now.

Another core thing to tackle before the fun shader stuff. I added a dedicated logger, which is just a few functions to neatly display logs, and two macros to wrap them for convenience. Curiously, I have encountered a peculiar bug which I can’t seem to find the root of. the LOG(...) macro segfaults if I use it in the main render loop, but nowhere else. In this case, the LOG_RAW(...) macro doesn’t. Also sometimes internal char* buffers for color and label fail (see the screenshot) and I simply have no idea why, as always happens with one specific LOG and no other ones.

In the first hour (and some minutes) of this project I simply set up my repository, which includes, but is not limited to, the directory structure, Makefile, README contents, the GPLv3 license and wrote some window abstraction code. That means, at this point in time, I can open a window. The project currently only runs on GNU/Linux, but in the future, I plan to support Windows operating systems as well.