Entries by Josef Meixner

Some days late, I totally forgot about it yesterday, but here is the review of February.

Today I implemented the rest of the code to finish the still open problems. The edge loop now has a nice little label to show the direction of the edge being split. That way numerical control is possible and I already played a little bit with it and it works quite well. The biggest problem was to add some form of minimum size for the label. The code I had written was completely ok, but it didn't work.

At the time I thought I had done something wrong and tried some other things, but in the end I found out, that the multiplication of a vector with a matrix was wrong. It didn't use the values of the fourth row. Normally not a problem as the usual affine transformations have a last row consisting of 0, 0, 0, 1 and that can be ignored. But as I had to transform a vector by the projection transformation it resulted in wrong results, as that matrix has a very different last row (it is not an affine transformation). So in the end I found a very, very old bug and made the program a bit slower, but at least now it works.

I have continued a bit on the edge loops. It is always quite some work to get something into the OpenGL-renderer, as I have to be careful to not bind the modeler core to OpenGL. I hope to finish this thing tomorrow and then continue with the room to finally create some renderings for the socket and the light switch.

It might sound excessive to go to such lengths to get some renderings for two small objects, but I had problems to do those renderings quite often in the past. So I want to finally fix these problems so that I can create the necessary models more easily in the future. The features will be useful in future models, I am very sure of that.

Last week I didn't do anything, but at least this week I have started on the code to create the geometry to handle the track textures. The first function I need is to define where I have to put the slices. When I started to add it, I noticed there was something missing, I had not added some form of sanity checks, so even completely useless definitions could make it into the algorithm.

To make it at least a bit easier I decided to first check the slices. There are a number of conditions which have to be met. E.g. there has to be at least one slice, at least one slice has to be flexible in width and if there are fixed alignment positions they have to be in a rising sequence. Also the first slice has to either be anchored to the position 0 or at least be able to fill the track all the way to the left edge. The same is true for the last slice, it has to be able to fill the track to the right edge.

I hope, I can implement all the checks next week and perhaps even start on the distribution algorithm.

I am back at where I was before I started to implement the shader operator. I guess for now I will try to implement what I have currently and then see, how to fix the rest of the problems. So as the default model of the Channel Material is now nearly a working version (I didn't define the shader to use, I basically have an empty container), I hope to finished the preprocessing step and then implement a simple OpenGL-version of the material. It will just create a texture and then use a Phong shader.

Edge Loop

I added a new UI-control to show the length of the edge being split. So now only the second part is missing, adding a transparent quad with a texture with a "+" and a "-" on it to show in which direction the edge will move.

Channel Material

I have defined all the necessary pins for the shader model. When doing so I also thought about the next steps and there are some problems. One is, that the raytracer uses quite different data and for example handles antialiasing whereas the OpenGL-renderer doesn't. I will have to think about a way to handle that, I only have an idea at the moment. If possible I would like to avoid to implement the operators twice, once for OpenGL and once for the raytracer.

Continuing with the channel material is not as easy as I had thought. The problem to finished the preprocessing step is, that the output operator had the wrong pin-type. For some reasons the shaders need to output quite some data so I can use it in the raytracer. So I had to add a new pin type to represent that. And now I first need to implement a component turning color into shader output. I could obviously just leave it at the color pin I use now, but honestly I would not like to write much code I will very soon have to throw away.

So I decided, that I will add an adapter to the list of operators which will use the shader models I have for my other material class and make it usable for the Channel Shaders. I always intended to add that so I can at least use some of the code I have written for my older, simpler system.

When I tried to use the result of the Edge Loop-modifier I found out, that something didn't work correctly. I obviously didn't get the correct length of the edge. When I today looked into it I found out, that the Change Geometry had a bug, when an edge was split multiple times it didn't correctly record that in a map. So I fixed that, although I already knew at that point, that it won't be the correct solution. But it is a very important class and so fixing problems with it is also very important.

In the meantime I have found an easy way to get the length of an edge. I could destroy it if I made a change in the future, so tomorrow I will add a comment to explain that. But I am still not finished, there is one more problem. I can't see, where the edge starts, so if I want to split an edge close to the middle, I can't tell if I use the right length. I think I will add a small helper tomorrow which shows a texture with "+" and "-" so I can immediately tell, which direction is which.

Today I also worked on the HTTPD. I have extended the response- and request-classes so that the request can tell the response, that the client (i.e. the browser requesting a page) can handle compressed pages. As the evaluation, if a client understands compression is costly, I added a virtual function to the response so an implementation can inform the request, that it can't compress the contents and so it doesn't have to look into the header. Currently the error response doesn't return any data, so it obviously doesn't need to support compression. The same would be true of binary data like images, but I haven't defined a response to handle that yet, currently I can only send texts.

I have finished the changes to the Edge Loop modifier. It now works mostly as I expect it. There is a small issue where values only change after the scene is refreshed I don't quite understand, but it doesn't look too bad to use. So tomorrow I will finally try to use it for a real model.

I was so lazy yesterday, I haven't done anything at all. Today I have continued with adding the Channel Material to the OpenGL-part of the program. The first step to use the Channel Material is to evaluate the graph of operators and build some structures. As I know, that the graph has no loops as I simply don't allow them (the program currently doesn't make any checks if there are any, though), I can evaluate the operators in a sequence, so that the input values of any operator are available when I evaluate it.

That means the first structure I need is a list of operators. This list defines in what sequence the operators are evaluated. As it only contains operators reachable from the output operator, it also means that I can add as many dummy operators as I like to the material, evaluation will not suffer. I think that is an important aspect as it allows to play with alternatives.

The second structure is the size of the necessary state. The state is the sum over all output values and the input values to the channel shader. The input values are things like the uv-coordinates, the 3D position and the normal of the point where we want to evaluate the shader. What the evaluation step has to do besides creating the list of operators is to tell each operator where it shall store its output and where it can find its input. All inputs which are not connected will receive a default position to read, so a pin for 2d-coordinates will receive the original texture coordinates. For channel types where there is no input, e.g. the color, I will create dummy places filled with some default value, e.g. black for the color or 0 for the intensity.

I have also continued a little bit on the channel material. I have started to create the OpenGL-version of the materials. I know I wrote previously that I would start with the Raytracer, but I noticed, that the first steps have to be done in the core and that is much easier to do with the OpenGL-version. So I have started with the class and will continue until the common stuff works. I haven't decided if I will then just fake the shader, e.g. paint the object gray or do a bit more, e.g. create a texture and use the Phong shader or the OpenGL fixed pipeline Gouraud shading.

The code is working now, at least in general. I still have to fix some issues, the code currently doesn't notice changes done directly in the graphic. I will try to get it fixed on Friday. I need that code to continue on the "simple room" model I have started. To make it possible to put items into the walls I need some structure where I want to put items (because of the limitation on my CSG implementation). I used simple boxes for the four walls, and I would like to put edges at certain heights, so I can cut out the hole for a window or door or to put a socket into the wall at a fixed height over the floor.

I had some other things to do today, but at least I am back at the code I wrote on Sunday. I also extended it a bit into the direction I am heading and am now rather certain it is the right direction. So hopefully I will manage to implement it tomorrow.

Yesterday I started with a small change I still haven't finished. The edge loop modifier, which splits quads will get a way to define the split point numerically. As I am able to select the loops, I can add a UI for it. I want to have two ways to specify the point where to split, as factor of the edge length and in physical units, e.g. meters. I didn't think it would be a big problem, but I got a bit tangled up in all the ways I can define UIs. I think I now know, how to do it and will try to fix it tomorrow.