Wednesday, December 15, 2010

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

5 comments:

  1. Vala is very fresh project and it's used mostly by Gnome devs, maybe that’s why they don't know about it : d

    But Vala haves strong position in Gnome 3

    ReplyDelete
  2. פייתון ופרל לא מספיק גבוהות?
    זה אומנם לא קמפול אבל נראה לי מספיק טוב בשביל זה
    תראה את בלנדר הרבה מההרחבות שלה זה פייתון
    נחמד לראות את הפוסטים שלך ;-)

    ReplyDelete
  3. שים לב שיש בעייה עם פייתון ופרל - הן מעולות לרמה הגבוהה של התוכנית (ממשק משתמש וכו') אבל לא לאלגוריתמים הכבדים (כמו עיבוד התמונה).

    בבלנדר, הרבה מאוד מהחישובים בזמן העבודה השוטפת (ולא הרינדור) הם ההצגה - אבל בלנדר מנצל את ההאצה של כרטיס המסך בשביל זה (גרטיסי מסך מיועדים לזה) וככה זה עובד די מהר.
    אני בספק רב אם תמצא קטעים כבדים של הרינדור עצמו שכתובים בשפת פיתון או פרל.

    עכשיו, בגימפ אין דבר כזה "ניווט מסביב" - כי שם אין כמעט שום דבר מלהזיז תמונה על המסך (וזה באמת קל) - בגימפ אתה הרבה יותר זמן מבצע עיבודים על הנתונים (צביעה, פילטרים וכדומה) לעומת בלנדר - כי בגימפ אתה כל הזמן עושה חישובים לעומת בלנדר ששם החישובים הכבדים ממש הם בעיקר בשלב הרינדור (ומעט בכלים כמו הפיסול וכדומה).

    ולסיום - אם יש משהו מחרפן בשפות כמו פיתון זה העובדה שאין סוגים לטיפוסים של פונקציות. בשפות כמו ג'אווה וC נורא קל לעלות על זה שהעברת פרמטר מהסוג הלא נכון - התוכנית ללא תתקמפל. בפיתון ופרל אי אפשר לעשות את זה - ולכן זה סיוט! צריך לודא כל הזמן סוגי נתונים או לכתוב המון תיעוד של מה כל פונקציה מקבלת (וגם זה לא יכול באמת למנוע טעויות). אני כן מעדיף לתוכניות גדולות להשתמש בשפות עם סוגים. יכול להיות בהחלט שאפשר לכתוב את ממשק המשתמש של גימפ בפיתון (זה אפילו נשמע רעיון לא רע), אבל הקטעים הכבדים (ובגימפ יש הרבה כאלו) צריכים להיות בשפה מקומפלת עם סוגים

    ReplyDelete
  4. We need a low-level language for the pixel processing parts, but IMO we should move to a higher level language for the UI, and JavaScript seems like a good choice since it's both GNOMEish and HTML5ish

    IMO we should get rid of Scheme ASAP...

    ReplyDelete
  5. @Martin Nordholts:

    I agree on C for the low-level parts (we even have some assembler code in GIMP, as far as I remember) but I disagree with your choice for the UI. If there is something annoying about python/javascript/etc., it's the lack of strong typing and the ability to do "correct" mistakes. Many of the features of these languages are gifts, but I'll present some of the problems that occur when writing LARGE programs in them:

    1. Typos in names: writing "f.widht = 50" instead of "f.width = 50" is not an error syntactically, and it will just create a new field. It can take hours to find these annoying bugs

    2. Lack of auto completion in IDE's: Due to the unknown type of objects, auto-completion in IDE's is somewhere between minimal and non-existant

    3. Lack of strong typing: Let's assume I have an object of type RGB color and another of RGBA color. I pass an RGB color to a function expecting RGBA colors. The result - getting the value of "c.a" will refer to an undefined field and cause troubles.
    It is possible to check the types, but adding type checking code everywhere kind of contradicts the reason we wanted a free-typed language...

    ReplyDelete