Development Journal of a Raytracer

Today I was totally lazy and basically didn't do anything. I looked a bit into the terrain stuff I wrote about yesterday and found and fixed a spurious bug. I thought about how the UI should work for the feature I intend. I guess a context menu would be best, just the vector graphics editor doesn't have a facility for that, yet. I guess that will be the next thing I will implement for the UI.

I worked a bit on some different things today. First I changed the interface for evaluation of the tiled material. I had put the parameter "slope" into it and have now exchanged it with "normal". It is trivial to get the slope from the normal, but vice versa is impossible. And the normal seems to be a useful bit of data for conditions, e.g. snow will stay much longer on the side of a hill facing north.

The second thing was that I started with the feature to combine two ISO-areas of the terrain editor. When I first found out I needed that feature I had no idea how to implement it. In the meantime I came up with a way. To combine two areas it will be necessary that two consecutive vertices of area 1 overlap with two consecutive vertices of area 2 and obviously that the areas have the same height value. Then the two vertices of one of the two areas have to be selected and then the program can search for the other area. If there is a longer line where the areas overlap then the excess vertices have to be deleted one by one. I haven't even started programming this feature, I only created a test case so I can try the code as soon as I have the first bits.

The third thing I worked at was the depth of field thing. In principle I slice the image into partial images where the distance of the raytraced image from the camera falls into a certain interval. Then I recombine those slices with some blur, the farther away the slice the stronger the blur. On Wednesday I finished the code which creates the slices behind the focal plane. For performance reasons I have to do slightly different things for objects in front of the focal plane to those behind it, I started with the part behind. Today I started on the step recombining the data. It still is some way from being finished, but it is at least progressing.

As I am now able to import rather complex objects I should be working at the scene file format so I can import the positions of objects. I plan to separate the two things. But currently I don't want to spend time with that part, but do a bit more with Java3D.

So I decided I will start with the "avatar". As it is supposed to become a racing game your "avatar" in the game is the cockpit of a car, I want part of the steering wheel, the dashboard and the mirrors to be visible. I started modeling that element in my program (and no, I won't post it, it is still way too ugly) and hope to soon have something which at least looks a bit like a car interior. As I couldn't wait, I exported the object and loaded it into the Java3D program.

At that point I found out, that I hadn't thought about supporting transparent materials. It isn't complicated, you just create an object of type TransparencyAttributes, use BLENDED as type and 1.0f - alpha as the transparency. That object is passed to the Appearance with setTransparencyAttributes. And so the problem is fixed.

I have worked on the new idea (I haven't specified yet) for a simple way to fake depth of field in the last days. It is still some way from working, as I have spent only some minutes per day on it. I hope to finish it by the end of the week and present the results and then describe what I am doing. It is nothing exiting new, I only try an algorithm which is used in GPU shaders, I just think I had an interesting idea to make it fast (probably not on a GPU, though). I will see if it works.

The filters should be fully working now. I didn't test them yet, but I don't see where I could have made an error. The currently implemented filter is similar to the one I had before, but there are small changes which will make conversion from the old to the new system impossible. At least if the intent of the conversion is that the output will be the same. I think the new filter is the better one as it is more logical. The old one used world coordinates of the hit point as input to Perlin noise, the new one the uv-coordinates scaled by the number of tiles. The new filter now uses exactly the same function as the distribution does and I think that is good because I can use similar parameters to get similar results.

As I don't really care so much for the exact same images to be generated, I will make a best effort to conversion and then leave it at that. So now I have to test the filter, implement the conversion and then remove tons of old code and I am really finished with this.

Today I mainly continued on the tiled material. The filters are nearly finished only integrating them into the raytracer is still missing. The problem is, that I need to pass considerable state through some functions and I want to check it I can make that easier than adding it to some abstract functions and burdening many functions on passing the values through.

Due to a distraction (taxes) I didn't have a lot of time today to work on my program. I opted to do something different than the last weeks and added a small switch to remove the renderings of light sources and cameras from the OpenGL renderer. I was actually trying to start modeling the skirt for the character and loaded my base model. Then I turned the model a bit to find where to start and was instantly annoyed because from a good view point to plan the mesh I was only seeing parts of the character as a light source got into the way.

As that happened in the past far too often I decided that I will first add a small setting to switch them (and the cameras with them) off. That way I can model with the models lighted and still don't get them into my way all the time.

The other thing I have started is a new try at depth of field. The last try was a disaster, but I think I have a new idea which might work. I will try to implement it and then write a bit more about what I am doing. It will be another try at faking it, though, not the real implementation.

The rendering had a second bug. I still don't know where it is, I think the code did the right thing and only the way the UI presented the list of conditions is wrong an so I didn't model what I thought I had done. To test if it would work when the conditions were used in the right sequence I changed the code. The image doesn't look very good, so I won't post an image, but it seemed basically correct. It seems I should match the brightness of my tiles.

The second thing I did today was implementing the filters. They aren't added to the raytracer yet, but the UI should work now. And the first filter also should have all the information the old one had. So as soon as it is working I should be able to implement the conversion from the old to the new model. Then I can throw away a lot of old code.

I have a bad headache today so didn't really want to do a lot of programming. But I looked briefly into the trouble with the tiled material and I even found the reason why the result didn't look like what I had expected. It is rather simple, I had added the ability to connect to a source for heights, but forgotten to actually use it, so the height was always set to 0 when evaluating the tiled material. I will fix that tomorrow.

Today I fixed the last few problems with the export function. The first was that I hadn't set a proper bounding volume. All objects in Java3D have a bounding volume and some tests I did when I started to use it seem to imply that they have to have them or they aren't rendered. So I just created a bounding box from the coordinates I read.

The second issue also wasn't a big problem. I added an object which "owns" the read data. I write the owned in quotation marks because in Java it is technically not possible to own an object as it will stay alive as long as any pointer to it exists which is in use, directly or indirectly. But my design can still define ownership and so this new class basically is the object I plan to use in the higher levels to represent the low level 3D object and allow access to its transformations. As the objects I can currently read are always rigid I called it "RigidObject".

The third and last issue was memory related. I had created a class which reads the XML file and turns it into the 3D object. While reading the file I have to collect information which I don't need when the 3D object has been created. To make usage easier and also make sure, that the memory is reclaimed as soon as possible I made all member functions private (even the constructor) and gave the class a static function expecting the filename and returning the finished object. As that function is the only place where a reader object can be created I can control the life time of those objects and can be sure, that the last accessible pointer is removed when the static function is left. The garbage collector then will sooner or later collect the memory and reclaim it.

I did some minor changes and then started to test the tiled material. As often I right away found some bugs and fixed them. I also found out, that I need to add two things, first an ability to delete components so I at least have any chance to fix something I did wrong and second the ability to move components. The first one should be fairly simple, the second one could get interesting, but I don't expect big problems.

I also rendered some example images, I guess I overdid the tile size so the tiles near the camera get a bit big. Also I am not convinced the interleaving worked so well, I have to check that.

But at least the code is working again. Fixing some bugs is not such a big issue as rewriting big parts without a chance to even see anything it can produce.

I now should have all the code to handle doubles with the new abstraction. I made the interface to create an UI identical to the other kind of variables, the AniVals, so I can easily move code from one to the other. One feature is still missing, they don't support to inform another object when they are changed. I will add that tomorrow and then start on implementing the support to get the normal from terrains so I can continue with the tiled materials. I will try to render an image using the new stuff with the terrain I posted some days ago before I start on the normals. I hope it goes well and I can again use it to render some images.

Most of the issues I was not able to finish yesterday have been done today. I am still missing the UI-bit of yesterdays "invention" of the new variables I call "UIVars". But that shouldn't be hard to implement. The other thing I did today was to define a new interface to the textures used only by objects querying for the terrain data. That interface can not only produce the heights but also the normal on the terrain at an arbitrary point of it. Currently those functions aren't implemented yet, but I need them for the tiled materials as I will add a condition for the slope soon.

So I am still not finished with this thing, but I am still sure it was for the better of my program.

Today I first finished the implementation of the tree control in the Qt-UI. So the UI for the tiled material is now again working in both variants. I also implemented the height condition. But I haven't finished the integration of the height sources yet.

The reason for that is a bit complicated. To be able to access different kinds of height sources I added an abstraction considerable time ago. Its principle scope is even wider, it is supposed to abstract access to textures, though it isn't used in that way yet. One of the problems was, to integrate images with objects like the terrain. In principle the one has colors, the others heights. So they have to be mapped somehow to make sense. And there I made an error, the users of that abstraction currently have to have an additional pair of values to scale the textures. For the terrains it doesn't really make sense to use that facility to rescale the data.

As each of the users now has to know quite a lot about the sources (abstracted into an interface, so there are basically only two cases, but still), it means quite some duplicated code. So I came to the conclusion that the texture abstraction should do the scaling on its own. When I started to add that I hit on another long lasting problem: it is easy to use animatable values in my program, but hard to use values which aren't supposed to be animatable. In principle I could make all of them animatable, but for some values it just doesn't make any sense. E.g. the number of tiles in a tiled material is inherently unchangeable as changing them would result in the tiles moving quite uncontrollably over the terrain, changing their appearance at the same time. The same is true for the scaling in the texture. I don't see it as making any sense to only have that ability for textures and not terrains, so if I want to have it, I think it only makes sense as an additional value for users of the class.

So today I finally decided to do something against that problem and started a new abstraction to make using constant values (constant in the sense that the animation time has no effect) as easy as the animatable kind. I am right in the middle of that, so couldn't finish with the tiled material today. But I am sure the consistency which will result from the steps just described will be worth the time.

I worked on the tiled material most of the day. I fixed some hard to find bugs and now I am fairly sure the currently implemented condition and the distributions are working. I have also added the handling of the height source (I can use different objects already), though there is still a small problem with the UI. Currently the height source is not used in rendering, I will have to add that tomorrow. Also I haven't added any filter yet.

The Qt-UI now is also working in principle, only one small thing and it should work as well as the MFC-UI. So it still looks like I might get this thing to a working state this weekend. The two parts missing in addition to the two items from above is another condition I have started but not finished (as I need the height source stuff first to even have a chance to test it) and the conversion of old material definitions stored in files to new ones.