DEV Community: Csilla Lukacs

4 Things I learned from Ray Tracing in One Weekend

Csilla Lukacs — Mon, 04 Aug 2025 09:09:02 +0000

Recently, I followed the Ray Tracing in One Weekend book to implement my own ray tracer in C++. I considered following the Rust version, but settled on C++ for two reasons:
1) I have some experience with C++ and
2) Lots of things I read about Rust seem to compare it to C++, so if I want to understand Rust, I might as well get a deeper understanding of C++.

Here's a selection of things I learned.

1. CMake, Clang, GCC, Clang++, G++

By far the hardest part of the project was setting up the environment. I opened my editor of choice, VSCode. I installed the "C/C++ Extension Pack". I followed the steps the extension suggested and created my first cpp file. I ran it by clicking a triangle shaped button provided by the extension. And... it didn't work. I pasted the error messages into ChatGPT. It insisted that I was using a C compiler, when I should be using a C++ compiler. I am not! You are too! And so we went on. Finally, I had to admit that my tasks.json file (generated by the extension, mind you), did indeed reference clang instead of clang++. I think at this point I gave up on the extension, and decided to compile my code using the terminal.

The book makes some references to CMake, so I thought that maybe I'd have to use it, and a brief conversation with AI seemed to confirm this, suggesting that if I want to scale up my project beyond "one file", I'm better off using CMake. Nevertheless, I decided to see how far I could go with clang++. I wanted to really appreciate the need for CMake before trying it. It turned out to be unnecessary this time. My project consists of a main.cpp and many header files, all inside one folder, clang++ was able to handle this perfectly well.

2. build/inOneWeekend > image.ppm

I was of course dimly aware of the > operator, and I'm certain I've used it before, but I never considered extending it to programs I wrote myself. If I wanted to save something to a file, I would have to start with googling "open files in "... Turns out, you can just write to std::cout and then decide to redirect that to a file of your choosing when running the program. This also means that if I want to save image1, image2, image3, ... I don't have to recompile my program just to change the file name. (Yes, ok, I could also do that with command line arguments, but... how does that work again? argsomething...?)

3. std::flush

This is the third thing I'm highlighting that is not strictly speaking related to ray tracing. Didn't I do this to understand something about computer graphics? Maybe my point is that learning doesn't happen the way we assume it does. Maybe a book about ray tracing teaches you how to not litter your console output with

Scanlines remaining: 400
Scanlines remaining: 399
Scanlines remaining: 398
...

Well, this is how:

for (int j = 0; j < image_height; j++) {
    std::clog << "\rScanlines remaining: " << (image_height - j) << ' ' << std::flush;
    for (int i = 0; i < image_width; i++) {
        // ...
    }
}

4. What you will get wrong

Since all the code for the ray tracer is available in the book, I gave myself two rules:

I will not copy and paste any code.
If AI code completion suggests the correct code (with the same variable names as in the book!), I am allowed to press tab.

This meant that I still read every single line of code and thought about what it meant, but I could still breeze through the really really really obvious bits.
Still, I made two mistakes that resulted in a different image than what I was supposed to get:

Here, the top image was the desired result, and my code resulted in the bottom image.

Similar story below:

Want to guess? Ok I'll spoil it for you. The first one was literally a sign error, in that I added a minus sign where there shouldn't have been one, when calculating whether a ray intersects a certain sphere or not.

What about the second one? This one was more annoying, because I learned something from it that I would have preferred not to learn.
Here's my code:

if (rec.mat->scatter(r, rec, attenuation, scattered)) {
    return attenuation * ray_color(scattered, depth-1, world);
return color(0,0,0);
}

Here's the correct code:

if (rec.mat->scatter(r, rec, attenuation, scattered)) {
    return attenuation * ray_color(scattered, depth-1, world);
}  
return color(0,0,0);

I don't blame you if it isn't obvious at first glance! It wasn't obvious to me either, and I blame my preference for not using braces around if blocks that are just one line. Which I must now admit is WRONG. If I was consistent about using braces everywhere, I would surely have noticed that just because return color(0,0,0) is unindented, it is not preceded by a closing brace, and therefore must still be part of the if block.

Ok that's almost 1000 words, I have more notes but they will have to go in part 2 because I'm tired of writing now!!!

Making a note-taking app: day 2, in which we add a database

Csilla Lukacs — Mon, 21 Jul 2025 14:44:24 +0000

In the previous post I started building my app by creating a basic user interface. But I couldn't stop thinking about data persistence.
Should I save notes as files? Should I use a database? Does it make sense to use a database if I only want the data to exist on the user's phone? What if I want the option to upload it to the cloud later?
As a developer, I feel more comfortable making queries to a database, and my data has a structured format - pages belong to notebooks, notes belong to pages, and each has metadata. This would make it a good fit for a relational database. And I don't want to deal with opening and editing files. But I still had doubts: isn't it natural to save your notes as Markdown files, like Obsidian does?
In the end, I settled on a database. Since my app is inspired by messaging app interfaces, any individual notes would be short, so I might end up with a lot of Markdown files. Surely opening and editing files adds some overhead, and databases are designed to let you quickly access your data, make queries and update your data quickly. Does this reasoning sound vague? Ultimately, the sooner I made the decision, the sooner I could build something and figure out if it can work!

So I started by installing expo-sqlite, and adding this file to deal with creating (and resetting) the database:

import * as FileSystem from "expo-file-system";
import * as SQLite from "expo-sqlite";

const DB_NAME = "notes.db";

let db: SQLite.SQLiteDatabase;

export async function initDatabase() {
  if (__DEV__) {
    await resetDatabaseInDev();
  }

  db = SQLite.openDatabaseSync(DB_NAME);
  await setupSchema();
  return db;
}

async function resetDatabaseInDev() {
  const dir = `${FileSystem.documentDirectory}SQLite`;
  const dbFile = `${dir}/${DB_NAME}`;
  try {
    const fileInfo = await FileSystem.getInfoAsync(dbFile);
    if (fileInfo.exists) {
      await FileSystem.deleteAsync(dbFile, { idempotent: true });
      console.log("💥 Deleted old DB in dev mode");
    }
  } catch (e) {
    console.warn("Could not delete DB file", e);
  }
}

function setupSchema(): Promise<void> {
  return new Promise((resolve, reject) => {
    db.execAsync(
      `
          CREATE TABLE IF NOT EXISTS notebooks (
            id INTEGER PRIMARY KEY AUTOINCREMENT,
            name TEXT NOT NULL
          );
          CREATE TABLE IF NOT EXISTS pages (
            id INTEGER PRIMARY KEY AUTOINCREMENT,
            notebook_id INTEGER,
            content TEXT,
            created_at TEXT,
            updated_at TEXT,
            FOREIGN KEY(notebook_id) REFERENCES notebooks(id)
          );
        `
    )
      .then(() => {
        console.log("✅ Schema created");
        resolve();
      })
      .catch((error) => {
        console.error("❌ Schema creation error:", error);
        reject(error);
      });
  });
}

export function getDb() {
  if (!db) throw new Error("DB not initialized. Call initDatabase() first.");
  return db;
}

Ok, so I let AI generate it for me, and then fixed syntax errors and replaced calls to non-existent functions. All this file does is define some functions that are called from elsewhere in the code.
initDatabase creates notes.db, and I call it in my main _layout.tsx file. (note this line: db = SQLite.openDatabaseSync(DB_NAME), this will open 'notes.db' if it exists, OR create it if it doesn't)
I also want to make sure to recreate the database when reloading the app, because I expect the schema to change a few times during development. (For example, created_at and updated_at shouldn't be TEXT fields, but for the moment I wanted something that works and I don't know off the top of my head what data types exist in SQLite)

The next step was to confirm that I indeed created a database and I am able to connect to it, so I did that using my favorite method: I added two buttons, one that creates a new notebook, and one that queries the list of notebooks and prints the result to the console:


          <Pressable
            onPress={() =>
              getDb().execSync(
                "INSERT INTO notebooks (name) VALUES ('New Notebook')"
              )
            }
          >
            <Text style={{ fontSize: 40 }}>+</Text>
          </Pressable>
          <Pressable
            onPress={() => {
              const res = getDb().getAllSync(
                "SELECT * FROM notebooks"
              )
              console.log(res)
            }
            }
          >
            <Text style={{ fontSize: 40 }}>O</Text>
          </Pressable>

And it worked! Now that we confirmed that (1) a database is indeed created (2) we can connect to it and insert data, we can focus on making the schema reflect what we actually want (not only do we have notebooks and pages, but those pages have notes inside them), and replacing the dummy data on the screen with data from the database. We should probably seed the database with test data as well!

See you next time!

Making a note-taking app: day 1

Csilla Lukacs — Fri, 18 Jul 2025 20:38:22 +0000

The Idea

I don't know about you, but I frequently use messaging apps for note-taking. I like typing in a thought, an idea, a measurement, and immediately having the timestamp appended.

I thought I should build a note-taking app based on this idea. The user interface should be that of a messaging app, but it's all in service of taking quick notes. Servers become notebooks, and channels become pages.

I've already worked with React Native and Expo, so I decided to use these for the app. I have yet to decide how to persist data. The app should work offline, but I don't want to exclude the possibility of syncing to the cloud in the future.

My goal is to eventually publish this on the app store.

Getting Started

I decided to start with getting the layout/navigation right.
My first experiment was inspired by the Discord app, tabs on the bottom of the screen, list of servers and channels on the left, clicking a channel opens that channel in a panel that slides in from the right. Swiping right takes you back to the channel list, swiping left opens the same channel again.
I first experimented with using an expo modal for the individual 'channels' (so a Stack.Screen with presentation: modal). I wanted it to be a modal because I want it to cover the navigation bar with the tabs.

        <Stack.Screen
          name="page/[pageId]"
          options={{
            title: "Page",
            presentation: "modal",
          }}
        />

The problem with this is that, on iOS at least, the modal only ever slides in from the bottom (so setting animation: "slide_from_right" doesn't work). Also, once you close it, you can't reopen the same page by swiping up, you would have to select it from the list again.
For these reasons, I decided to instead use the Drawer component. Now the navigation panel sits on top of the current note, and can be opened and closed by swiping right/left. I got rid of the tabs for now.
I also came across this article on how Discord does navigation on Android (or did, in 2020), so that disabused me of the idea that apps that work well do so because they only ever use out-of-the-box components, in the ways they are meant to be used, so never run into problems or bugs or anything of the sort :)

I also added a TextInput to the individual channel/note/page screen (what are names), and played around with KeyboardAvoidingView which hasn't gotten less annoying since the first time I used it. Apparently react-native-keyboard-controller is better, so I will try that next. The current one works except for one small thing, namely that it's not animated, the view jumps up before the keyboard animation even finishes.
There's an issue for this on Github, although i'm not using iPadOS.
I kind of wish I could make something without importing a million libraries!

Conclusion

I think I tried to do a bit too much today, if I'd stopped sooner today I would have gotten less annoyed. Luckily I still managed to have a nice evening, I ate some oysters, drank thai iced tea and watched a movie.

Ok that's all for today, see you next time!

Cube 1: Fixing the bug

Csilla Lukacs — Thu, 17 Jul 2025 15:46:20 +0000

Yesterday I wrote this post describing a Three.js project I worked on a year ago and a bug that I was encountering. I thought I would write a long series of posts in the process of trying to fix it, so this might come as a bit of an anticlimax: I figured it out this morning. I've been putting this off for weeks, and now it's done.

So what happened? Well, the most important clue was that the bug only happened when using the mouse, so it must have been caused by something that happens when we do something with the mouse, such as hover over the cube or click it.
Maybe even something that happens many, many times a second?

So what happens when we move the mouse? We check if the cursor is 'above' one of the faces of the cube and highlight every cubie on that side, to make it clear that if the user clicks the cube at this point, this is the side that will rotate.

Except, this code doesn't just run when we move the mouse. It runs on every frame. Why? Well, when I wrote it, I reasoned that the cube is also rotating on its own, so the 'selected' side could change even if the mouse isn't moving.

So how exactly were we highlighting the currently selected side? First, we cast a ray to see which face of the cube it intersected, then we added each cubie that was currently on this side to a group (this is what updateSide(i) does), and then for each cubie in this group, we set the material to be emissive.

    update() 
    {
        this.group.rotation.x += 0.002;
        this.group.rotation.y += 0.002;

        if (this.animating !== -1)
        {
            // ... 
            return;
        } 

        this.raycaster.setFromCamera(this.mouse, this.camera)
        const intersects = this.raycaster.intersectObject(this.hitbox);

        for (const cubie of this.cubies)
        {
            cubie.mesh.material.emissive.set(0x000000);
        }

        if (!intersects[0])
        {
            return;
        };

        const face = intersects[0].face;
        for (let i = 0; i < 6; i++)
        {
            const key = Object.keys(Cubie.directions)[i];
            if (face.normal.equals(Cubie.directions[key]))
            {
                this.updateSide(i);
                for (const cubie of this.sides[i].array)
                {
                    cubie.mesh.material.emissive.set(0x444444);
                }

            }
        }
    }

Let's look at updateSide() for a second:

    updateSide(sideIndex)
    {
        if (this.animating !== -1) return;
        this.cubies.forEach(cubie => 
        {
            if (this.isOnSide(cubie, sideIndex))
            {
                if (!this.sides[sideIndex].array.includes(cubie))
                    this.sides[sideIndex].array.push(cubie);
                this.sides[sideIndex].group.attach(cubie.mesh);
            }
            else
            {
                this.sides[sideIndex].array = this.sides[sideIndex].array.filter(c => c !== cubie);
                this.theRest.attach(cubie.mesh);
            }
        });
    }

So updateSide() runs both when we hover over a side and when we want to rotate a side (either by clicking it or by pressing a key). The point of this function is to check the actual position of each of the cubies and tell us which ones are currently, say, on the left face of the cube. We add these cubies to a Group, mainly so we can rotate the group as a whole, and not have to bother with rotating each cubie individually.
When you add objects to a group in Three.js using .attach(), it updates their local transforms based on their world matrices. If this is done every frame, tiny floating point errors can accumulate.

Ok, so let's step back. We were performing this calculation on every frame because we wanted to make sure that the currently highlighted side is still 'under our mouse', i.e. it hasn't rotated away. For this reason, we do need to cast a ray on every frame to check which face of the cube it intersects. But we don't need to actually call updateSide() on every frame. We only need to call it if the intersected side is different from last time. So if we add a field in Cube, let's call it highlightedSide, we can check if it changed, and only then do the whole [find out which cubes belong to this side, attach them to a group, highlight them] thing.

So then, our new update() function looks like this:

    update() 
    {
        this.group.rotation.x += 0.002;
        this.group.rotation.y += 0.002;

        if (this.animating !== -1)
        {
            // ...
            return;
        } 

        this.raycaster.setFromCamera(this.mouse, this.camera)
        const intersects = this.raycaster.intersectObject(this.hitbox);

        if (!intersects[0])
        {
            for (const cubie of this.cubies)
            {
                cubie.mesh.material.emissive.set(0x000000);
            }
            this.highlightedSide = null;
            return;
        };

        const face = intersects[0].face;
        for (let i = 0; i < 6; i++)
        {
            const key = Object.keys(Cubie.directions)[i];
            if (this.highlightedSide !== i && face.normal.equals(Cubie.directions[key]))
            {
                this.updateSide(i);
                this.highlightedSide = i;
                for (const cubie of this.cubies)
                {
                    cubie.mesh.material.emissive.set(0x000000);
                }
                for (const cubie of this.sides[i].array)
                {
                    cubie.mesh.material.emissive.set(0x444444);
                }
            }
        }
    }

So tl;dr, we had some unnecessary matrix multiplications happening on every single frame, which eventually led to inaccuracies. This also gives us a clue as to why the bug seemed less likely to happen on my ancient Thinkpad: the frame rate was 30 fps, so it would take twice as long to get to n matrix multiplications (where n is however many it takes to produce an obviously wrong result).

In the process of fixing this bug, I grew quite attached to the 'broken' cube (don't physical objects also break if we play with them too much?), so I decided to deploy it here.
And of course, the current version can be found here.

Cube 0: My Rubik's cube project from a year ago

Csilla Lukacs — Wed, 16 Jul 2025 22:35:04 +0000

This will be the first post in a series about returning to a project I did about a year ago and trying to improve on it and maybe learn something along the way!

A year ago I built an interactive Rubik's cube using Three.js.

The inspiration behind it was probably reading Erno Rubik's book Cubed: The Puzzle of Us All, a memoir where he talks about the cube.
There are two things I found interesting & still remember from the book.

That Rubik originally considered purple for the sixth color, but ended up settling on white, because he considers the cube male.
That after he created the cube he actually solved it himself. Does being the creator of the magic cube make it easier to solve? I like the cube as an object and sometimes play with it until I get frustrated, but out of principle I refuse to "learn" how to solve it. But I also never seriously consider the possibility of actually figuring it out.

When you open the page, you see a (solved) cube rotating in empty space*. When you hover over a face of the cube, that side of the cube is highlighted. If you click it, you can rotate the side, just like with a real cube.
This feature set is enough for me to consider the simulation complete, since this is pretty much what you can do with a physical cube. There is no "scramble" or "solve" function, nor do I plan to implement these since at the moment the cube interests me as a physical rather than mathematical object. I don't currently represent the 'state' of the cube, beyond the positions and rotations of the little cubes (which Rubik in his book calls cubies, so I adopted this terminology in the code).

However, because it has to look nice, one thing I did bother with is a custom shader for the cubies, so they are not just a solid color, but also have a black border, to imitate the look of colored stickers on a black background:

material.onBeforeCompile = (shader) => {
    shader.fragmentShader = shader.fragmentShader.replace(
        '#include <color_fragment>',
        `
            #include <color_fragment>
            vec2 cUv = vUv - 0.5;
            if (abs(cUv.x) > 0.45 || abs(cUv.y) > 0.45) diffuseColor = vec4(0.0, 0.0, 0.0, 1.0);
            if (abs(cUv.x) + abs(cUv.y) > 0.85) diffuseColor = vec4(0.0, 0.0, 0.0, 1.0);
        `
    );
};

cUv stands for "centered UV", basically we want the coordinates to move between -0.5 and 0.5 instead of 0 and 1, so we can reason about left/right and top/bottom similarly.
the next two lines define where we want the square to be black: (1) anywhere that's less than 0.05 from the edge, and (2) the corners.

Also, if you're wondering about lines 2-5, we are replacing part of the fragment shader code, basically we are replacing "#include <color_fragment>" with "include <color_fragment>" plus our code, aka inserting our code after "include <color_fragment>". Why there specifically? It took a bit of trial and error, trying different places until one of them didn't break anything.

This is all well and good, so it's finished, right? I finally completed a side project? Well, almost. There is a small issue, the explanation for which will probably be "...something something floating point". If you play with the cube long enough, it eventually starts acting weird. Some of the cubies get stuck in weird positions, and seemingly even become a bit smaller than the rest. What's worse, I thought I'd fixed this exact issue before, but the bug is still there when running the code on a better computer.

So my goal now is to return to code I wrote a year ago, understand it, and try to figure out what's going on. Come along for the journey?

Some things I want to do:

try to vibe code the entire thing from scratch, for fun
describe the problem. when does it happen? there's actually two ways to rotate the cube: with the keyboard or with the mouse. if one uses only the keyboard, and doesn't hover over the cube with the mouse, i believe the bug doesn't occur. so it must have something to do with what happens when we raycast / highlight the selected side.
✨✨✨ make the code cleaner ✨✨✨, get it to a point where I can explain all of it (without significant embarrassment)
possibly add some tests. Right now I'm not sure how to write tests for three.js. also, this might involve representing the state of the cube in some way, to then be able to compare that to a desired state after a series of rotations.

*Initially, I considered a white room as the background. When I experimented with removing it, it turned out that it improves performance by a lot. I was surprised by this, it was a simple white box with what, 24 vertices? Well, it turns out not rendering anything on 70% of the canvas makes a difference.

btw if you want to follow along, here is the code I'm starting with.
And the latest version can be played with here.