Development

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.

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.

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.

Left is Lambertian, middle and right Oren-Nayar, the one at the right has higher roughness settings.

I finished the implementation of the shader using the paper from Oren-Nayar today. It isn't exactly spectacular, but it has some small issues which should result in more interesting images, I hope.

From the image you can see, that there is some difference to a pure Lambertian shader. I think I will implement at least one more BRDF, Cook-Torrence. Perhaps next weekend, the two shaders I implemented this weekend profited from being able to implement it in one go.

Today I have implemented a simple Lambertian shader. It was fairly easy and as I used the Ward BRDF as template I even found another stupid bug in that shader. I had accidentally applied a factor of 1/PI to the diffuse value twice. So the materials were often quite dark and the specular factors were too strong. I have rendered two examples and the images indeed look differently again.

I have also started to implement Oren-Nayar BRDF. I have added it to the editor and have started to add it to the raytracer. I still have to transform the formula from the paper into code, but hope to finished that tomorrow.

For once the "usual problem" of a wrong transformation wasn't the reason. Instead a forgotten transformation was the problem, the objects were all created correctly, but some where not put correctly into a grid and so were only partially rendered. It looked as if it was a transformation error, but on closer inspection it wasn't. Then I discovered another problem, also with transformations, two transformations were swapped. But it seems the code I have changed some time ago finally is correct, I just ran into two yet untested cases, but no general change was necessary.