Tuesday, January 6. 2009
I haven't finished the distribution object. But at least I have done a big part of the raytracer integration. The initialization is finished, now I "only" have to implement the part where the ray tracing takes part. I don't expect problems, so hopefully it will work tomorrow.
Monday, January 5. 2009
The distribution object is now mostly finished. There are some small things I will still have to fix, but nothing big. The OpenGL-renderer of the object is also fully working. So all that is missing is the raytracer integration. The last big feature was the integration of multiple objects to be distributed. Currently only objects which know how to randomize themselves are supported. I am thinking about allowing arbitrary objects later. Currently the only object which can randomize itself is the plant. So to test the new feature I tried to create a simple plant. While doing so I found some bugs with the plant, one was showed a deep flaw I could fix. So tomorrow I will try to finish this thing and render some images.
Sunday, January 4. 2009
I think I have all the necessary parts of the distribution object in the model now. The OpenGL-renderer is still missing one feature and then I will have to add it to the raytracer. I have one problem in the model I can't fix currently, I hope it won't result in problems later on. I have thought about how to write the raytracer object and think that I know how to build it. The problem is, that an implementation using the model of the group-object would waste a huge amount of memory, but I think I can handle that problem.
Saturday, January 3. 2009
I continued work on the distribution object. It now has an OpenGL-representation and I added the code to randomize the positions. I haven't added it to the raytracer yet as I want to make one bigger change before I do that. Currently only the positions are random, I also want the rotation of the objects to be random. That means I have to change some data types which form the interface and I think for now it is enough to see the results in the OpenGL-version so I only have to change one user of the interface.
Friday, January 2. 2009
I had a lazy day today, so not a lot of progress on the new object. I think I have most of the parameters and have written a simple algorithm to distribute the instances. Next is to create a representation of the object in the GL part of my program so I can see, if it works. Then I have to add it to the raytracer. After the basic things work, I will have to work on the distribution function, it currently would create a rather boring distribution (regular grid). Then that is working I will have to switch from positions to matrices to define, how and where the instances appear. The last part will be support to have multiple objects being used so that I get a bit of variance.
Thursday, January 1. 2009
Today I started the implementation of a new object. This object is supposed to distribute objects randomly over an area. I intend to use it to distribute plants. Most of the "infrastructure" is done, I hope to get it into a working state tomorrow.
Wednesday, December 31. 2008
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.
Tuesday, December 30. 2008
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.
Monday, December 29. 2008
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.
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. 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.
Sunday, December 28. 2008
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.
Saturday, December 27. 2008
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.
Friday, December 26. 2008
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.
Thursday, December 25. 2008
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.
Wednesday, December 24. 2008
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.
|