Lessons learned from Writing a RayTracer

As I promised in my post about finishing my ray-tracer, I'm publishing the math equations I used in order to save some time for other people, when doing the intersection calculations.

You can find the document here: The 3D Equation Sheet

And here is a list of ridiculously annoying bugs, that I encountered during writing the ray-tracer. Although some of these seem really trivial, I'll list them in hope that they will save you some time when you write a ray-tracer. Even though these seem trivial, I know that some of them are bugs that other teams also had.

Common Bugs:

• When you shoot a ray from the eye and find an intersection, make sure the item is actually in front of the eye and not behind it!
• When the ray from the eye intersects with a point, and you shoot light at the point, make sure the light is on the same side of the surface as your eye - so that you won't see light on the other side on opaque surfaces!
• When calculating the intersection with a cylinder, which has a limited length - if the first intersection is "too far" from the origin of the cylinder, the second intersection may actually be in range! So check both...
• Rays of light should be shot from the eye of the camera, and not from the image plane of the camera! (It matters when checking if an object is behind us or not)
• When building the plane where x=6, the equation is x-6=0 and not x+6=0. Trivial, but not noticing this missing minus wasted an entire day for me…

Finished my Raytracer!

Snowy Night
15K faces, includes reflection and phong normal interpolation

Above you can see the splash screen for my raytracer! Just handed it in, and overall I'm proud of myself (many thanks to my partner, the guru behind most of the lighting!). The code is very optmized (as much optimized as I can get without starting to write unreadable code).

Overall, I would summarize this assignment as something which I learned from - not only about graphics, but mainly about, how to optimize code (changing several lines for example made everything 3 times faster), how to debug properly and about writing larger scale programs (4000 lines is not gigantic, but it's bigger than anything I dealt with in the past, in which I knew what every line does).

The interesting part was writing the Octal Tree, aka Octree (Blender users should know what this is!). This was my first attempt at developing a high-performance data structure on my own, without any reference (there are many on google, but I used none). On the way I developed several optimization tricks (to make the tree less deep, to reduce the penalty of empty areas, and to overcome some other non-optimal meshes).

I really enjoyed most of this assignment (except for the part in which some of the reference renders had mistakes in them - wasting 6 hours because they have a mistake is NOT fun...) and developing most of the fast calculations for the geometry (not for the lighting) was fun.

The document describing the math which I used will be released later this week (as a starting point for people who want to write ray tracers), along with a list of annoying and potentially common bugs when writing a raytracer. Also an update about StructureGraphic - still waiting for the answer from the proffessor about hosting it the university. If he won't answer soon, I'll host it externally (any suggestions for code hosting sites or tips for choosing between github, launchpad, etc. ?). BTW, The next project in the course is writing a simple 3D game engine in OpenGL, and then writing a game with it :D

Writing a Raytracer, and some other random thoughts

I always wanted to write a raytracer, and theoretically I knew enough math and programming to do it for a long time. Yet, I didn't write one before - this is because I thought it would be a gigantic project. Well, I'm gald to tell you that at least a basic ray tracer is not too big!

The picture above is from a half-done ray tracer which I'm implementing during a course in computer graphics (which I'm taking now). I have documented the math that I needed, along with annoying bugs that I had (and I'm sure that at least some of these are common bugs).

When I finish this project in the following weeks, I intend to publish these documents. Currently I have:

• A list of things which can cause annoying bugs, which are related to how ray tracers should work.
• A document explaining many common 3D calculations (instead of taking these for granted, like we did in class).

I may publish more documentation about writing a ray tracer when I'm done - but this is just quick update about what I'm currently working on.

During writing the raytracer, I saw the influence of choosing the right programming language. We started with C++ and after we had memory leak that we failed to trace (even with valgrind and friends) we migrated to java (in which you have to work very hard to leak memory) - since it was the begining and converting the code was quicker than fixing the leak.

The debate about programming languages made me wonder - when GIMP 2.8 is finally out (and I'll start working on gimp again in the next weeks - I had too many things to do lately), and the writing of GIMP 3.0 starts, should we keep using C?

C is OK, as long as you know what you are doing, unlike C++ in which you can still make things crash even if you *think* you know what you are doing. I would really like to see GIMP in a higher level programming language, but it seems as if Java and C# are out of the question (patents, political/idiological reasons, ...). About a month ago, someone introduced me to Vala - a new OOP programming language, which works very nicely with the GNOME libraries, and it's translated to C code so that it works on most platforms.

I wonder if it's possible to convert the code gradually to Vala - and have the C code integrate with the converted Vala code. It is theoretically possible (I think, since Vala translates into C), I just wonder if it's practical, and what would other developers think about this idea.

Also, is Vala mature enough? And more importantly, Is Vala known enough? I did find several projects that use it, but when I tried to check how many people know it (asked fellow students in the university labs - sounds like the right place to ask) most people said they never heard about it.

Edit: See the comments below for a discussion for/against languages such as javascript/python/perl