Development Journal of a Raytracer

 I have continued work on the thread stuff. It slowly makes progress and I hope that I will be able to switch the raytracer to the new system tomorrow. Then I can also remove the old code and start with the addition of the functions I need to query the number of cores available and ask for creation of some threads, each locked to a core. Even if Microsoft discourages setting the thread affinity, I will do it, because when I see, how Vista distributes the load on my machine, I do not have a lot of confidence into the scheduler and will rather do it myself.

I have finally also done some real work on parallelization of the raytracer. In the last two days I have looked into the (simple) threading stuff I have been using. I don't want to have the dependency on threading in my low level libraries, I only need the interface there. So I plan to have a plugin module which supports the real thread implementation. To do that, I need two abstract base classes.

The first is called "Thread" and has an abstract function "run", the actual implementation derives from that class and overloads the run-function. All thread control is supposed to be in "Thread".

But the actual code to create and handle threads will be in a child class of ThreadImpl. The Thread-class will simply dispatch all calls to that one. When created it will ask to get an instance of ThreadImpl. Child-classes of ThreadImpl will supply the actual functionality. With this I hope to be able to have a threading system which is easy to use, but keep my programs working even if I don't supply any threading support. Also it should be possible to change the threading model if a third party library needs it.

I have done all the easy things now for the Sweep Constructor. There were still some small issues with profile editing, but those are solved now (a missing matrix). Also the constructor actually creates geometry now. It only works with paths of length 2 and only with path that are running along the y-axis. I have also thought about how to change the path, I don't want to input the paths in 3d, I already know that that is hard. So I try something different, the path is projected onto two planes (xy-plane and zy-plane) and I will edit the path on those projections. I don't know if it will work, but I think it might be a good way. The projections are already displayed and also a grid is placed behind those projections.

As I don't see any useful way to combine editing of the profile and the path, I think I will separate the selections and editors. I have never tried that and am not 100% sure I can do that in my current model, but I think it should work. That would show a path for future modifiers which should make it possible, to create complex editing behavior from smaller building blocks.

I have worked quite a lot on the Sweep Constructor. It is progressing nicely and I hope I soon have the simple stuff implemented. The harder bit will be, to make the path changeable. I will need to make the selection and the editor more flexible to do that, without breaking the Rotational Constructor.

I have "played" with the Draw On Plane-modifier today and it looks like I really fixed it. I continued with the handle of the cup and have created the raw form and also extruded it. I will probably need to do some more changes to the program to finish it, though. I have trouble to round off the handle and have been considering changing the Free Edit-modifier so, that I can lock in the work plane. Currently the work plane is always defined by the camera view, but I don't see a big problem to make the change and it should help me to model complex stuff where I need to move the camera to decide if the movement is ok.

I have also started on reworking the code to pull out the profile editing functions. First I created a new class which contains only the profile stuff. This is already compiling. Next is to remove that part from the Rotational Constructor and base it on the new class. That shouldn't be very hard so I hope to get that done tomorrow.

I started to add the new track and ran into some problems. Not with constraining the car, at least it seems so, though it could also be affected. But the problem is on a much lower level, the program has troubles handling straight segments, the resulting track is just wrong. I have fixed some issues (e.g. the left and the right side of the track was swapped), but there are still some problems. I will try to find and fix them next week and then I also have to finish the new track. The inclination is still wrong, it jumps from 0° to 5°, it is supposed to move more slowly and I have no slope in it yet.

I think I have found and fixed the problem last found. So on Friday I will once again try to create the handle of the tea cup. I hope it finally goes well and I can finish the cup. A lot of work had to be done to fix the program. So now I hope I can again spend some time modeling. If it goes well, I will start to modify the Rotational Constructor. I am planning to move the profile editing out to separate classes so I can reuse that bit. I plan to add a sweep operator which works like the Rotational Constructor and also uses the same code to edit the profile. I hope that part will be as much fun to use as the Rotational Constructor.

I am finished with the second step, the thread id is now passed through all the code which needs it. So next I will add the function to query the number of cores and create the threads. Then I will write the new sampler and then we will see, if it works. So I hope the next steps are more interesting, the addition of the thread id was as boring as it gets.

Edit:

Forgot to mention it. The raytracer still works and though I only tested one scene, it still seems to create the same images.

I am still working to pass through the thread id. It is needed in all the functions in the active rendering loop. So a lot of the functions I only changed some weeks ago now are changed again. I am mostly finished with this, I do not expect to loose a lot of single thread performance, as most of the functions already had a lot of parameters, so I hope passing through an additional int won't matter.

When I have finally all the functions adapted, I will test if the raytracer is still functioning. Then I will have to write some new thread functions to create the threads (I plan to pin the threads to the cores later) and then I need a new sampler which distributes the work to the threads. The final step will be to add conditional instructions to choose the thread-safe spacial subdivision structure I have already modified. And then I will see, if it was worth the effort.

I just noticed I have not blogged about the test with the Draw On Plane-modifier. It went terrible, the Change Geometry had nearly the same bug as the old code. The old code was the model after which I created the Change Geometry, but that I have managed to transfer that bug into code which works considerably differently is curious.

In any case I have spent some hours last week to try to find and fix the problems. Today I finally found out, where the problem was and even was able to fix it. The problem is, that I need to calculate the index an edge will have after all the changes have been done. This is not easy, as an edge can be split multiple times and so I have to keep track exactly which edge will end up on what index after all the split edges are sorted out. And there I had a big bug in the code, the sequence it ended up calculating didn't match the one which resulted from actually applying the changes. What made it very hard to find is, that incrementally it worked perfectly, only when applying all the operations (e.g. multiple additions of edges, moving of vertices, splitting of edges) it failed.

But now it seems to be working. I tried quite a few modifications and all went through well. But I also found the next problem. A face is created from the sequence of edges. If those edges are split, the face actually created has to incorporate all the splits. And that doesn't work, the result is just wrong. So I will have to look for that problem next.

I was a bit lazy today as I ran into problems everywhere. One of them is, that the renderings to find the problem with the Ward BRDF take very long. So I started to finally parallelize the raytracer. The first thing I did was to fix the spacial subdivision structure. I use a grid and mailboxing, but that was not safe for parallelization as I had implemented it. I added a second structure to do it right for multithreading. I added a second one, as the original implementation has advantages for single threaded use which I want to keep.

Then I started to add the thread id to the raytracer. It has to be moved through the calls, as I don't want to use OS specific calls. Also I need the thread ids to be consecutive starting at 0 so I can use them to directly index into arrays. Most of the function used while rendering will have to be changed again.

I looked into the next rendering problem and am now rather certain, that the deterministic part is correct. It does not show any problems. I also checked the uv-mapping which had made problems before, but the directions look good, differences in the components are smaller than 10e-7 and I don't believe that to cause issues. So it must be something else in the sampling part. There is something strange though, when I switch off antialiazing the "triangles" are no longer visible. So I tried to render a image with stronger antialiasing and I have also changed to 64 instead of 16 rays. It looked very nice while it was rendering, but my system crashed before it was finished. I will try again tomorrow.

I know it is hard to believe, but I have finished the functionality to constrain the car to the track. I still had to fix some small bugs in the intersection functions, but now it is working. When the car leaves the track it is reset to the center of the track (or rather the defining line of the track, it can have different track widths to the right and left) and the speed of the car is set to 0. Additionally I had to change the heading of the car to the track direction. Else the car was racing towards the track boundary again.

I have also changed the camera following the car to always stay upright. So now the car is supposed to moved when the inclination changes. The current track has a constant inclination, so it does not change yet, but soon. Deviating from the plan I put forth last week, I will probably add a second track first, a simple oval, one side higher (so I have an upward and downward slope to test the addition to be made to the energy calculation) and with banked turns. Perhaps that leads to a bit more interesting track.

First few issues solved...

I have rendered the image I wrote about yesterday as you can see. The issues 1 to 3 are really gone now. The darker area on the left wall is the shadow of the box, I checked it.

The next issue (label 4 in the posts before) is with the Ward BRDF shader. The triangle in the lower right corner of the box is no longer as visible, but on the side facing right it can be seen and also on the top left corner. So I think there is still either a bug or the shader picks up something strange.

In the meantime I am also inclined to like the whitening of the lower left corner. I would be surprised if it was a bug. Something I still have to work on is the noise created by sampling. I fear I need more than 16 samples. I wonder if the renderings in the paper were really done with 16 samples, it never is stated explicitly.

I also fixed the first problem with the image. I have yet to render a full scale image to check, but the issues 1 to 3 seem to be fixed. There is something new which might be the shadow of the cube on the left wall, but I am not sure of it. Also the problem in the lower right corner of the cube (labeled with the red 4 in the image) seems to have been related to that problem and seems to no longer happen. But on the small image it is hard to tell for sure.