Development Journal of a Raytracer

It feels like yesterday I have done the last review (as it was so late), but here comes the review of July.

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.

Today I have continued to get the textures fixed. The length of the segment now is used to calculate the texture coordinate, but there a problem has appeared. The straight segments are so long, that they cover more than one complete texture instance. As I don't yet add new vertices, I can't handle that case correctly, currently all the texture coordinates end up with the same value. So next week I have to start adding additional geometry to correctly texture the track. But at least I seem to be getting closer to a working solution.

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.

I am still working on the feature to mark some entries as mandatory. I have changed the table so I can now define a style for each cell of the table. And I have started to add the functions to define, how to mark the fields in the table. There is "only" one thing missing, using that information when creating the table. The current code to create the table has to be changed, it is not possible to implement all the features. I thought of another way I will try, which should also make it possible to put more than one form-field into a line.

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.

I haven't done any of the small items for months, the last were done in May. So this time I have finished the two just in time. So here are some renderings of the beaker and the tube.

I haven't used a high number of segments for both, for the beaker it would at least be possible. For the tube I have tried to use more segments, but the changes done after the rotational constructor then don't work correctly any longer. Perhaps I will look into that problem.

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.

The next thing I want to add to the table containing the forms is the usual way to mark a field as mandatory (often a small asterisk). I don't want to hard code that symbol, though, instead I will supply the code with a string to display and where to put it. But to format it, I need some way to specify an id or a class so I can use CSS.

And there a longer tangent started today. I have intended to add that feature to the table right from the start, but didn't come up with a good way to do it properly. Today I found one, I have created a new class which stores the id, the list of classes and the direct styles for an element. That class can then be used to specify the style of an HTML-element and also format the attributes. I have implemented that class and also changed the class for the table so, that I can specify a style for the table, one for the table head (if it is used) and one per table row. What is still missing is, to specify a style per table entry. After that is added, I can add the functions to mark form entries as mandatory in an extra column. Quite a lot of work for a small feature, but I consider the style class a very important part of my implementation, as I expect it to be useful later.

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.

The function to turn the form data into a table is now mostly working. Most of the options are in the program, I can handle normal text fields and password fields, I know how to handle default values and I can set the size of the text fields. Also the previously entered values can be written to the table when the data has to be presented again. As a part of this I have also implemented a function to turn UCS-4 into UTF-8 data.

For the text fields I am only missing two more features. First I want to be able to add the little star to mark a field as mandatory and second the data being returned to the user is not sanitized. Currently it would be very easy to break out of the form and inject arbitrary code into the site. I will have to add some function to fix that problem, but I haven't yet seen a complete set of rules what to do.

Then all what is missing are more handlers for the forms. E.g. for check boxes or options. Also additional buttons can be quite useful and I would like to be able to add javascript event handlers and CSS-styles. And finally I would like to be able to tell the code, that some form fields are supposed to be in one line of the table without having to specify the full layout.

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.