Development Journal of a Raytracer

Tea Cup and Saucer. The Cup looks like a sugar bowl.

I did start on two more small items this week, one is even finished. The items are a saucer and a tea cup. The saucer is quite nice, but the cup is still missing its handle and it seems to be too wide. I have the impression I made an error when measuring a cup and then defining it. I will check tomorrow.

The height of the cup looks ok, it only is too wide. Still looks like a sugar bowl.

For the handle I plan to define a new constructor. The Rotational Constructor is a big success, it is fun to use and I can easily create the forms I want to. So I would like to have a second constructor similar to that one I can use for things like a handle.

This week I at least made a bit of progress. It still isn't working correctly, but I found some bugs and it seems to get better. One of the bugs I fixed seems to have led to the track no longer being visible. I think I had a normal wrong and "fixed it" by negating it quite some time ago. Now that I fixed the original bug the track is only visible from the back and so doesn't get rendered (backside clipping is on).

Also I found out, that I had assumed the track to be in the wrong direction. So when I looked at the matrix I mixed up the direction the car is going with the direction pointing to the right of the car. The effect is a bit funny, the car no longer flies, but instead of being tilted a bit to the left, the front is pointing upwards.

Both problems should be easy to fix next time I work on this thing. I might even finish this little part of the problem, who knows.

The plant objects are now also converted and I only have to change the raytracer functions calling the changed functions. It shouldn't be hard (in fact the main raytracer class in a lot of ways acts like a container object), so I hope I will finish with the conversion on Friday. Then the "interesting" part will start, debugging the mess I very probably made. Should it work I then can try to find out, if it also solves the problem with the release build of the raytracer when the Ward BRDFs are used.

I have been working on the hit infrastructure of the raytracer yesterday and today. I am only missing the plants and then all the object are converted. In the process I fixed some bugs or let's say problems which didn't manifest themselves so I would have set out to fix them. When the plants are converted I only have to change the functions which initiate object and shadow hits and it should compile again. Then I can test it, remove bugs (as I would be surprised if it was working without a problem) and see, how slow the raytracer has become. Then I will add custom memory management for some objects which are continuously created and destroyed with the change I am making. But first it has to work, then I will make that change to make it faster to not introduce even more hard to trace bugs.

As the first two small items I played with the new Rotational Constructor. I created two plates and think they are quite nice.

I hope I manage to model two more items this month, as it would at least one month I manage to keep to my plan.

I have also added the last bit, the grid texture can now be 100x100 pixels instead of 64x64 if the graphic card supports non power of two textures. I haven't tested the code, but I am fairly certain it will work. So now the Rotational Constructor is finished, see the second entry of today for some first uses.

The rotational constructor is mostly finished. The grid is completely implemented and working. After I finally had all the graphical stuff done it was rather easy and straight forward. I have now decided that the angle constraint takes precedence over the grid.

I don't call it finished for one small detail. Currently the texture for the grid is 64x64 pixels and that means that the distances between the lines are not all the same. It is the most compatible choice as all OpenGL implementations can handle power of 2 textures. What I still plan to implement is to check, if I can use non power of two textures and in that case make the texture 100x100 pixels. I think it is worth it as I can see the differences in distance clearly.

I am making progress with the changes in the hit infrastructure. It is taking quite some time and I often need to go back and add something I had forgotten. I think I have the interface right now so that I only have to go back when I discover I have made an error. The polyhedron is corrected and most of the containers are also fixed, from them only the distribution object is still missing. I still have to fix most of the object types and finally the main loop of the raytracer. It is quite boring stuff, but it also has some advantages, one is that the new interface is quite a bit simpler and that I can get rid of quite lot of code I no longer need.

I have added the graphical representation for a grid as well. It wasn't as easy as I had thought. I needed some tries to come up with a way to turn the parameters into a grid and to fix the rendering so it is usable. I am not finished with the rendering of the grid, but hope to get that working tomorrow and at least start at actually using it for the Rotational Constructor.

I have also started to change the raytracer in the way outlined yesterday to fix the problems with recursion and make the raytracer fit for parallelization. This will be quite a lot of work and as a number of basic assumptions will change I will have to do quite a bit of redesign to get all parts fitting together again. I have barely started and already ripped out half of the interface which was actually used in the inner core of the raytracer for hit processing. So this will be an interesting thing to do, I hope it also results in a bit better performance for complex settings, where objects are used multiple times. If they are only used once it might become a bit slower.

The next little feature of the rotational constructor is in the program. The constraint to an angle is working. It was a bit harder than anticipated as I found out, that I didn't have a clear idea how it was supposed to work. What I ended up with was to calculate the angle of the line after the current movement was done, calculate the nearest allowed angle, then project the moved point onto a line through the fixed point and parallel to the new direction. It is necessary to store the difference between the movement done by the user and the resulting movement. This last vector accumulates the movements orthogonal to the current target direction and will eventually change the target direction. This vector is simply added to the movement at the next loop through the algorithm.

I also have started with the last addition I plan to make, the grid. The variables to define the grid are in the UI (and are stored and loaded) and I have added a new function interface to have the grid drawn, drawing is what I plan to implement next, it should be fairly easy. Then I have to add the code to actually constrain the movements. I don't know yet what will take precedence when both the angular and grid constraint are used. So I hope I will finish this thing this week end.

Another week and I am still working on this stuff. The matrix has been fixed so I have finally made a bit of progress and the program again executes. But now there is a new problem, the car is floating into the air. It actually rises with every bit it goes forward. As I tried to create a car and not a plane, I think this is wrong.

I have traced the problem to the function doing the constraining. Something is wrong with the intersections, it doesn't hit the track segment under the car, but one quite a bit away. As I have defined quite a big inclination and I hit the track quite a bit away from the central line I get a high value for the y-coordinate. So the question is now, what is wrong with the intersection code. I hope to find out next week. (And some day I will manage to have a proper cliff hanger, this one is about as interesting as watching paint drying.)

I think I know what the problem with the release version and the Ward BRDF might be. I have one assumption in the program I already know doesn't hold in all cases and the point it crashes and what I see in the call stack hint into the same direction. I have tried to minimize allocations in the inner loop of the raytracer, but that has a problem, I can't handle recursion any longer, so when a ray hits an object, which sends out another ray which in the end hits the original object again some data can't be damaged. I assume that is what happens, the stochastic rays in that area hit the plane and the sphere multiple times. In debug mode it seems to muddle through, but the release build (fully optimized, no debugging code) crashes.

I already have been thinking about how to solve that issue, as it it one key issue with the parallelization I intend to do. There the problem is even worse, I don't even know for sure how much state I have to preallocate, so it won't work the way I implemented it in any case. Therefor I have been planning to change that stuff to use a custom allocator, that should make it possible to have low overhead and solve the current problem. It also should enable me to start with parallelization. In addition I will change something closely related to that which should speed up the raytracer (a rather simple space/time trade off).

I always forget to add new stuff to the list. So today I added for programming:

1. Finish the Rotational Constructor
2. Speed up the OpenGL representation of polyhedron

And for modeling I also have some points to add:

1. Finish Cat
2. Start Bunny

And finally I think I will try to add a new meta todo, create four small or one medium sized object per month. I consider the cat as a big object, the models I would like to create for that todo are supposed to be simple, e.g. a plate, a fork or a knife, mostly to get a bag of filler objects to put into scenes. A medium sized object might be a simple rowing boat, I think that should be possible to model in some hours.

On Sunday I have added the code to limit vertices to one half of the plane (so they can't cross the axis of rotation). I also started on the stuff to limit the movements of vertices to multiples of an angle. Most of the time I spent on adding UI stuff to the program, I want to only see some fixed values and don't want to allow arbitrary angles.

But now that I have finished that stuff, I am not sure how to continue. I never draw new vertices (they are created by splitting an edge in two parts), I only move existing ones and it is not clear to which of the (normally) two lines to apply the angle. I can't apply it to both, as that would limit the possible positions to two (and in many cases one). So I need to select the line and only one vertex, but selecting the line automatically selects the vertices. Perhaps I will change the code so it is easier to use this feature (e.g. optionally disable automatically selecting the vertices with the selection of an edge).