Results

Today I finished the implementation of the layered materials. Finally, this took a whole lot longer than anticipated due to a lot of bugs I have found. I hope the code is now better and I will never again have to do such a number fixes in elementary parts which were supposed to be correct.

In the process of getting this stuff working I had to make some more changes. The UI of texture rectangle was not usable in the way I wanted to use it and so I changed it a bit. The current way is much better. Also there were still some bugs left in the layered materials as such. Even the UI still had a stupid bug.

But now I think all is working and I can finally turn to a new feature.

I have found the problem with the textures. It was as I thought, you have to copy the texture coordinates in a vertex shader. Then the texture appeared, but it was not lit very well. It seems, that the gl_FragColor-variable used to set the color of the fragment shader is always clipped to 0.0 - 1.0. So I now collect the color in a variable, then do the multiplication with the texture value (that is all you have to do if you only use GL_MODULATE as texture environment) and then put the value into gl_FragColor.

I also finally made some screen shots. The one at the top is with the new GLSL shader, the one to the right is with the fixed functionality pipeline. I think you can clearly see the difference, the images used exactly the same settings and were not edited.

With the Phong shader you can see three highlights in the sphere from the three light sources, whereas the fixed functionality hardly shows the strongest and it doesn't look good. Also the spot light lights the plane with the Phong shader, in the other image there is no hint of it on the plane at all. Finally near the right lower corner of the plane you can see the difference in diffuse lighting. With the Phong shader it is much more defined and clearly circular. In the fixed functionality there is not much definition remaining.

Granted, I "cheated" a bit by using a big quad, if the plane used many more vertices it wouldn't look as bad with the fixed functionality. But the basic problem remains, the spots would appear but they would be much more diffuse and highlights with high specular exponents would need a very fine geometry. And somehow I have the impression that the shader is by far a more efficient solution than creating more geometry.

I did some benchmarks today. I already knew, that the Opteron will gain speed if run with 64bit software as it has more registers in that mode which allows an optimizer more freedom. So I rendered the same model with the same settings and got these running times:

	Render Time
32bit Executable	16m 35s
64bit Executable	14m 56s
32bit + Thread pinned to one Core	14m  9s
64bit + Thread pinned to one Core	12m 14s

So in 64bit mode my program needs 10%-14% less time. But as I had written, that I had the impression that the program ran faster when I pinned the process to one core, I also measured that. The first two results were for free floating threads, the last two are pinned to one core.

In 32bit the program runs 15% faster when it is pinned to a core, in 64bit it is even a bit more, 19%. So running pinned to a core in 64bit is 27% faster than just executing the 32bit version. Quite a lot, I would say, like going from the 2350 with 2GHz to a processor with 2.5GHz.

I did only one run, so the numbers are not precise, but honestly if I can get 20%-30% more power by simply flipping a switch (that is basically all I had to do in Visual Studio to build in 64bit mode) and pinning the process, then I don't need precise numbers to know, how to run my program. I will see, if I can find out, which of the "CPUs" in the thread affinity dialog belong to one physical CPU so I can measure the difference of free floating threads with only one physical CPU. I still think, that the two CPUs make the problem worse when the threads move between them.

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.

Today I finally found and fixed the root cause for a lot of problems with the MFC-UI I had in the last years. There always was something strange going on, I somehow had two MFC-contexts, one from the application, the other from the DLL. It often caused problems and I did a lot of workarounds with time.

The main reason for the problem was, that I use MFC in a very unusual way. Nearly all MFC specific parts of the program are in a separate DLL, the model and the rest, even most of the UI code connects to it over some class factories, abstractions and a powerful application specific UI-toolkit. This design has proved to be very powerful, nothing in the model has any direct connection to a UI so I could for example link my model implementation directly to a web server if I wanted to. There wouldn't be any problem to write a rudimentary UI in HTML/Javascript and connect it. So allowing simple geometry manipulation via a web interface.

But that way to use MFC is very far from normal use and so I sometimes have to dig quite deep to actually get things working and often even deeper to disable automatisms of MFC. E.g. my accelerator work was a good example, a normal MFC application doesn't even notice that it is there, it is simply automatically done.

I for some time had thought, that the reasons I had problems was, that I had to put the main object (CWinApp) into the executable, while all the rest of the code was in a DLL. The two contexts were obviously connected to those two. But I didn't understand how that could happen. So I tried to move the application object to the DLL and it quickly failed in a way I was quite sure I wouldn't be able to fix.

So I today decided to find out, what was going on. The first thing I noticed was, that my UI-library wasn't a MFC-extension DLL at all, but a DLL using MFC in a shared library. As soon as I tried to make it into an extension DLL I got linker problems. It turned out, that I had used a function which will make it impossible to create an extension DLL (AfxGetStaticModuleState). So I removed that and added some more code for things I had done wrong (dialog boxes needed an instance handle and used the wrong one) and now it works.

So after some years I have finally solved a big issue which had plagued me for some years.

I finally have all that stuff implemented. There were some bugs in the skinning operator (e.g. I had swapped the sine and cosine term for the direction), but I think I found and fixed all of them. I have only done some simple tests, the real test comes when I adjust the mapping of the characters skeleton. Then I will see, if it works.

But I think I now have a quite versatile skinning operator. The ability to have an angle between the bone and the area of influence should be quite handy for the upper arm and leg, as there I got into some trouble before. The problem is, that I have to be sure to hit all the vertices which should move with the arm or the leg.

Although there are still problems with the skeleton, it is at least useable. I already missed at least three features, I can't delete bones, I can't split bones and I need a way to insert a bone. The last I miss the most as I made a big error on the hip. I connected the two hip bones directly to the root bone. Now I can't tilt the hip with one movement. That means any pose involving hip movement (so nearly all of them) will be quite complicated.

Additionally the character also needs some changes. First the arms are way too thin. And I think there are problems with the shoulder area. It is either a problem with the geometry or (perhaps more likely) with the skeleton setup and mapping. Also visible is, that I didn't map the fingers. And there another feature is missing: partial poses. I want to be able to only define a pose for the left hand and apply that seperately.

But it is working.

I had started to render a sequence of the last island scene. My raytracer is terribly slow (yes, I will fix that eventually), so it took some days to render some seconds. So here it is:

I wanted to see, how the moving waves look in this setting. And I think they are quite nice.

I found the problem. The specular highlights didn't work properly because there was another bug in the mirror calculations (this time a forgotten minus). And I finally got how the specular highlights on waves work. I didn't have an idea where to get the factor for the the highlights from. I tried the factor for Fresnel reflection for the water surface. The idea in principle wasn't bad, but it wasn't with either.

When the eye ray (the ray from the camera into the scene) hits the water surface the Fresnel formula is used to find out, how much of the reflected and refracted light reaches the viewer. But the formula also applies in the other direction, it also tells me, how much light from the sun enters the water and how much is reflected. And that was what I had missed. Now the brightness of the ocean is also goverened by how high the sun is on the sky. Also the strenght of the highlights comes directly from that factor.

I think the images show quite well, how well it works now.

I fixed all the issues. So all the still missing things (no animation, autoskinning with severe limitations, no manual skinning) considered, the skeleton is basically working. The misalignment was in the variable where I expected it, just the function was a completely different one. I thought I had used the inverse of a transformation, it turned out the transformation was completely wrong.

So here is the example:

The next thing to do is to create a better autoskinning operator. My current one is the basis for more complicated ones. The next example I want to do is a hand. As you might have seen I created a skeleton for a hand to try the skeleton. So I now will try to model a hand around that skeleton and try to move the fingers.

And I also did the rest of the renderings. With 90%, 95% and 99% relative humidity. Well, the differences stay subtle, but at least the differences between 50% and 99% are quite visible. The sky gets considerably darker and the water starts to look different.

I had hoped that the part of the island on the left would show some airial perspective, but I can see nothing. I know it is there (I checked it in another scene and it was visible), but in this model I used all my photographical tricks. The island is only 1km times 1km and the far end probably isn't farther away than 500m (probably even much less). It only looks as if it was quite far away because I used the equivalent of a very short lense. I checked it, it has a focus length of 15 mm. Perhaps I should just stretch out the island much more, but then I will have to recompose the setting. I might just do that, though.

OPAC, the program I used to calculate the airial parameters, at least says, that the viewing distance at a humidity of 99% would only be 12.92km, so I hope if I make the island 25 times bigger it may be visible. Perhaps I should make it 100 times bigger (10 times the length and the width). I will see.

Mie absorption is also in the program, only Mie scattering is missing. I deactivated it as it was producing nonsense. Due to the Rayleigh scattering I now know in what area I expect the values to be. Not a big step and the real reason for this entry is, that I wanted to show the image created by a 6.5mm lense setting.

Oh, you can also see my really bad antialiasing. I think I will have to change it soon.

It works. Finally got the light source to behave. The tone mapping still has some problems and the sky dome is too bright (and the wrong color) in the morning and evening, but it at least works. At the start (about 7 am) and the end (about 5 pm) the sky seems nearly white. That happens because my simple tone mapping tries to always go to the same brightness.

I will add a minimum and maximum setting soon. Also I will add code to make the sky dome darker in the mornings/evenings. But I won't recolor it. As I want to do the complete solution of the papers I also have links to in the link section, I don't need it. Those will create (hopefully) better images in any case.

Next feature to come is the scattering with first order effects. When that is completed airial perspective and color of the lightsource should be correct. Then the "sun" will emit red light in the morning.

After fixing another bug I was able to create a new image of the island. I think it slowly starts to look good. The island still is missing a solid texture and the boundary between wave and land needs refining, but it starts to look like a real island now.

After some changes I was able to render an animated sequence of the waves. The sequence is 10 seconds long, has 250 frames and per frames the rendering took about 3.5 minutes. So the complete sequence rendered in about 15 hours (I don't have the exact time as the program crashed on frame 6 and I didn't rerender the first 5 frames just to get a precise number). I think, it looks quite nice.