Development

I have finally created the images of the uv-mapping of the stack of books. So now I can use it to draw some simple texture. This stuff is still not working well. I guess I will have to make some bigger changes.

I first need a way to map parts where the current automatic mapping doesn't work well. I will probably write a simple modifier which just maps each face into the uv-map so no two faces overlap. But it will not connect any faces. The second issue is old, but still not fixed, I need a way to directly write the uv-map to disc. Currently I make a screen shot of a window and then cut out the map. Not efficient and I currently can't even change the size of the image. The biggest problem here is, that I don't have a way to turn the uv-maps into images I can store. But it isn't really hard either, I basically have to be able to draw lines into my image class. That should be fairly easy, it is just a lot of work to get the stuff working.

I still have troubles creating a good uv-mapping for the stack of books. It just is very tedious to fix the parts where the Least Squares Conformal Maps(LSCM)-algorithm didn't work well. Either I have a really strange programming bug in it or it has troubles with some kinds of geometry (which was "forgotten" to mention in the paper). The geometry in question is not exactly nice, I have to handle the top sides of books, so they are basically long and thin quadrangles, which are connected in a way which makes it impossible to create a correct planar uv-map. And that last property seems to cause the trouble, I guess, that the necessary distortions are so big, that the thin rectangles can't be aligned any longer by the algorithm. The results are terrible.

But fixing the parts which can't be handled automatically is also bad. I am a bit lost on what to do to finally finish this model. I guess I will try to fix the rest by hand, but honestly I think I have to find a better way.

Currently I think it would probably make sense, to create another automatic mapping, like the operator using LSCM, but creating disjoint maps. Basically mapping each face to a piece of uv-space. Probably not easy to use, but that is what I do manually in any case.

I also made a small change to the UV-editor today. When trying to finally get the uv-map of the group of books working I missed a function. Some faces were mapped to the same uv-coordinates and I couldn't separate them as I wasn't able to select them independently.

For technical reasons the normal selections can't be used by the uv-editor, so it has its own selection. All I had to do was add a function which looked at the selected faces in the geometry and create a selection for the faces in uv-space. It turned out to be quite easy, only the UI made some trouble. But now it should be working.

I have finished with the changes for the stored selections. It is now possible to also select vertices, edges or faces based on the material or direction. The directions will add all faces where the face normal is no more than 45° from the chosen direction. Currently the directions are fixed to the three axis (and the negatives of them) in the objects coordinate system. I might handle the other coordinate systems in the future, but currently I don't see much reason to add that. Also I might add a way to define a free vector and difference value later. There is still one issue I have to change eventually, the stored selections should create objects which contain the description of the selection and not the selections, that way a change in geometry would be handled automatically. But for now it is finished.

The channel material finally created the first pixels in the raytracer. Currently the shader is not evaluated, I still have to add a facility for that. But at least the evaluation is working now. So with the addition of the shaders it will be working on a basic level. Then I have to solve the remaining issues:

1. Lazy evaluation of switch statements
2. Handling of antialiasing
3. Handling of face differentials (mapping from uv-space to world space on the face)

I don't know yet, how to implement the last two issues efficiently.

Didn't have a lot of time today, so I only worked a tiny bit on the stored selections. I think I am mostly done, I only have to extend the function handling the selection so it is able to select based on materials. And then I will add the selection of faces based on the normal.

I have modeled a block of books to put on the book shelf. The block is one object, it contains two thick and three thinner books. Yesterday I finished modeling the geometry and tried to start with the material definitions. I selected the geometry where the pages would be visible and assigned them a different material. I plan to add a new shader component to get some bump mapping for the pages. Then I tried to select the rest of the geometry and noticed, that I didn't have a way to do that.

So today I started to extend the stored selections to also include selecting all the faces which are painted with one material. I will also add a second setting I have missed in the past, the ability to select all faces which point into one of the six base directions.

Today I started to think about how to allocate the memory I need to evaluate the material in every step. I think I will need to use the blocked allocator I have written before, as it will probably be too expensive to allocate and deallocate for every single evaluation. I had to add a new version of it, as the existing one expects the size of the blocks as a template parameter and that is not possible for the channel materials. The size of the block is only known after preprocessing.

The second big problem is, that the code has to be thread safe. As I already solved that problem I will use the same design I used for the objects. The problem is, that currently the materials don't get all information. I have started to change that, but it will take a bit until it is working.

Today I continued the reorganization of the code by implementing the first parts of the new response. This response is supposed to be the standard response to be used in most cases. It has the streaming interface and internally uses a number of send buffers. The data supplied is written to the buffers which will be used to send the data. That way I should need only two copies of the data, I don't think I can get lower. I will always need one buffer to collect the data, so that copy can't be eliminated and I need a second one to send the data to the socket

In theory I could eliminate one copy when using chuncked transfer, as I could copy the data directly from input to the socket, but I don't think it would be very efficient to send very small chunks (because of the additional headers), so some buffering would probably still be necessary.

I have started the implementation with the uncompressed case as it is easier to implement and debug. The compressed version will feed the input directly to zlib and use the send buffers for the output of the zlib calls. That way I hope to also minimize the amount of copying in that case.

Today I finished the new constructor for the frustum. It wasn't much left, I had already created the top and bottom face and so only needed to add the sides. I tried most of the controls and the results looked correct. So another small item is finished.

Today I have implemented the preprocessing of the channel material in the raytracer. What is missing now is allocating the memory needed for evaluation and then evaluate the material. And that should be all for the basic evaluation, but it will not apply the shaders. For that to work I will have to extend the preprocessing function a bit more as I don't see a way to write the shaders in a generic (and at the same time efficient) way and so will implement the shader parts in the raytracer and swap the operator for evaluation with a raytracer variant.

Today I have started to implement the Channel Material in the raytracer. Currently only an empty class exists, but now I can start to add the things necessary to evaluate the material. I will have to make some changes to the basic evaluation algorithm, as I need to use real shaders, but that should be possible. So I hope to soon have something working in the raytracer.

The frustum is mostly implemented, only one function is missing, the most important one. I have started to implement the function which turns the parameters into geometry and hope it won't be too complex, but I think I know how to create the geometry. I have mostly defined two planes, one defining the bottom plane and the other the top plane. The next step is creating line segments starting at the bottom plane and running to the top plane. And then I only need to split each of the lines into the right number of segments and connect them. So hopefully in the next days I can finish it.

I started implementing a new constructor. This one will be able to create a frustum. But I will also add other options to influence the object, there is an excentricity setting so I can define an ellipse as base instead of a circle. Also the bottom and top faces can be slanted, even using different planes. I hope that it will be a useful addition, especially abusing it as a more flexible variant of the cylinder. I could create all of the forms using some combination of modifiers, but I think it makes sense to extend my base set of constructors to make it easier.

If I find some time I will also add some more, I think it would make sense to have hollow variants of the objects. Also I would like to have a constructor for boxes which can chamfer the edges. Those I think are useful as they are quite frequently needed as building blocks for larger objects.

I have finally managed to find and fix the CSG bug. The bug was in the function calculating the intersections of one objects edges with the other object. It stopped much too early and so didn't find all intersections. Once I had finished that the program worked correctly. But I did something else. I originally thought, that I can only work with convex faces and so in a preprocessing step the faces were changed to be convex. But I think there is no problem using non convex faces. So I dropped that step and I guess I will see, if it works or not. I will try to post an image of the sockets tomorrow.