matteopicciolini / jtracer

Project for Numerical Methods for Photorealistic Image Generation Exam at UNIMI (Master Degree in Physics)

💫 About Me:

I'm a master physics student. I got my bachelor's degree in physics in 2022 in Milan. I am interested in general relativity and cosmology. In the figure beside I show you one of the most fascinating things that I have had the privilege of studying. It is a simulation of the gravitational lensing phenomenon, which describes the deflection of light rays in the presence of very massive objects.

I'm 24 and I like programming, listening to classical music and programming while listening to classical music.

Feel free to have a stroll around my profile. Suggestions to improve my code quality are always welcome! You can contact me at this e-mail: [email protected].

🌐 Socials:

💻 Tech Stack:

jtracer's Issues

Camera position bug

In PCG, Material and Test #6, the Camera class has some bug. In both Perspective and Orthogonal modes, if the camera is positioned at Vec(1.f, 0.f, 0.f) and all objects are at Vec(<1.f, 0.f, 0.f), they still appear in the output image.

Bug in PCG random generator

The addition of the pathtracer feature in the PR #8 has highlighted an issue related to the random number generation using the PCG class that was not discovered during testing. Specifically, I have found that the randomFloat method is generating negative numbers.

The tests performed on the PCG class only cover random method, while randomFloat method has not been directly tested. This method is indirectly used in the ONBTest, but it did not raise any errors. However, it appears to be the cause of the failure in the CI build of this commit in the PR #8: 7d093cf.

Incorrect Exception Message

I am reporting a bug that occurs when a GrammarErrorException is thrown. If the syntax of the .txt file is incorrect, the error message of this class should be: 'got instead of an identifier,' but instead of , the memory address of token variable is shown. I suppose the issue can be resolved by introducing a toString() method.

Computing time Triangles

I opened this issue cause of the computational time spent to generate shapes using TriangleMesh.
I tried to measure computing time generating a simple scene with sky, ground and the solid made by triangle's meshing, with no antialiasing and 10 rays per pixel. I built a graph of the time used in terms of the number of vertices passed by command line:

We need a method to speed up the code. One soolution could be parallelize the Triangle and TriangleMes classes to be more efficient. Another way could be using a simple shape like a sphere to make a fast check for the rayInterception before calculating all the normals of the triangles.

Missing Tests for Hyperboloid and CSG

In PR #16 and PR #15, I forgot to start git tracking on the test files that I had locally. I am directly uploading the files to the master branch with reference to this issue.

Diffuse material polyedron's faces and transformations

there's` a new problem for the face of the polyedron created by triangle mesh, some of the polyedron's faces are completely black. I individuated the problem on the calculus fo the normals of the triangles: the method createMash generate random order in the indexes of the vertices and this leads to a error on the normal calculus.
Also transformations don't work so far.

The function:

public void createMesh() {
        int numVertices = vertices.size();

        if (numVertices < 3) {
            // Non è possibile generare triangoli con meno di 3 vertici
            return;
        }

        // Genera i triangoli
        for (int i = 0; i < numVertices - 2; i++) {
            for (int j = i + 1; j < numVertices - 1; j++) {
                for (int k = j + 1; k < numVertices; k++) {
                    Point v0 = vertices.get(i);
                    Point v1 = vertices.get(j);
                    Point v2 = vertices.get(k);

                    // Calcola la normale del triangolo
                    Normal normal = calculateTriangleNormal(v0, v1, v2);

                    // Verifica l'orientazione della normale rispetto al verso desiderato (ad esempio, verso l'esterno del solido)
                    if (isNormalOrientationCorrect(normal, v0, v1, v2)) {
                        triangles.add(new Triangle(v0, v1, v2, transformation, material));
                    } else {
                        // Se l'orientazione della normale non è corretta, inverti i vertici per invertire l'orientazione del triangolo
                        triangles.add(new Triangle(v0, v2, v1, transformation, material));
                    }
                }
            }
        }
    }

And the result is:

indices kji:

indices ijk:

Bug in scatterRay in DiffuseBRDF

I open this issue in an attempt to resolve a bug that has been present since the beginning of PR #6 and has inevitably propagated to PR #8, #10, and #11. In all the images displayed in these PRs, please note that the diffuse spheres actually reflect other nearby objects. The reflection in question is not as sharp as it should be for a SphereBRDF, which suggests a bug in the Sphere or BRDF class. I am providing an image below that clearly demonstrates this phenomenon:

A situation where this issue was already clearly noticeable is the following:
Originally posted by @matteopicciolini in #10 (comment)

Bugs in InStream (incorrect parse)

During the code writing for PR #13 (branch compiler), I encountered difficulties in generating output images from an input file using the "render" command. By modifying the tests in the InStreamTest class, in the commit e983ddb, I narrowed down the issue to a bug in the translation reading. In fact, the tests are failing due to this line in TestParser:
assertTrue(Transformation.translation(new Vec(0.f, 0.f, 1.f)).isClose(scene.objects.get(2).transformation));
I am opening this issue to resolve this problem.

Upside-down flipped Image

In Cameras Development #3, the produced images are flipped upside-down due to a bug in the implementation of function fireRay in class ImageTracer.