Development Journal of a Raytracer

I have also finished adding antialiasing back in. It is now much cleaner as before and easier to understand. So now the program can do what i could do before the change, just the structure is much better to aid in further improvements. So I call this project finished and remove it from my todo-list.

Today I started with the first changes to the raytracer so I can make it faster. The area I worked at is not at the core algorithm, but close, it is the part of the program which handles creating of rays, storing the results and anitaliasing. I need to rewrite that part to implement packet tracing, make the raytracer multithreaded and finally to add true depth of field. So an important step which kept back three big things, two which should make the raytracer much faster.

I had planned to do this for some time, but as I started I dropped the ideas I had developed and went with a different idea I think is better. Basically I create a new class and some derived classes which handle the sampling. That way I can just create a new class if I need new features and encapsulate at least part of the necessary code into those classes. Where I still have problems is, how to implement antialiasing.

And finally I worked on the blossom. I think I will call it finished, I originally intended to give it even more structure, but that would have been much harder. I think it would have been faster to start anew instead of changing the thing I had started with.

I think all in all it isn't bad. It really resembles a flower, the end of the petals is slightly wrong, but I think I will leave it like it is.

I had written about the ability of Visual Studio to incorporate rules to define custom build steps. In the meantime I have found out, that this feature is also part of Visual Studio 2005. It worked quite nicely, only the dependencies were not working as expected. The rule calls a tool which creates a HPP-file with the same base name as the input file. That files is then included into a C++-source file, so the build step should only happen after I changed the shader file and then the C++-file should also be translated.

But it didn't work like this. The tool ran with every build and the C++-file was not rebuild, so I had to build twice after a change to the shaders. Today I finally found where the problem was. One of the properties of the build rule is the output. A short help text says, that it is commonly set to "$(InputName).<new extension>" and that is, what I also used (I obviously used .hpp as extension). As the dependencies didn't work as if the output file never existed I guessed, that I had not specified the correct file. As the file name was correct, it could only be the directory and that was indeed the case. It seems, that the default directory is the intermediate directory where the C++-compiler places the obj-files. So today I changed the output to "$(InputDir)\$(InputName).hpp" and then it worked. This is really a nice feature, if only the documentation wasn't that terrible.

GLSL Phong Shader

I have found the problem with the textures. It was as I thought, you have to copy the texture coordinates in a vertex shader. Then the texture appeared, but it was not lit very well. It seems, that the gl_FragColor-variable used to set the color of the fragment shader is always clipped to 0.0 - 1.0. So I now collect the color in a variable, then do the multiplication with the texture value (that is all you have to do if you only use GL_MODULATE as texture environment) and then put the value into gl_FragColor.

Regular fixed functionality pipeline

I also finally made some screen shots. The one at the top is with the new GLSL shader, the one to the right is with the fixed functionality pipeline. I think you can clearly see the difference, the images used exactly the same settings and were not edited.

With the Phong shader you can see three highlights in the sphere from the three light sources, whereas the fixed functionality hardly shows the strongest and it doesn't look good. Also the spot light lights the plane with the Phong shader, in the other image there is no hint of it on the plane at all. Finally near the right lower corner of the plane you can see the difference in diffuse lighting. With the Phong shader it is much more defined and clearly circular. In the fixed functionality there is not much definition remaining.

Granted, I "cheated" a bit by using a big quad, if the plane used many more vertices it wouldn't look as bad with the fixed functionality. But the basic problem remains, the spots would appear but they would be much more diffuse and highlights with high specular exponents would need a very fine geometry. And somehow I have the impression that the shader is by far a more efficient solution than creating more geometry.

I didn't get far today. First I was trying to find out how to access a texture in a fragment shader. I use the OpenGL Superbible as reference and although there are examples of how to use textures in shaders, there is one aspect missing, how to associate the texture engines to the samplers. The samplers are variables in the GLSL shaders which can be accessed to get a value from a texture. The program (on the CPU) has to connect them to the shader engines and it is totally simple, from there a sampler is simply an integer where you put the number of the texture engine to use.

Parallel to that I reformatted the shader code three times and ended up with the original version. I needed that time to find out how to best integrate the texture stuff. It is still not working, but I am sure I will find the bug. It looks as if it uses only one texture position, I will check first thing tomorrow if I have to pass the texture coordinates through the vertex shader.

As I am finally able to play with the GLSL shaders, I am slowly making progress. I have implemented both of the things I wrote about yesterday, the specular highlights work and also the parameters for spot lights are evaluated and used, correctly I think.

The results are great, I can now say that even diffuse lighting profits from a fragment shader. I used a large plane made of one quad and there you can see the light painting a circular shape where light and dark meet. With the fixed functionality it never was circular as the linear interpolation results in a line as separator.

The specular highlights look really great. It should be much easier now to create a good light setup for the raytracer as the results can be previewed better. The same is true of spot lights. I can finally judge their influence by looking at the picture the GL-renderer creates.

Now I have one last feature to implement and then some clean up work. The feature still missing is the ability to use a texture. It shouldn't be hard to add that as well. The clean up is necessary as I want to encapsulate the functionality to create and maintain a GLSL-shader and I want to move the current shader out of the material so I can use the same shader in multiple materials.

Today I finally found out, what made the program crash the display driver. It wasn't the shader program at all, it also crashed when I created just a box using the fixed functionality. There seems to be an issue with 64bit mode in my program. I don't know yet where it is located, but it is interesting that the raytracer didn't seem to have issues. On the other hand I indeed do some low level stuff in the OpenGL part to setup buffers. Possibly there is a bug in the program in that area, it will be "interesting" to find in any case, I fear.

But running in 32bit mode my shader really worked. It currently only does the diffuse part of the lighting calculations, but now that I know that it works, I can add the specular part as well. And then I want to add support for spot lights. Those two should benefit the most from the shader, the diffuse part looks a bit better (I think), but the difference (if I am not imagining it) to linear interpolation over the vertices is pretty small.

But for specular highlights the difference should be clearly visible, as there linear interpolation is not really resulting in something which is even near the real results. And on coarse geometry the highlights frequently have no effect at all as no vertex is close enough to the highlight. Something similar happens with spot lights, if no vertex of a face is hit by the light cone, the face simple doesn't get any light from the spot light.

Today I continued with the Phong shader. It should now handle the ambient and diffuse parts of lighting. Specular is still missing and I haven't added support for spot lights either. I got the shader to compile correctly, but I still crash the graphics driver when I execute my program.

I think PerfKit might help me, it should be able to print a message when I do something wrong in OpenGL. But either I misunderstood or did something unusual, it is no longer working. From the website I had the impression, that under Vista you no longer needed the instrumented driver, but it doesn't seem to be possible to activate instrumentation. It worked before, but I installed an updated driver since, so I guess there either is an instrumented driver installed with the PerfKit or I was just unfortunate enough that something strange happened. I guess I will tomorrow reinstall PerfKit and hope to get it to work again.

I wrote the little tool to turn text files into strings today. It seems to work nicely, I even added support to escape quotation marks and backslashes. They shouldn't appear in shaders, but I will probably also write comments and there it would be possible. So it is better to have them handled correctly. I also wrote the tool so, that the backslashes linking the lines to one long string are all at the same place using some tab-characters. That is something I always do for code which generates texts which I might have to look at to find problems.

To turn the sources into the strings I also added a new rule to Visual Studio. It is quite easy to do so, once you have discovered it. If you add a file with an extension VS doesn't know how to handle, it presents you with a dialog box asking if you want to create a build rule (at least VS 2008 does, I don't know if 2005 had that option also). You can also access the build rules via the projects properties. There you can define how to handle files with that extension, what the command line is to translate them and what the tool will create. That way even dependencies work correctly and if you need more control you can even define your own property pages which will appear in the properties of a file using the custom rule. The rules are finally stored in a file you can distribute if you work in a team. A nice feature I only discovered by accident.

Today I did two things. The first was starting a handbook. Even if I have no intention to publish my program, I slowly need a handbook so I can look up how things work. For some weeks I have been looking into DocBook occasionally. I would like to use Eclipse to write the texts and then convert it into HTML-files.

I tried to find a nice free editor for DocBook, but have failed. So I guess I will have to try in XML, it shouldn't be too hard, I hope. I had started to create the necessary framework to handle DocBook and today I tried to do the rest. I created an Ant-build script and started with the documentation. I want to use modular DocBook files as I feel it is easier to handle that way. I tried with entities first and it worked, but then I can't use the DTD in the files really containing the texts so the XML-editor of Eclipse can't help me to create well formed documents.

The solution for that is XInclude, then you can use an XML-preamble and a DTD. But I don't get it to work. My knowledge about Ant is about zero and I have big problems to find out, how to tell the parser to switch on XInclude.

The second thing I "worked" on today is the management of my little tools. For the little benchmark between 32bit and 64bit code I wrote a simple timing utility. It has a couple of lines, nothing fancy. But I still would like a place to put it. As I need another of those tools, I today created a svn-repository for them and placed the timer thing in it. The next tool I need for the shader code.

I want to include the basic GLSL Phong-shader in the executable so I don't have to worry about finding an external file. I started by putting the shader source into a string literal. But it turned out to be a problem to make sure, that it stays a valid string literal. Writing something down is not hard, but making changes is. So I decided I will write the shaders into their own files, have them processed by a small utility to turn them into a valid string literal and then include that into the CPP where I really need it.

I continued with my shader. The support code is now working, I am able to load a shader and compile it and finally link the vertex and fragment shaders together. So the basics are done. I even managed to crash the OpenGL driver with it, it seems it doesn't like to get empty input.

I have also started to write the Phong shader. The vertex shader part I need for setup is done. The fragment shader is more of a problem. I want to use the old fixed function data as much as possible so that the program still stays compatible with an implementation without shaders, as my laptop has such a card. Therefore I plan to use the material and lighting parameters OpenGL uses in the fixed function pipeline. The first problem I have ran into is, that I don't see any way to access which of the light sources is active. It seems there is no equivalent of glIsEnabled(GL_LIGHT0). I think I will introduce a bool array with that data and try to finish the shader. If I later find out there is a way to query that information, I can hopefully integrate it.

I finally started to look into shader programming. For my raytracer I have some simple (and some not quite as simple) shaders, but I have never written one for the editor. I wanted to do a HLSL shader for some time, but somehow never did. So today I read a bit about them and started to add the code to use them. I will start with a very simple Phong shader.

I know, that you can download Phong shaders, but I still want to roll my own. The first reason is so I can learn something, it is easier to start with something from which I know, how it works and is simple. The second reason is, that I can create the shader exactly how I need it, leaving out things like fog or color sum, which I don't use. And the third reason is, that I would like it to behave similar to my raytracer shader. That way I hope I can judge from the OpenGL-representation how the finished image might look.

The second shader I would like to write is for the terrain. I would like to transform my tiled material into a shader. It will not look exactly like the raytraced output, as I won't replicate the full set of features, but it also should give a good impression of how it looks when finished. But before I do that, I plan to write code which turns the tiled material into a rough texture image so that I can even see the general features with the fixed function pipeline on my laptop. That should be fairly simple and I think I can reuse parts of the code for the shader implementation.

I did some benchmarks today. I already knew, that the Opteron will gain speed if run with 64bit software as it has more registers in that mode which allows an optimizer more freedom. So I rendered the same model with the same settings and got these running times:

So in 64bit mode my program needs 10%-14% less time. But as I had written, that I had the impression that the program ran faster when I pinned the process to one core, I also measured that. The first two results were for free floating threads, the last two are pinned to one core.

In 32bit the program runs 15% faster when it is pinned to a core, in 64bit it is even a bit more, 19%. So running pinned to a core in 64bit is 27% faster than just executing the 32bit version. Quite a lot, I would say, like going from the 2350 with 2GHz to a processor with 2.5GHz.

I did only one run, so the numbers are not precise, but honestly if I can get 20%-30% more power by simply flipping a switch (that is basically all I had to do in Visual Studio to build in 64bit mode) and pinning the process, then I don't need precise numbers to know, how to run my program. I will see, if I can find out, which of the "CPUs" in the thread affinity dialog belong to one physical CPU so I can measure the difference of free floating threads with only one physical CPU. I still think, that the two CPUs make the problem worse when the threads move between them.

Today I finished "porting" to 64bit under Windows. Only the targets for the release (that is optimized) build were missing. I have added them and the program still seems to work. The next thing I plan is to time the 32bit and the 64bit version. I can be mistaken, but I had the impression, that the 64bit version was a bit faster.