Development Journal of a Raytracer

Nearly didn't make it this month. I had some problems with my netbook (spilled some liquid over it on Friday, I still have to clean the keyboard, I was just too frustrated to do it today) I use for modeling. But I still managed to finish this wall clock. The wall is a bit dark or rather the exposure is not correct (slowly my models behave more like reality, so I should use my photography skills).

I think it came out very well. There are still some problems with the clear cover you can see in the image to the right. Where the surface has a vertex there is some disturbing reflection. I think I have to do a bigger change to fix that, I think the best way would be, if the object wasn't a polyhedron at all. I should directly render the object as a rotation surface made from a spline. That way there would not be any hard edge.

But I think I get much better at modeling and defining materials. Both images are linked to bigger versions.

Today I finished most of the selection framework for the Channel Material editor. It is now possible to select an operator and the selected operator is indicated by a red frame around it. I needed to write quite a bit of code to get that implemented, but I still hope I get the framework stuff (or at least most of it) finished tomorrow.

I haven't worked a lot on the Channel Material today, but at least I have started to add selections to the material editor. The editor component is mostly finished (easy with copy and paste) and the next step is to create a class for the selections and make the material return those selections. Then I need to implement a transform function and some mouse handling. And then moving of the operators should work.

I have been working on a wall clock for some days and Wednesday tried to do the hands. I used a real wall clock as reference and like the hands, they have a small ring where the axis runs down to the motor. I would like to add a similar ring to my hands and found out, that I couldn't easily do it. I had started to model the hands as a rectangle, but my program makes it very hard to create a ring in that way. Fixing that would be quite hard, so I intend to do it in an easier way.

So today I extended a special constructor for 2d elements to be able to create a ring. Nothing big, but I will try tomorrow to get the hands fixed by starting with a ring and then add some rectangles. I think it should be fairly easy and then I only have to paint the face and should be done with another small object.

I think it was a good idea to model two small objects per month. That way I at least use the program regularly, get a lot of small bugs fixed, get ideas for small missing features and even get some objects.

Finally a day where I did get some stuff done. I have finished defining the DTD for the track texture files. I have also created a very simple file containing only a single very simple track texture (basically it will result in the same texture I have been using all along). And I have started to write the SAX-parser to read the file and turn it into Java-objects.

Next week I will try to get as far as possible in implementing the parser. I don't know if I can finished it, but it is possible, the file format isn't very difficult. Then I will have to write the functions which create the track segment so they match the specification and apply the textures.

And now the input pins are also drawn. I have also refactored the code so that the input and output pins get drawn by a common function. Next I will start with some editing functions, first is selection of the operators and adding a visual indication of which one is selected. Then I will probably add moving the operators and add a property dialog. At that point it will finally make sense to add some data members to the two operators I have.

I still haven't decided if I will use a fixed grid for the operators and channels. It might make it easier to create a pleasing image of the material setup. I think it is important to be able to create diagrams which can be understood easily and I know, that I find it distracting when in a diagram items don't line up.

And the next incremental step is done, I have defined the class for the input pins and added the function to the operators to get the information. I have not managed to add the input pins to the draw function, but only actually drawing them is missing, the code already calculates the size requirements and leaves room for them.

I will have to clean up the code, though. The draw function slowly gets too long, so I will try to split off some parts. I think drawing the pins can be put into a common function, at least currently. It might change in the future, but then it will no be much trouble to duplicate the function. So again I work on something which is not interesting at all, the stuff I am currently doing is boring standard code, but without it, this thing will not work. I hope I get the boring stuff done this week.

Today I got the output pins rendered. It looks quite nice and so I will start with the input pins tomorrow. That should be enough then for rendering operators and I can continue with adding the other stuff. First will be the input pins of the material (e.g. for the color, alpha value or the bump mapping). I will just render some input pins at the lower edge of the window. Then I will add the feature to create channels and make it possible to connect input and output pins.

Somehow this Sunday was shorter than the last one. I didn't get to do a lot, but I have continued a bit on the Channel Shader. There is now a second operator, one which will turn color (RGBA) into intensity. I need it to also implement the input pins. So technically I wouldn't need it currently, but I wanted to have a second one.

I also added a class for the output pins. And I added a function to query the output pins for drawing. I want to be able to group the pins, I don't know if I will use the feature in the end, but I think it will be easier to remove than it would be to add if I started without it. So tomorrow I will try to get rendering of the output pins into the program.

Slowly the Channel Material takes form. I have done quite a lot of the necessary steps to get an editor going. The material now creates one operator so the editor at least has something to draw. The operator is drawn as a small box with some texts. Nothing big yet, but at least working. The next thing to do is adding the input and output pins. Then I think I will add the channels (basically connectors between pins) and add the capability to move operators.

And then I think four things will be missing, a way to create operators, making it possible to delete them, make it possible to remove a channel and finally allowing access to the options of an operator. Then the stuff should work well enough to start with integrating it into the renderers.

I have continued with the Channel Material. There is now a first operator, but it is still mostly a stub. It is supposed to return a single color, but currently can't even store a color. It also has no output pin so couldn't deliver the color to any other operator. But I need to start somewhere.

I also started to define the vector graphics based editor. I hope to get it to open in a very basic form tomorrow. As soon as the basics are working I can start to extend the operator and add the rest to get a simple version working. Then I need to create the OpenGL representation and also the raytracer needs to be able to handle it. I think it makes sense to put those in front before starting to define more complex operators.

Today I started on the next issue. I want the track geometry and the track textures to be separate. That way I can define a track and don't have to watch that the vertices match the textures. The same is true of the textures. What has to be done is to map the textures to the track, eventually creating additional geometry.

I have started this by starting to define a DTD for the file containing the definitions. A track texture will be made out of multiple slices. E.g. there could be five slices, which define the left edge, the left side, the center, the right side and the right edge. The edge and center slices would be of a fixed width to make it possible to define graphical elements, the left side and right side slices would basically repeat to fill the space to handle different track widths. The program would need to create five vertices at the start and end of a segment and create five quads. Each quad would then get a texture mapped to it and the texture coordinates and wrapping modes would be set so that the texture fills the track.

In the last few days I have done a bit of modeling. The CSG-operations still have some bugs, one resulted in a crash. Today I investigated where the problem was and found out, that there were some small issues I never had handled correctly. The first was a stack overflow, the code tried to substitute an edge with the parts after it had been split. The strange thing was, that the edge was split into itself and a second edge. That is absolutely impossible, so I checked where that came from and it was quite easy, the split point was the end point of the edge. Obviously in that case the operation shouldn't do anything at all, I only had forgotten to handle that case (and naturally I now also check the start point).

After fixing that bug, it still didn't work. I ran into a second bug, very similar to the first one. This time the code tried to create a face from two vertices. The two were even the same vertex. I haven't fully fixed the problem, I fear, but the case which led to it was better handled much earlier. It turned out, that something tried to split a face, for that an edge-loop is necessary and the edge-loop was composed of one point appearing twice. That means it was attempted to split a face along a vertex, which obviously is not possible. After fixing that one the operation worked, though some faces were flipped and I still have no clue where that comes from. But as it is easy to correct manually, I won't look for that bug, at least not now.

I am sure there are more bugs along that line, but this time all of them were in the Change Geometry. As I have made that class an important implementation detail which is used in multiple places, it is very good to find and fix them, as it immediately can fix a number of modifiers.

I continued with the Channel Material. Nothing exciting, only laying down the base classes. I think the next thing to implement are the first operators. They will be more than simple, I will implement operators returning constant values. But that also means I will implement the first output pins. And I think I will then start with the graphical editor to "draw" the materials. With the first operators I should be able to at least start with it.

Today I finally started with the new material I wanted to create. I call it "Channel Material" (I couldn't think of a better name and believe me, I have tried). The base idea is to connect various operation with channels. One of the channels will then give the final color and a second will return the depths for bump mapping or displacement mapping. Some simple operators would just return the same color for each call, others might evaluate a texture image and still others could use a noise function.

But I intend to also implement much more complex operators. The first real test case will be a operator for simple tiled surfaces. It will have to create some tiles and fill the area between the tiles with e.g. "mortar". I intend to give it a bit more parameters so I can also create masonry or wood flooring in the end. It will have multiple output channels, one for the color, a second one for the depth information and probably a third one to control, which BRDF to use.

It will be some time before this thing works, but at least I have started to create it. I hope, that it will prove powerful enough to do a wide range of materials. I also hope to get it implemented efficiently, I think it is possible to do the evaluation with a dataflow architecture so that the channels don't cost a lot of time by evaluating the same operation multiple times.