Exams

18 07 2008

I was studying all week for an exam tonight (around 00:00 ~ 01:00 utc). Coding will continue after that.





Week #5

14 07 2008

Last week the code was simplified, with the intention for it to work as a simple ray tracer. The view_pixel() function was pretty simple, something like if it hits, paint it black, else paint it white. Frame buffer set and the first images consisted of three, equally spaced lines. There was something wrong.

Further hacking in view.c and I found that the pixel width was a problem. When it was set, in view_2init(), the first images were shrinked horizontally, but that was some bug with ap->a_x not being multiplied by pwidth. This was the result:

D
First Rendering. This is a cube😀

Next step – flat shaded images. Back to hacking view.c.

At first I thought it had something to do with kut_planes (because RT_HIT_NORMAL was there) so I tried to use it, but only got segmentation errors. After I realized that handling normals shouldn’t be optional (there was a big if (do_kut_plane) block), I found out how to use RT_HIT_NORMAL (and there needed to be a for loop, to find valid partitions), that code was used and this happened (also, color identification was moved back to rayhit() and view_pixel() just handled ap->a_color):

Isnt that a beautiful cube?

Isn't that a beautiful cube?

That was a big motivation for me.

Rayhit() wasn’t saving the hit points properly – when it got to the memory de-allocation, in view_end(), rtmlt crashed. So, in order to create those images, that part of the code was commented and I only gave some attention to that after the flat shaded images. It was leaking big chunks of memory per rendering, but now it is fixed and the paths are being recorded. But not correctly – currently, it saves every point in a single path (the point recording is important for path tracing, this will be changed in the coming weeks).

Also, allocating memory in each rayhit() function is a problem – performance will be much better if the allocation is done somewhere else, as Sean mentioned. Another thing pending is the file writing, that was cut in order to create the images (in the three lines days, it created a 128mb file).
Moving on to path tracing now.





Flat shaded images!

10 07 2008
Image generated using the rtmlt application

Image generated using the rtmlt application





First image

9 07 2008

Commented a lot of code and simplified view_pixel() and rayhit(). Managed to output the first image (but only to the framebuffer).

http://img99.imageshack.us/img99/1521/silhouettezu3.jpg

And this is the RT output:

http://img164.imageshack.us/img164/1715/rttn3.jpg





Week #4

7 07 2008

School demanded a more time this week, plus the need to take care of things from the abscent week made me need to step a little back from the project, and that wasn’t something I was comfortable with doing, having been away a whole week already.

On to more pressing matters. Functions similar to RT are ready and I intend to code rayhit() for my next step. Some considerations regarding that subject:

  • RT uses ap->a_uptr to store visited regions. Since ap->a_uptr, in RTMLT, points to the MLT structure, I’ve decided to include a generic pointer inside MLT_APP, to hold that information.
  • Where to find a function to treat reflections?? And refractions?? The idea is to recursevely call rt_shootray(), and at the end of rayhit(), set the new direction and origin point from where to shoot the next ray. Which functions must be used in order to achieve that?
  • Should the coloring be done in rayhit()?? Since the MLT path points affect every other point of the path, should the lighting be calculated as we build the path (in rayhit) ?? Still, some info must be collected regarding the color and other properties of the material hit, to make further calculations, if not done in rayhit().
  • Also, how should light be literally transmited ?? Exactly where is the information about the light and how will it affect coloring ?? How exactly are the calculations done ?? Another idea is to add, to the structure point_list, a pointer or a value, to hold the light being emitted from that point. But since every emitted light depend on every other emitted light, how should this be done?? Perhaps there is a more simple way.

Another thing that is bothering me is the time constraints I have – I’m not having the time I’d like to dedicate to the project. Other GSoCers have solid results to show and, with the midterm evaluations approaching, perhaps some alterations need to be done. Feedback appreciated in this regard.





I’m back

30 06 2008

And I’m back. Last week was not the best one for coding.





Absence

19 06 2008

I’ll need to be out of town from 19th June to 29th June. I’ll be back by 30th June.