Development Journal of a Raytracer

It has been forever that I really worked on the HTTPD, I have sometimes done some small stuff, but mostly to get it compiling again. Last weekend I managed to update my SuSE 11.1 installation to 11.2 (astoundingly the updater really works) and it finally seems to support my system well enough that I can work. The network is detected with the right speed (in 11.1 the network came up with 10Mb/s) and even my audio card works again.

I am still at the point to add compression to the HTTPD, but I first added something else. As I want to write web services in C++ I need some support to make it easier to create pages. The first addition was, to have a class which creates the HTML-header (containing the DTD, the title and so on). I will extend it later so I can also pass the location of CSS- or JS-files, that way I can write it down correctly once and don't need to remember or look up how to do it. Yes, I know I am lazy.

With that I extended my first test page to contain a bit more text. Next weekend I will try to finally add primitive support for compression.

I continued with the changes to the editor. Today I worked on the way I move the camera. I have a button to move around a selected object. Basically I get the difference in x- and y-coordinates the mouse has moved. Then I rotate around the selected object along the y-axis and use the x-difference to govern how far I move. After that I rotate around the object in x-direction using the y-difference in mouse coordinates. That way the up-direction mostly stays upright and it is rather easy to use and works quite well.

But all my buttons in that location react to left clicks with movement and to right click with rotations. So I had not really had a good idea of what to do with the "Rotate Around"-button on movement. It was set to behave like another button, but that wasn't good. Today I finally changed it to do the same as the rotation, but it rotates around its own origin, so it only turns the camera, but doesn't move it.

While doing that I noticed, that my rotations were too fast. That wasn't any new information, but it had never been important enough to fix. But today as I was working at that place I just fixed it and added handling of modifier keys similar to the one of movements. If I move while holding shift the movements get slower, holding the control key makes it faster. So I added similar handling to rotations, now I should be able to control it much better.

I have also finished the other camera setting, I now can define a speed factor for the movements and the focal length (I only allow three fixed settings, 50mm, 35mm and 24mm equivalent to 35mm film). I even added a new setting to define the center of rotation for "Rotate Around" when nothing is selected. So I will have to use the new stuff and see, if it is useful.

I finished the change from yesterday. Now the OpenGL render function has an additional parameter to request transparent rendering. I also implemented it for the polyhedron class. So this should be finished now.

Then I started with the addition of the changes to the camera. First I reworked the UI I already had for settings which are specific for a model. There was quite some clutter I had to clean up. I also started to implement the factor to make it possible to adjust the speed the camera moves. For the camera angle I can't implement a simple setting. Instead I have to get the camera object of the system camera and ask that one to show a usable editing interface.

I hope, that these additions will help me to model. Also I really enjoy not working on the channel shader. I will return to it soon, though.

I reworked the stuff I did earlier in the week. I now actually allow it to specify, if an ObjectPointer is rendered normally, transparently or not at all. To implement that I had to drag some old code out into a file of its own and had to do quite a lot of changes. But now it compiles (and hopefully works). So next is actually changing the OpenGL-rendering functions so I can really instruct objects to be transparent. A lot of changes for a small feature, but I am very sure it will benefit the program. It will solve some problems I had for quite some time without having the right idea of how to solve them.

Today I only refactored the code I already had. I had tried to come up with a better way to store the track textures, but I didn't find any. So I simply moved the once internal enumerations and classes from the SAX-parser and made them top-level classes. So now I should really have all the information ready and should be able to implement the code to turn the track information into properly textured geometry.

Yesterday I decided it was time to finally get the socket into a model so I can get my two models of the month posted. I decided it would make sense to create a simple room model I can reuse when I want to post images which need a room. So I created one and then had some problems. One was, that it is hard to work with the scenes if you have a closed space. The other had to do with the camera.

The first of the problems I have started to fix. Long ago I implemented switching off objects, I use that often for editing, but it also affects the raytracer, so I have to remember to switch all objects back to visible before rendering. And so I simply added another setting which is supposed to hide the object in the editor. While implementing it, it appeared to me, that it would make more sense to not hide the object, but to make it transparent. I haven't fully implemented that as I have no parameter to tell an object to become transparent, so currently I tell the object it is selected, which at least has the effect of becoming transparent for the polyhedron class. But I guess I will extend the interface to allow me to switch the objects transparent as it is probably better.

The problem with the camera is a bit different. I somehow have the impression, that the image is looking too small, not as if it was a real room, more like it was a tiny model of a room. I have no clue where that comes from, the camera angle should be set to 90° which should result in a natural view. I simply have no idea where the perception comes from. Perhaps it is linked to the second issue, I think the camera moves way too fast when I move it. I will try to solve both of these problems by adding settings so I can define the view angle for the modeling camera (for the cameras used to render the scenes in the raytracer that was possible for a very long time) and to define the speed of movement. Perhaps then the effect will vanish?

I have finally added all the code to add channels. I guess I will ignore further work on the editor and finally try to implement the stuff into the raytracer so I can soon play with it. I finally want to do other stuff, this thing is exhausting me.

I also continued a bit on the channel material. The selection was changed and I have now all the information to create the new channel. The next step is adding the command and the code to actually add a channel. There is one issue I still need to fix, only one channel can be connected to an input. So when creating the command object I have to check, if there is already a channel and create a second command to make sure only one of the channels is used.

I worked a bit with the socket model today and found and fixed two problems. The code I added to the groups to add objects didn't account for the transformations. It is still missing another one, but for that a bigger change would have been necessary and the change I made today covers the current case.

The second problem was, that when material was being linked, it was no longer possible to store. It also wasn't a big change, but now it should work.

It was a very lazy weekend, I didn't do anything yesterday and today wasn't much better. I looked briefly into the code to add channels and found a new issue. The selection has a little problem, I currently only make the pins selectable when the operator is selected. I will have to change that, but I don't think it will be a big problem. So I am still working on the UI of the channel material.

More of the boring stuff. Now the pins can be selected, though there is a small problem, where the operators and the pins intersect the code only returns the operators as hit. I don't see, how the channel materials code could cause that, so it is probably an issue somewhere in the vector graphics implementation. But with that limitation I was still able to implement quite a bit of the code to make it possible to add channels. When I right click a pin a rubber line is created which follows the mouse. What I still have to implement is handling the next click. If it is on a pin of the right type the code will have to create a new channel. And I have to implement some way to cancel the operation. But then I should be able to create new channels and the only thing missing will be deleting channel. With that the editor for the channel materials should be working well enough to continue with actually implementing the material in the raytracer.

I had no time today, so only a small change. I started to add the class which will handle the application of the track textures to the track segments. It currently is completely empty, but I have already added it to the SAX-parser. So next is adding some functions to set the data, some functions to format it and then the first part is done. The second part will consist of the code to create geometry for and apply texturing information to the track segments. That will again remove some functionality from the track class making that one simpler.

Today I have added the ability to select channels. The code is obviously quite similar to the operators. I have also started to add a selection for the pins. I plan to use a right click on a pin as the start of a command to create a new channel. The way I thought I could implement it is currently not possible, I would have to rewrite some code. But I think it is possible to implement it in a little bit different way. The only impact would be on the function evaluating the selections, but it shouldn't make a big difference there either. I will try that, not because of the little effort to change the code, but because the current way is more logical and therefor better.

Today I have finally added my first channel. The program can now manage the channels and draw them. Next is adding the ability to create new channels and connect them. Then I need to be able to delete channels (I will probably also add the code to delete operators, it should be rather similar) and change them.

I finished the improvements for the groups, they seem to work. There are some minor issues with transformations which are not applied (e.g. when an object is removed from the group, the groups origin transformation isn't applied and neither is the transformation of the object pointer). But those I consider minor, it can be fixed with some copy and paste for now. So tomorrow I will return to the Channel Materials.