Development

Today I have finished this part, the intersection guide lines are now also stored and loaded from the file. So now only the problem in the CSG-operator remains. Then hopefully the two will interact much better.

I think I have mostly implemented the materials. Only some parameters for the Phong-shader are missing. The first version will use only one single shader, using the Phong lighting model and all the colors will be set to gray. I have also found out, how textures are exported. So I should be able to make the materials more similar to the ones I use. But first I want to have something I can test, then I can add the missing pieces.

Today I managed to combine the lines which give limits to the extents of a profile. The code now looks for lines in the same direction and if it finds some uses the one closest to the origin. If the path is not planar it could happen, that the profile is limited by parallel lines on both sides of the origin, that case should be handled correctly, I haven't tested it, though. Now I only need to add saving and loading the information and this thing is also done.

Quite a lot of code was necessary to export the geometry information. Collada is a complex format in that respect and the specification isn't easy to understand as it is mostly broken up into the tags and you have to find out for yourself how the parts fit together. I needed some time to figure out, that you could use the "offset" attribute of the "input" tag to use multiple indexes to link the position with the normal data. In my system, I have no 1:1 relation between points and normals, points are global for the geometry, while the normals are stored with the faces. There is one last feature missing to complete export for objects, handling of materials. I will probably only export simple single-colored Phong materials. If I can find out how, I would also like to export materials using a texture image, but I haven't found out yet, how to do that.

Then I need to export the scene, basically a scene graph and it should be a complete Collada file. I will try to find some test apps to see, if the data I export is acceptable, when that is also implemented.

Today I wrote most of the code needed to show some lines where the planes along the path hit the neighboring one. That way I hope it is possible to never run into the situation, that the geometry is self intersecting. There is still something missing, though, the data is not yet stored to the file (easy to fix) and I have to remove duplicate entries. I will try to collect all the lines with the same direction and then use the one closest to the origin.

Before I change the sweep modifier I wanted to fix the CSG-modifier so it can use the form created by the sweep. I have made the change to the geometry and when subtracting it from the base form the program crashed. I have found and fixed that bug, but there is still an assert firing. It is in the function looking for the intersection lines through faces again. The result looks correct, so I don't know, if the assert is wrong (I doubt that) or if there is a bug which is so subtle I haven't noticed it.

I think, I have a good idea how to handle this problem with self intersecting sweeps. Instead of adding something which tries to automatically create a good object, I should probably collect the lines where the profiles intersect and draw them into the profile. That way I can see, where I am creating self intersecting geometry. But I will also have to fix another problem, the CSG-operators have trouble with the generated sweep objects. I have now tried twice to get it to work and both time hit a lot of failed asserts and the program finally crashed. So I guess I have to look into this also.

I have looked into the problem from yesterday and thought I had a solution, but it turned out to not work. The problem was, that the profiles intersected where the path was curved and so the geometry was not useful. I thought, that it would be easy to fix, I could calculate the line where the planes containing the profiles would intersect and for any line in a profile intersecting that line I would get the intersection point and throw away vertices until I intersected the line again.

But that will not work. I would also have to connect those partial profiles with the neighboring profiles and there I would probably have more vertices and would have to try to find a good mapping. That might be possible, but I would also have to check all coming profiles to find out, if the current one was intersected. I have a feeling, that would not work well, also I am not sure if it would lead to the expected result. So perhaps it is better to not handle this case and leave it to the user. Then I only have to make sure, that the program is stable enough to handle that strange geometry allowing changes.

Some time ago I had a crash when using the CSG-difference (again with the still unfinished radiator model). Today I took a look what it could be and first had to fix a little bug to even load the model. But that could not have been the problem. Then I executed the CSG-operator and got an assert very early, when it tried to simplify the geometry. It turned out, that there was a bug in the sweep constructor, it sometimes tried to connect a point to itself. I could fix that problem quite easily.

But the problem is deeper, I found out, that the problems are entirely caused by the sweep modifier. The form I created is self intersecting, I have to change the modifier to fix that problem. But at least the CSG-operation ran through and the parts which are correct look very good. So I will try to fix that problem in the next few days before returning to the AniVal-stuff.

Yesterday I have started to model some small objects for this month. I have already done a beaker (like the one I use when I brush me teeth) and started with a small tube containing some hand cream in reality. The beaker was easy, I have modeled enough objects like it to be very comfortable with it. The tube was a bit more of a problem. I have created the tube, but it is still cylindrical. So next is giving it its form and for that I tried to add an edge in the middle of the cylinder. That crashed the program, I found and fixed the bug. So I now "only" have to give it its form and I should have two nice little objects for this month.

I fixed a problem which had been in my program for a long time. When I created the animation I again noticed, that a small feature was not working. I can attach arbitrary objects to the camera and then apply all the movements done to the modeling camera to those objects as well. Especially for camera objects it is very useful, as you can immediately see what you are doing.

But it didn't work, because I did something stupid, instead of storing the object selected when I lock onto the object, I looked for the currently selected object in every movement. That didn't work so well and so today I finally fixed that issue. So next time I do an animation it should be a bit easier.

I have thought about the last problem I had with the code and decided, that I won't implement that bit now. I would need the path of the object being edited and that is currently not available. I could add the necessary parameter to a number of functions, but it wouldn't work correctly when multiple instances of an object were used. To fix that I will have to do a bigger change. So now it seems to work and I think it is time to move to the next issue, displaying the paths visually and make it possible to directly edit them.

I didn't have a lot of time today, so only looked briefly into the next step of the export to Collada. The next step is the export of geometry and that is not exactly easy to understand. The data format looks highly optimized, it looks as if it is flexible enough to actually make sense of nearly arbitrary in memory layouts used in what OpenGL would call Buffer Objects where you mix the position, the normal, texture coordinates and other stuff. So I guess I will take a bit to actually understand how to write my data into it.

I have found the problem, why only polyhedra were tracked. They were not tracked at all, instead the origin was tracked and the polyhedron was exactly there so that it looked as if the wrong object was being tracked. I know, what I would have to change for it to work, but I am not sure that is correct. The problem is, that currently I can't tell the reference object the position of the start object as I don't have a reference to it where I need it. Without that, I can't handle the situation, that the tracking object is contained in a group, as the matrix which is influenced is always relative to the container.

I have spent quite some time in the last days to get the new reference object into a working state. It seems to work, but still has some issues. It doesn't drop anonymous objects which I use for pure editor stuff, they wouldn't be a good source to track. Also selection doesn't seem to work only one object worked when I tested it and it didn't matter what I selected. I will have to check why that happens. Then I still have to connect the notifications from that object to the variable which is supplying the value so it can relay them to its receiver. But then it should work.