Development

Today I was totally lazy and basically didn't do anything. I looked a bit into the terrain stuff I wrote about yesterday and found and fixed a spurious bug. I thought about how the UI should work for the feature I intend. I guess a context menu would be best, just the vector graphics editor doesn't have a facility for that, yet. I guess that will be the next thing I will implement for the UI.

I worked a bit on some different things today. First I changed the interface for evaluation of the tiled material. I had put the parameter "slope" into it and have now exchanged it with "normal". It is trivial to get the slope from the normal, but vice versa is impossible. And the normal seems to be a useful bit of data for conditions, e.g. snow will stay much longer on the side of a hill facing north.

The second thing was that I started with the feature to combine two ISO-areas of the terrain editor. When I first found out I needed that feature I had no idea how to implement it. In the meantime I came up with a way. To combine two areas it will be necessary that two consecutive vertices of area 1 overlap with two consecutive vertices of area 2 and obviously that the areas have the same height value. Then the two vertices of one of the two areas have to be selected and then the program can search for the other area. If there is a longer line where the areas overlap then the excess vertices have to be deleted one by one. I haven't even started programming this feature, I only created a test case so I can try the code as soon as I have the first bits.

The third thing I worked at was the depth of field thing. In principle I slice the image into partial images where the distance of the raytraced image from the camera falls into a certain interval. Then I recombine those slices with some blur, the farther away the slice the stronger the blur. On Wednesday I finished the code which creates the slices behind the focal plane. For performance reasons I have to do slightly different things for objects in front of the focal plane to those behind it, I started with the part behind. Today I started on the step recombining the data. It still is some way from being finished, but it is at least progressing.

I have worked on the new idea (I haven't specified yet) for a simple way to fake depth of field in the last days. It is still some way from working, as I have spent only some minutes per day on it. I hope to finish it by the end of the week and present the results and then describe what I am doing. It is nothing exiting new, I only try an algorithm which is used in GPU shaders, I just think I had an interesting idea to make it fast (probably not on a GPU, though). I will see if it works.

The filters should be fully working now. I didn't test them yet, but I don't see where I could have made an error. The currently implemented filter is similar to the one I had before, but there are small changes which will make conversion from the old to the new system impossible. At least if the intent of the conversion is that the output will be the same. I think the new filter is the better one as it is more logical. The old one used world coordinates of the hit point as input to Perlin noise, the new one the uv-coordinates scaled by the number of tiles. The new filter now uses exactly the same function as the distribution does and I think that is good because I can use similar parameters to get similar results.

As I don't really care so much for the exact same images to be generated, I will make a best effort to conversion and then leave it at that. So now I have to test the filter, implement the conversion and then remove tons of old code and I am really finished with this.

Today I mainly continued on the tiled material. The filters are nearly finished only integrating them into the raytracer is still missing. The problem is, that I need to pass considerable state through some functions and I want to check it I can make that easier than adding it to some abstract functions and burdening many functions on passing the values through.

Due to a distraction (taxes) I didn't have a lot of time today to work on my program. I opted to do something different than the last weeks and added a small switch to remove the renderings of light sources and cameras from the OpenGL renderer. I was actually trying to start modeling the skirt for the character and loaded my base model. Then I turned the model a bit to find where to start and was instantly annoyed because from a good view point to plan the mesh I was only seeing parts of the character as a light source got into the way.

As that happened in the past far too often I decided that I will first add a small setting to switch them (and the cameras with them) off. That way I can model with the models lighted and still don't get them into my way all the time.

The other thing I have started is a new try at depth of field. The last try was a disaster, but I think I have a new idea which might work. I will try to implement it and then write a bit more about what I am doing. It will be another try at faking it, though, not the real implementation.

The rendering had a second bug. I still don't know where it is, I think the code did the right thing and only the way the UI presented the list of conditions is wrong an so I didn't model what I thought I had done. To test if it would work when the conditions were used in the right sequence I changed the code. The image doesn't look very good, so I won't post an image, but it seemed basically correct. It seems I should match the brightness of my tiles.

The second thing I did today was implementing the filters. They aren't added to the raytracer yet, but the UI should work now. And the first filter also should have all the information the old one had. So as soon as it is working I should be able to implement the conversion from the old to the new model. Then I can throw away a lot of old code.

I have a bad headache today so didn't really want to do a lot of programming. But I looked briefly into the trouble with the tiled material and I even found the reason why the result didn't look like what I had expected. It is rather simple, I had added the ability to connect to a source for heights, but forgotten to actually use it, so the height was always set to 0 when evaluating the tiled material. I will fix that tomorrow.

I did some minor changes and then started to test the tiled material. As often I right away found some bugs and fixed them. I also found out, that I need to add two things, first an ability to delete components so I at least have any chance to fix something I did wrong and second the ability to move components. The first one should be fairly simple, the second one could get interesting, but I don't expect big problems.

I also rendered some example images, I guess I overdid the tile size so the tiles near the camera get a bit big. Also I am not convinced the interleaving worked so well, I have to check that.

But at least the code is working again. Fixing some bugs is not such a big issue as rewriting big parts without a chance to even see anything it can produce.

I now should have all the code to handle doubles with the new abstraction. I made the interface to create an UI identical to the other kind of variables, the AniVals, so I can easily move code from one to the other. One feature is still missing, they don't support to inform another object when they are changed. I will add that tomorrow and then start on implementing the support to get the normal from terrains so I can continue with the tiled materials. I will try to render an image using the new stuff with the terrain I posted some days ago before I start on the normals. I hope it goes well and I can again use it to render some images.

Most of the issues I was not able to finish yesterday have been done today. I am still missing the UI-bit of yesterdays "invention" of the new variables I call "UIVars". But that shouldn't be hard to implement. The other thing I did today was to define a new interface to the textures used only by objects querying for the terrain data. That interface can not only produce the heights but also the normal on the terrain at an arbitrary point of it. Currently those functions aren't implemented yet, but I need them for the tiled materials as I will add a condition for the slope soon.

So I am still not finished with this thing, but I am still sure it was for the better of my program.

Today I first finished the implementation of the tree control in the Qt-UI. So the UI for the tiled material is now again working in both variants. I also implemented the height condition. But I haven't finished the integration of the height sources yet.

The reason for that is a bit complicated. To be able to access different kinds of height sources I added an abstraction considerable time ago. Its principle scope is even wider, it is supposed to abstract access to textures, though it isn't used in that way yet. One of the problems was, to integrate images with objects like the terrain. In principle the one has colors, the others heights. So they have to be mapped somehow to make sense. And there I made an error, the users of that abstraction currently have to have an additional pair of values to scale the textures. For the terrains it doesn't really make sense to use that facility to rescale the data.

As each of the users now has to know quite a lot about the sources (abstracted into an interface, so there are basically only two cases, but still), it means quite some duplicated code. So I came to the conclusion that the texture abstraction should do the scaling on its own. When I started to add that I hit on another long lasting problem: it is easy to use animatable values in my program, but hard to use values which aren't supposed to be animatable. In principle I could make all of them animatable, but for some values it just doesn't make any sense. E.g. the number of tiles in a tiled material is inherently unchangeable as changing them would result in the tiles moving quite uncontrollably over the terrain, changing their appearance at the same time. The same is true for the scaling in the texture. I don't see it as making any sense to only have that ability for textures and not terrains, so if I want to have it, I think it only makes sense as an additional value for users of the class.

So today I finally decided to do something against that problem and started a new abstraction to make using constant values (constant in the sense that the animation time has no effect) as easy as the animatable kind. I am right in the middle of that, so couldn't finish with the tiled material today. But I am sure the consistency which will result from the steps just described will be worth the time.

I worked on the tiled material most of the day. I fixed some hard to find bugs and now I am fairly sure the currently implemented condition and the distributions are working. I have also added the handling of the height source (I can use different objects already), though there is still a small problem with the UI. Currently the height source is not used in rendering, I will have to add that tomorrow. Also I haven't added any filter yet.

The Qt-UI now is also working in principle, only one small thing and it should work as well as the MFC-UI. So it still looks like I might get this thing to a working state this weekend. The two parts missing in addition to the two items from above is another condition I have started but not finished (as I need the height source stuff first to even have a chance to test it) and the conversion of old material definitions stored in files to new ones.

Today I made some last changes and now the very first example of the tiled materials is rendering again. It wasn't very spectacular as I just used a material painting a plane green (and I wouldn't need tiles for that), but at least it was working. I haven't done further testing yet, as I am still missing some parts in the model. Also the implementation in the raytracer is not completed yet.

I also fixed the first missing thing for the Qt/KDE interface necessary to use the tiled materials UI. The first issue was simple to fix now I am missing some code with the tree widget and then it should work there as well.

I still hope to fix the biggest problems this week end so I have a working solution very soon. I probably won't be able to implement all the conditions I would like to have in that time frame, though.

And finally there is something I keep thinking about which can not be integrated into the current code base so easily. The current model assumes that all the children you add to a condition are equal. But that is not necessary so, it is quite likely that I will have to use two complementary conditions to handle both cases (or even multiple cases) and it seems like a good idea to only have one condition object and the children somehow connect to a kind of exit of the condition object depending on which one of the conditions it needs. But that would make it necessary to somehow identify to which of the conditions exits the child would belong. I am still thinking about how to integrate that into my design.

So here are the images to yesterdays entry:

Modeled	With Fractal

The first pair only shows minimal differences, although if you look closely you can see, that the right image has a bit more structure. In the second pair you can clearly see the effect of the fractal. The last pair is a bit dark, but I think you can still see the differences. What is also visible is, that the fractal process doesn't change the overall structure.