Hey, I’m Mátyás Komáromi!

Turns out my ray tracer uses a biased estimator, so I unbiased it. The issue When using Monte Carlo integration, the samples need to be weighted by the reciprocal of the probability of choosing that sample. This ensures that the expected value of the sample is the integrand, i.e. that it is unbiased: $ \begin{aligned} I = \frac{g(x)}{p(x)} \end{aligned} $ Here, $g$ contains all terms contributing to the terms inside the integral in the rendering equation at the current vertex and $p$ is the probability of choosing $x$ as the sample. ...

In my ray tracter on sharp edges like the rim of the spheres a strong aliasing effect can be seen, so I decided to look at antialising this time. Randomizing sub-pixel positions So far I have been initiating rays from the centers of pixels always, instead of that I can simply generate two uniform random numbers on [0,1] and initiate a ray from that sub-pixel position. I introduced a new enum, expecting having to add different strategies for sampling: ...

This time I am adding transparent materials to my ray tracer and use it to simulate a glass ball in the Cornell box scene. Transparent Material So far I only had once kind of material; diffuse. To model glass I need a new kind of material that describes how light rays can pass through the object. First of all let’s introduce an abstraction for a medium. struct Medium { float ior; ///< Index of refraction }; For now it only describes the index of refraction, which I will use to figure out how light rays refract when crossing boundaries, but later I can use it to add support for volumetric rendering such as fog. ...

The rendered images look good but it takes an awful lot of time to create them. Adding more effects later will make it even slower, so I want to take a look into using more of my computer’s resources to render. Single-threading The renderer currently uses a single CPU core. To assess the speed gains I wrote some code to count the number of ray casts performed per second. In the single-threaded version that works out to be 9.1 million ray casts per second. ...

Previously I created a ray tracing program that can render colored shapes with a checkerboard texture. It’s finally time to actually do computer graphics and add path tracing to my application. The rendering equation In its most glorious form the rendering equation looks like this: $L_o(\bold{x}, \omega_o, \lambda, t) = L_e(\bold{x}, \omega_o, \lambda, t) + L_r(\bold{x}, \omega_o, \lambda, t)$ $L_r(\bold{x}, \omega_o, \lambda, t) = \int_\Omega{f_r(x,\omega_i,\omega_o,\lambda,t)L_i(\bold{x}, \omega_i, \lambda, t)(\omega_i\cdot \bold{n})}d\omega_i$ Where ...

Previously I started working on my very own ray tracer in C++. I got to render basic shapes and put a checker texture on them. This time I want to introduce a new concept into the code, materials. Debug color Each object looks the same in my render right now, it would be nice to see where one ends and another begins. To achieve that I added a material class: ...

Last time on my ray tracer journey I made a simple C++20 program that could trace rays from a camera and test if they intersect with a sphere. This time I will make the scene more interesting using UV coordinates. UV coordinates of a Sphere When a ray hits a sphere we can use some simple trigonometry to find the intersection point’s Uv coordinates on the sphere. Again, I will just link to Scratch a Pixel instead of repeating the math. ...

I absolutely love computer graphics and since many years I have been dreaming of working on something with it. Well that time is now, I decided to build a ray tracing renderer from the ground up. I will document my journey here, loosely, making a post when I feel like it. There are many excellent tutorials that do a great job at explaining the foundations and ray tracing and photorealistic rendering, therefore I will not attempt to be thorough on every such detail, but I’ll rather link to resources I used. ...