As stated in the previous post, this implementation will be used as the baseline for other programs to be compared with; mainly because I suspect this will be the fastest instance of the program.
To meet the criteria of the 2 minutes running time, some tinkering was needed and the following parameters where established:
Max depth indicates how many bounces a ray might be able to survive, meaning that rays with over five bounces are considered lost and won't affect the color of the corresponding pixel.
The samples parameter establishes de amount of primary rays used to render each individual pixel of the final image. 50 randomly distributed primary rays, are shot to the scene and their results averaged to get the final pixel color.
More samples per pixel allow the color of the image to avoid dithering and present smooth edges on the geometry (Antialias); all this at the expense of longer rendering times and greater amounts of processing power.
The scene to be rendered is the classic Cornell box, composed of 8 spheres; of which the ceiling acts as a light source, four more act as the box sides and three are floating in the middle.
The following image shows a rendered image of the sample scene. This was produced with 5000 samples per pixel and a max depth of 10 bounces.
$ time gcc crb.c -o crb -std=c11 -O3 -lm -D_XOPEN_SOURCE=600 real 0m0.739s user 0m0.628s sys 0m0.076s
$ time ./crb real 1m59.116s user 1m58.216s sys 0m0.112s
Running time on a Raspberry Pi 1
$ time ./crb real 8m14.677s user 8m6.000s sys 0m0.750s
Lines count: 303 code, 71 blanks, 374 total. File size: 7692 bytes
The language offers no surprises whatsoever, it is simple and straightforward and, as expected, the final code runs very fast; so fast that even a Raspberry Pi 1 was able to render the scene in a moderate amount of time.
On the low side, one main source of confusion is when accessing members of a structure instance, you must either use the dot (.) or arrow (->) notation, depending on the kind of variable that is being used. Also, being a simple language, it tends to be quite verbose.
Nonetheless, I really like the C language; resembling Assembler, it forces you to have a whole picture of what you are trying to do, and makes you consider situations that other programming languages hide from you.
You can follow the development of this project on GitHub: https://github.com/niofis/raybench