Development Journal of a Raytracer

I have finished with modeling a spoon today. I will post it tomorrow so I have the first object for December. The last couple of changes I made to the program worked very well in my opinion.

To finally get the Ward BRDF finished I am still missing some small things. One is that I can't control the number of rays used for the glossy part. It is part of a bigger issue I have to solve, how to specify the quality for a rendering. I have a very rudimentary implementation in my program, but I can only use fixed levels. I would like to be able to specify the parameters freely and also store and load them.

I started with adding a class I call "Quality Settings" which currently has four parameters:

1. Maximum Depth
2. Minimum Influence
3. Number of Glossy Rays
4. Use of Area Lights

The first parameter defines, how many levels we follow when calculating mirrored or glossy rays. The pathological example are two parallel mirrors, there will be rays which get caught and will never leave the pair when the camera is positioned correctly. The second is similar, for each mirrored, glossy or shadow ray I calculate an influence factor. It isn't precise, as the strength of the light source also plays a role, but it also is used to stop the calculations. E.g. a surface which is reflecting 10% of the scene will be rendered when directly visible shooting the ray, but if a glossy ray with low influence hits it, I can probably drop the reflection as the influence it has on the final result is unnoticeable.

The third and fourth parameters control features, the number of glossy rays directly influences the sampling noise. And finally area lights can be approximated with a single point light, which makes test renderings much faster. I think with time I will add more of that kind of parameters. But it should be enough for now.

I thought about what I wanted to do and how I wanted the Free Edit Modifier to behave. And I have come up with a rather simple idea. I used this modifier to create the head of the tea spoon, the problem was, that I kept moving the vertices around, I wanted to only move them along the y-axis. So I don't need to add code to somehow realign the work plane as I had thought (and written yesterday), I only have to make sure, that the constraints are honored.

And that is much simpler. I have implemented it and think it should work. Only movement is affected, I might be able to also add it for scaling. Rotations are completely different, though. But I will first play with it and try to use it, if it works I might go back and also add it for scaling.

Today I was very tired, so I only did a bit of testing. The changes to the movement code seem to work quite nicely, I only had added a small bug, the saved files couldn't be loaded again. It was only an oversight, I fixed that bug already. So next is the Free Edit modifier, it will get changed a bit. Currently it always works in screen space, but that is not necessary, I have come to the conclusion, that it should work in the other available (world and object) spaces too. I will have to add a bit of code to find the plane of the current coordinate system best matching the screen plane. That plane should then limit the movements. I think it should work quite well and the changes should be quite limited, but I will only know after implementation if it really works as well as I hope.

Today I wrote the rest of the code. It seems to be working well, moving of multiple vertices is in the program now. It is also incremental so that the files should stay small. There are still some weaknesses to select items, as it wasn't of big use before, but for now it has to do. I will try to model with it and see, if it is good enough.

Today I started to add a class which is supposed to handle one single segment of the track. But I have just started and already doubt, if it is right what I am doing. Currently a segment is a very short, straight piece of track. Every curve and even longer straight parts are segmented into multiple parts. For the curves I need it for geometrical reasons, for the straights for texturing. I also need many parts to form slopes.

Perhaps it would make sense, to define a structure even higher up in the hierarchy which breaks down the segments when needed. It would make defining tracks much easier. But there is also a good argument against it, the current way to define the tracks is only for testing, in the long run I want to draw them in the editor and then I don't care, if the export writes a data set for a curve or 20 for the segments to form the curve. So it might be a nice structure, but it is not clear if it is a good idea to even implement it. And I think, at least currently I should continue the low level structure.

I am slowly working my way through this stuff. I am still quite tired from being sick, so it progresses even less than normal. But I have now added the function to get the movement vector. Now I only need to change the editor function and it might work. I will have to see, how I can integrate the new stuff into the existing function.

I have most of the stuff done to move multiple vertices. The editor recognizes the condition, the command is created, added and even executed. The only problem is, that nothing happens as I am actually missing the movement. The code currently looks for the nearest point on the surface to the point where the mouse is and sets the one vertex it can move to that point. That is necessary to move a single point on a surface, but not to move multiple points, because now I need something else, a movement vector. I don't see an easy way to turn what I have into what I need, so a bigger change might be necessary. I will see tomorrow how to solve that problem.

Then I only have to make the command incremental as I did with the one to move a single vertex. I will follow the same pattern, so it shouldn't be a big problem to add that, once the code is working.

I am still sick, but at least I was able to continue a bit with the Draw On Plane-modifier. The commands to move a vertex now get recorded into one internal object which should result in much smaller files. Also undo/redo should be much faster as they always have to execute all the steps done to the object and moving the same vertex 10 times in sequence is slower than doing the same thing in one step.

I have also started work on the command to move multiple vertices. The internal object is already finished and tomorrow I will try to introduce the command object and the handler in the editor. I hope to solve this problem tomorrow or on Wednesday.

I am sick today. But I managed to get a bit done before it became too bad. When using the Sweep Constructor I had noticed a bug. I put the path together using two 2D paths and movements for one of them didn't work when the grid was being in use. The problem is, that for that path I have to use a projection which turns one of the coordinates.

When moving a vertex in the grid I calculate a raw movement based on the mouse movement. I then project it into the 2D plane which is actively selected. Then I have to evaluate the movement for the grid, so I am looking for the nearest grid point of the sum of the old possition, the movement and a stored value, the movement differential. That will normally not result to the point the raw movement would have led to. So I take the difference of those two positions and store it. To the next incremental movement that vector, the movement differential, is added before doing the mapping to the grid.

Storing the movement differential is very important, if it is not done the movements become very choppy and it is nearly impossible to control. The saved differential means that many small movements into one direction accumulate and after some passes the vertex jumps to the next grid position. But for the path where one of the directions is mirrored it means, that I move into the wrong direction. I tried to compensate for this by negating the direction to move the vertex. But that does not work, the stored movement differential also has to be negated. It took some time to find out, what was wrong and make the changes. But now it should work ok.

I looked into the last big problem I have with the Draw on Plane-modifier. As I wrote earlier I plan to add the ability to move multiple points at once. But first I want to get a stupid problem fixed, the modifier stores a lot of unneeded state when I move a single vertex. I actually have done the first changes to solve that problem and they nearly work, I need only one more call to tell the modifier something changed. Then I need to change the command object a bit and it should be ok.

Using that stuff as base I will add the necessary code to move multiple vertices. I will still need the old stuff, the Draw on Plane-modifier shares a lot of common code with another modifier, the Draw on Surface-modifier. That modifier is used to draw onto a surface formed by the geometry of another object. And there I don't have a good idea how to move multiple vertices, as each vertex has to be projected to the surface. The problem is the projection direction, I had not really a good idea I could implement and so project along the ray which passes through the mouse pointer. I have written the movement code so, that you can only move a vertex when the mouse pointer is right over it. Only that way the projection is controllable, it is already hard enough. But I don't have any idea, how to do that in a sensible way for multiple vertices, so that modifier will still have to use the old code.

I had the intention to finally interpolate the up vector of the sloped parts of the track. But when I looked at the data structure I quickly decided it wouldn't be right. The data structure I use to describe and handle the track is not good. I have never sat down and actually created a comprehensive structure, so I have three structures. The first is the list of track points I use to specify the track. It contains a point, a left and a right width and the inclination, at least currently. The second "structure" is the object I pass to the scene graph to render the element. I don't use it in any calculation afterwards. And finally I have a list of planes to do the intersection tests.

I think I should create a structure which contains track segments. That would make some calculations easier and I could store information I continuously recalculate. Also it would make calculations independent from the data structure I use to specify the track. I will have to extend that structure to contain additional information like what texture to use or if I want something like a crash barrier created at the sides. I could also separate the visual width from the width usable by the car so that it could leave the track a bit.

Also I still need to make the calculations to find where the car is located more efficient. It is very wasteful to search for it on the whole track. With vehicles you generally expect it near the spot you last saw it, they don't vanish and reappear on different parts of the track. And I think it is generally a good idea to put some of the calculations into its own class.

So I will next refactor the code. And then gradually add new features, first the interpolation of normals and then fitting the texture better. Currently each segment gets the full texture, irrespective of length. This is quite expensive (as I have to use many short segments instead of one long segment) and looks strange when segments of differing lengths are used. I also want to add a guard rail, but I would like to do that by specifying some values and let the program create the geometry.

Today it is hard to write what I did. I fixed some last issues with the stuff from yesterday I had found while modeling a bit. Also I started to add the ability to move multiple vertices at once to the Draw on Plane-modifier as I finally need it urgently. Yesterday I have started modeling a spoon to extend my collection of cutlery and made a bad error at the beginning. The head is way too long, so I would like to move quite a number of points. But currently the Draw on Plane-modifier only can move one single vertex at a time. The problem is not only the amount of operations I would have to do, but also that the relative position of vertices would get lost. So I need to be able to select a number of vertices and move them at once. With that addition (and a change made possible by it) I should finally make the last change to the modifier in my tries to modernize it, I hope.

I tested the alignment change I did for groups and it was indeed wrong, the transformation was inverted. So simple to fix and now it seems to work as I would have expected. I played a little bit with it and it is working great. Exactly what I have missed for some of the objects I did in the last weeks.

Then I fixed a small issue with the grid, the shader program was not reset and so it didn't work correctly as my Phong Shader doesn't handle all OpenGL options of textures, only those I use in polyhedra.

And finally I again tried to define a wall and this time it worked. I have changed the sweep modifier to handle the case that two vertices are at the same place so I can't accidentally crash the program. When the grid is active it can (and did) happen that a vertex snaps to the same position as another vertex. I still have to fix a little handling problem with the sweep, though.

I also tried to subtract a box from the wall and put a window into the hole. And even that worked very well. I will try to post an image soon, but I need to make some more changes first. I have not added a ceiling and you can even see it, also there is nothing outside the window and I believe that is the reason it is mirroring the scene, it doesn't look completely wrong, but still I would prefer for something to be visible through it. And finally I need to change the light setup. As I don't have any kind of global illumination the scene doesn't look so good.

I think I have implemented the alignment operation for groups so that I can put the origin so, that it is where one of the included objects would have it. I can't be sure, the example I used was bad, I have to try with a group defined so, that I can actually find out if it is correct. The trick was, to transform the groups origin and at the same time the object pointer with the inverse transformation. That way nothing moves as long as the group is only used once, but that is something I think I can live with. The biggest part of the work was moving the object pointer to the point I need it.

The alignment stuff is now working. At least the most simple case with the default implementation for all objects using the objects bounding box. I have also started with a specialization for the group, I want to be able to tell the group to move the origin to that of one of the included objects. There an additional problem arises, I would like the object pointer to move in the opposite way so the object overall stays in the same place. I actually need that last case quite frequently, e.g. when you group a door, the handle and the hinges into one object, you want the point of rotation in the hinges and not in the center of the three objects.