Development Journal of a Raytracer

The sphere uses more geometry than before, but now the glossy reflections look very, very nice.

I was too tired today to actually create a new model, but as I see from the old test models I also don't need to. I like, how the bright copper colored spot on the sphere is mirrored on the plane, where it has a different form. Also I think it is very nice how the color changes from the dark color of the shadows to the bright green. Very nice, I guess I will use that shader a lot in the future.

But I also can't call the shader finished, with the second model the program crashes. The crash only appears with high rendering settings and without further information I have troubles to locate the point where it happens. In the debug version it is so slow, that I had to stop it without hitting the problem.

I will try again tomorrow, I will try to use the 64bit parallelized debug version. That should work quite fast and when it crashes I should be able to attach the debugger.

Model crashing the program sometimes.

But apart form that problem, the results also look great. You can even see the mirror image of the box on the floor. That is exactly what I had hoped for. And obviously that white corner at the lower right hand side was caused by the bugs. I also like how the brushed aluminium comes out, it looks much, much better than before.

I was too tired yesterday, but I had managed to get the program to accept linked materials. It was much easier than anticipated, as I seem to have taken out the asserts some time ago. I continued with it a bit today, the linked materials are now marked in the UI and the name of the master object is also displayed in the UI. And I started to add a button to unlink the material. That should be fairly easy to finish.

Then I need to extend the materials, they have to contain a list of the objects which link to them. I need that, so that when I change the material of the master object to a different shader, all the linked objects can be told to do the same. Technically that is not necessary to change the shader in all objects, it would be sufficient to make one of the other objects the master. But I think it will be easier if I have the correct links and only want to use a different shader.

I think I finally found and fixed all the bugs with the implementation of the Ward BRDF shader. The first one of today was simple, the paper had a small error, an arctan was missing from an equation. I found out because of another paper, Notes on the Ward BRDF by Bruce Walter. I tried it, but the result was mostly the same. I went through the calculations again and then finally saw, that I had forgotten a sin(theta) when I calculated the new half-vector. Fixing that resulted in a proper image (see the linked big image).

Now it is much closer to what I would expect, the circles are all gone and the specular reflections of the light sources have an area of glossy reflections around them. I am only missing reflections of not so brightly lit areas, but perhaps I need a different model for that. I also should rerender the images I have used before.

But I think, I am now really finished with the implementation of the Ward BRDF shader. I will wait until I have done some more tests before I declare it finished, though.

Today I started something new (the machine I normally use to work on the Ward BRDF was busy compiling updates for FreeBSD 8.0). With the chair model I had the problem, that I didn't want to assign the same material to multiple objects. I want to be able to create one material and link the others to it, so every change is reflected in all objects. I started to implement that and already have implemented quite a bit of it.

The hardest part starts when I have finished with implementing the things I started today. Then I have to test the program and I already know, that a lot of asserts will be firing. When I originally implemented the material handling I didn't have the idea to make it possible to link materials and so put in a lot of asserts which make sure, that the materials are owned by the object using them. I will have to find and fix those, removing them isn't enough, I also have to check, that the code is indeed working with the new design.

I have found and fixed some problems. But it still doesn't look as I would have expected. The circles have changed, they are now no longer circles, I think, the parts running into the direction of the camera seem too long for circles. As far as I understand, the green colored streaks should basically follow the specular highlights. The calculations are supposed to be related, the glossy rays are just modeling a surface which is not perfectly smooth (to the last atom). But as long as a material is mostly smooth (like the brass at the left side), it should mostly act like a mirror.

I found and fixed a tiny bug, but it didn't really change a lot, so no image to post. I think I know where the problem is, but I have to come up with a solution. The paper has an expression which will return results only between -90° and 90°. I believe it is supposed to deliver the values from -180° to 180°, that is the full circle. So I guess I already have found the reason for the half circles. There is a second component for the outgoing ray, an angle between 0° and 90°, I have printed some values and that second value always was very small.

Example image for Ward Shader (Image is linked to bigger version).

I have changed the scene a bit and now am sure that I have a bug somewhere. But first the positive thing, the specular highlights are very nice, they are really quite different depending on material. The floor and the three blocks have the Ward Shader, the rest is Phong. The left block is "rolled brass", the one in the middle is "enamel finished metal" and the right one is "white ceramic tiles", the floor is "varnished plywood" (per the Ward paper). I didn't bother to give the blocks a color, they are just white and the floor has a simple checker texture.

The left block also seems to show a bit of the ceiling (only visible very faintly in full image). But those rings on the floor are very strange. They seem to be reflections of the bright spots on the ceiling (where the point lights are, they are 20cm beneath the ceiling, 3.3m above the floor). I can't tell, if it would be correct to see only a rather thin, bright line, but I see no reason for them not being full circles. It seems, that only the left half is visible. I guess I have to have another look at the Ward BRDF Shader.

I have started a new model to test my Ward BRDF implementation, but I am not yet happy with it. I will try to add some more structure because I still don't get any glossy reflections. At least I thought so, but now that I write it and think about it again, I did indeed see glossy reflections. I thought they were specular reflections of the light sources, but that is impossible, because they were noisy and so have to be from the glossy part. I will add a bit more structure to a texture and then I will see, what happens.

It worked as hoped, the idea was good to use one random number generator to create the seeds for all the other generators. I have a bit of a hack in the code to get seeds for the pixels I use for antialiasing, but I think it is mostly ok. I didn't want to calculate even more random numbers, so I use the weighted sum of the four pixels around a pixel for antialiasing. That obviously is not a true random number, on the contrary it is dependent on the four closest values. But it should be good enough as seed, I hope.

With this the implementation of the Ward BRDF is formally finished, but there is something which bothers me, I haven't seen any glossy reflection yet. So I will try to create a new model and see, if I have another bug in the program.

I looked into the problems some more. First I checked pbrt (and so found out, that there will be a new version of the book quite soon) as it contains a lot of knowledge and I knew there was a chapter on Monte Carlo, so there had to be something about random numbers in it. It turned out, that they use the Mersenne Twister, the RNG (Random Number Generator) I also had considered. But it also has a problem, it needs some samples to create good random numbers, and needs to be seeded from another random number generator and generally seems a bad fit for what I am trying to do.

My current problem is, that I need a repeatable random sequence per pixel, so I need to seed a RNG for every pixel. In that case a RNG with high start up costs would probably hurt performance. As it has turned out, that taking the pixel coordinates as seeds didn't work so well, I thought about ways to make them look more random. E.g. by inverting the binary number so that neighboring pixels would get different values or by using XOR to combine the x- and y-values. Then I had the idea to use a precomputed array mapping the lowest 8 bits to random values and using those in addition to the original values.

But I think the problem can be solved much better and easier. There is absolutely no need that the values correspond to the coordinates, only that they are repeatable. So all I have to do is to take a random number generator and sample it once for each pixel and store that value. As long as I always seed that generator with the same value and generate the values in the same sequence, all conditions should be met. So I will try to implement that, it means that the generation of the seeds has to be moved to the samplers, but that shouldn't be a big problem.

I didn't have a lot of time today, so I didn't get to do anything big. But I at least tried something simple, running the random number generator some times (10 and 20 I tried) before returning the first value. It didn't change anything, the artifacts seem largely the same. I am slowly a bit hesitant if it is really the random number generator which has a bug and not perhaps the shader. Perhaps the issue was masked before?

I was fighting with the strange behavior of my random numbers. The problem is, that I have the impression, that the sequences look awfully similar. I printed the first five values the random number generator produces after being seeded and see a very high similarity in the first number and even the second and third numbers are still often quite similar. So I guess the problem is twofold, the seeds are not very good and the random number generator I use is not good either. I fear the problem is, that I have not enough hidden state. I will try to implement a random number generator with bigger internal state.

I have added the last bits and also connected the Ward BRDFs random number generator with the seed. The results are awful. I see a lot of repetition (how that can be I have no clue, except if the random number generator is broken) and when I changed the way I calculate the seed a bit, the pattern looked as if a second coarser pattern was overlaid to it. I will have to debug the stuff, but that won't be a lot of fun, debugging this kind of stuff never is easy.

I have managed to get the new struct into the program. I have also started to add the value to seed random number generators. I need to make a few more changes so that extension also works. It already had the effect of making some code a bit more regular. Two places still are not implemented, the first is where the seed is created (easy), the second is in the tiled material. It has to call the material functions of other materials and for some technical reasons it is not easy to pass through the data. I will get that fixed tomorrow.

The last bit is using the value in the Ward BRDF. That part will be very simple to implement. And then the Ward BRDF should be finished. I will create a test case with multiple objects, each having a different material setting, but I don't expect new problems.

Today I only did one boring thing, trying to get the new structure passed through to the materials. I am still not finished with it and I will probably still run into a problem (with the tiled materials), but it is making progress. I again have to make a very high number of changes. I think I will finish this thing tomorrow, though. Then I can finally start with the real work why I am doing this, passing a start value for random number generators for each ray being rendered.