Development Journal of a Raytracer

Socket

I have finally rendered some images of the switch and the socket. The socket didn't come out too good, it is not easy to light it well, it seems (and the light setup was done in a hurry).

Light Switch

I have only used the single frame, I will soon post an image with the dual frame being used to combine switch and socket. I think the objects are quite nice.

So this month I managed to finally post them. So at least in March I have created my small objects, though the geometry has been finished for a very long time.

I have been working on implementing some additional operators for the Channel Shader. I am not very enthusiastic to implement a shader which I can use to render a solid surface with a Phong model in the raytracer. So I have added two new operators, the first was a simple switch operator, it gets an input with a value between 0 and 1 and is supposed to select one of three inputs it gets from shader models. The second is supposed to create a tile pattern. It uses two tiles and one gap between tiles. I decided to use two tiles so I can define checker board patterns. If I don't want to use that I can simply connect the same shader to two inputs of the switch.

The operators are implemented far enough so the editor works, but the tile shader is still missing a lot of its state. I have to implement that and also both shaders have no working evaluation function. But even in the current state it has helped to find multiple bugs. I had one in the UI, I allocate a font-object and had not released it. After moving some shaders in the editor the program crashed and was caught in a loop. As the structure is a bit more complex I also for the first time tried to save and load the model and found quite a number of bugs in the serialization functions.

And finally the switch has uncovered a problem in the design. As the switch is, at least currently, never blending the inputs, it only needs the values of one of the inputs. But currently always all three are calculated. As the inputs can be arbitrarily complex I need to find a way to only calculate the actually used parts. E.g. if one of the inputs was created by a Ward BRDF shader firing 64 rays per pixel and was only used in 1% of the cases the raytracer would be very slow while throwing away most of the work.

I have found out, where the problem with the socket was I encountered yesterday. There are two problems and the combined result was what had me confused. The first problem was, that the reference object I have written returned the wrong transformation when it got more complex and that led to the situation, that I had a CSG-difference where no single intersection was occurring.

The second problem was, that some defaults are wrong. When I subtract an object from another object which it doesn't touch, I would expect to get the original object. When it is a union of two objects I expect to get both objects in the case they don't touch. But in my program the default is to drop those faces which I can't qualify and when no intersection occurs I cannot do that. So together with the first bug it resulted in no geometry being created at all.

The first problem I have fixed today, the second I will try to fix tomorrow. I have also rendered a first image of the socket, but it is not yet usable. The socket came out way too dark (or probably the rest is way too bright). But it finally starts to look as if I might actually get some rendering done this month.

Last weekend I had started to define an interface to allow me to stream strings directly into responses. Currently I haven't defined a response with that interface. Currently there is only one interface which uses a std::stringstream to collect the data. I have changed my current test program to use that interface for now. It seems to work.

The next step is to define the first response which implements the interface and is able to store the data directly into send buffers so that most copy operations are eliminated.

As part of looking for some bug in the CSG implementation, I extended the diagnostics I had created for the polyhedron a long time ago. It only allows some limited access to the internal data, e.g. it will show me the edge numbers used by a face and allow me to jump to one of the edges to check, which faces use it.

Today I only extended it a bit, but I think it makes it much more useful. For faces the face normal is now also printed, before it was only drawn into the model as a short line. Also lists containing edges now not only show the edge number, but also the two point numbers. And finally lists containing vertex numbers now also show the coordinates. Only the face normal is new, the other information was available before, but it needed some clicks to find it, so now it is just more condensed.

When I was adding the reference object I noticed a problem with the CSG-operations. Sometimes a face was flipped, something I had seen before. So I tried to understand what was happening to finally fix it.

It took very long, as it was not clear, where in the CSG operation something failed. After adding some debugging code I could locate the bug in the function splitting the faces. I found out, that sometimes the face normal of a part being split off from a face had the wrong normal, it was the negative of the expected value. So I started to look at the function doing the splitting. There I couldn't find any obvious error either. So I again added debugging code to find out, where the face normals were changed.

But that still didn't help, I found out, what caused it, but somehow the code looked correct and the only case which might have the effect (which I think also is handled correctly) would have been impossible to handle differently. So I basically made the debug code part of the algorithm so the face normal would be flipped when it was wrong. But that still had not the desired effect. Two faces now had completely wrong normals.

And then I finally found out, where the problem was. The function calculating a face normal for a list of points is wrong. Sometimes it came up with the zero vector. The problem is still not solved, I only made it more unlikely. I have not yet a good idea how to fix it completely that is cheap, so if I don't get a good idea I will have to add something quite expensive. For now it is working.

But the socket still doesn't interact well with the wall. I tried it and the wall vanished completely. I still have to check what is happening this time. I sure would finally this stuff to just work.

I have managed to finally get the material into a working state. There are still many issues I will need to solve in the future, but for now it should be good enough. So next is adding the stuff into the raytracer so I can actually start to use it.

I added the final bits of code and now the evaluation is finished. So to complete the implementation for OpenGL I need to turn the image into a texture and map it to the object. I will also have to add some code to some functions I use to query information, e.g. if the material is transparent or generated and has to be refreshed when the geometry changes. So I hope to get it working tomorrow.

I didn't get anything done today. I am still trying to work my way through the alignment of the slices. At least I think I have finally found a way to evaluate them and have written some comments of how to actually implement that stuff. It isn't exactly easy as I have chosen a rather complex specification. I am not sure I will really need all the available features, but when I defined the DTD it seemed useful to include them.

Today I wrote most of the functions to "evaluate" my simple default shader. It will just fill the entire texture with a constant color, so the implementation of the operators was easy. So what I was actually fighting with was the code to get the operators to do something. I am nearly finished, only one small item is missing, reading the result and storing it in an image. The rest is pretty standard, I need to take the image and turn it into a texture, that is code I can just copy from other parts of my program.

One of the things I added yesterday was not correct. I had to break a loop and did it wrongly, it used knowledge about how the CSG-modifier works. But it is not guaranteed, that all users of the class work in the same way so today I fixed it correctly.

Also I added a setting to not pass on changes to the modifier. When something complicated happens, the program gets very slow to react. E.g. if I use a cylinder to cut a hole into a box and want to move the cylinder, it is very hard to get it to look right when after each slight movement the program takes some moments to recalculate. I guess currently the problem is the debug code, but with complex objects it will always be the case. So I added a setting to switch the notifications off and added a button to explicitly send one. So hopefully the thing is usable now.

I have indeed managed to finish the implementation of the object. But a first test has already shown some limitations, the object now directly fires off change notifications and that makes fine tuning something quite hard. I guess I will add a switch to enable and disable that behavior. I hope I can now finish the scene to show the socket and the light switch.

I have also worked on the Channel Material in the last few days. Nothing big enough to write about, though. Today I finished the next part, the operators can now create small objects to contain all the data they need for evaluation. The general design is from my raytracer, I use it there to return the candidates for the hits. There I only evaluate as much as absolutely necessary and defer all the rest to later stages.

And that is also the case with the material. In the raytracer I want to spend as few time as possible with searching in maps or evaluating the current state of an animated value and for the OpenGL variant it is probably not as critical, but still makes sense to speed up evaluation.

Next is the actual evaluation of the operators. For the current operators it shouldn't be much effort to do, basically only one will get an implementation and that one returns a constant color.

Nearly finished with this thing (apart form the graphical selection). Today I added the code to evaluate the references and attached the object to all the objects in the two paths. That way I can pass on any movement. What is now missing is the conversion of the old system to the new, the last bit for the change notifies (the CSG modifier has to pass a callback) and finally changing the CSG modifier to use the new system. Then it should work, I hope to finally get that done tomorrow.

I indeed had a very simple idea of how to fix the potential undo-problem I wrote about yesterday. It needed quite long because I had to change another central template and so had some complete recompiles until I got it working as expected. But now I am entirely happy with the code. So tomorrow I will try to implement the rest so it finally works.