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.

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 started to implement the function to turn the form description into a table (containing the form). I will add some data to make it possible to handle more cases, but I will only handle creation of very simple tables. If something more complex is needed, it is possible to create the page by hand. The next issue is to add a function to turn UCS-4 strings into UTF-8 strings. Then I should be able to create very, very simple forms. I will have to add more classes to represent the different options possible in forms, though.

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 swapped the implementations around, instead of first writing the function to turn the data into a table, I have implemented the test server. By using parts from the last one I could quickly add the necessary data. I found and fixed a number of problems and it now seems to work. I might change the way the form data is stored because I have the feeling I do too much copying when evaluating the data. Also I still have to implement the function to turn the form data into a table.

As I got the basic problems fixed last week, I could finally start to add all the little details. Today I first changed the code so it would create continuous geometry. That also closed most of the remaining holes (where small rounding errors occurred). Then I started to think about how I get the texture working correctly.

The texture coordinates have to be aligned to the geometry, so that the length of the track segment defines, how far I have progressed in the texture. When I reach the end of the texture, I have to close a quad and start a new one. I currently don't want to add points where the exact boundary between the v-coordinates 1.0 and 0.0 would be, I will just treat the point where the v-coordinate had the last value before rolling over to 0.0 again as that boundary. When that works, I will try to add the geometry to get that into a fully working state.

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.

The code is slowly progressing. I have the evaluation implemented, the code now checks, if the values from the form are acceptable. Error reporting is still rather bad, though at least it exists. I also found out, that I won't need a second class to also create a table based form from the data, a simple function in the class I currently write is sufficient. That way I can put arbitrary code before and after the table without any trouble. The next step will be to write that function and then implement the next test server to try this abstraction.

The light sources should now be exported correctly to a Collada-file. I also tested the code with a simple example and found a stupid bug. I have also started to implement export for polyhedra. Currently the objects are found and collected. Next is to actually write out the geometry. Then I will have all the parts and only have to combine them in a virtual_scene and instance that to have a complete scene.

I have continued with the class to aid in using forms. The easy parts are finished and so I have started with the hard part. I want to have a series of small objects I can use to define, what key-value pairs the form contains. The class is then supposed to scan the body and get the values and supply it to the function handling the POST-request.

I have defined a base class for those small objects, I intend to implement a number of classes to handle different types of values appearing in a form. I have started with a class, which expects strings or to be correct UCS-4 strings. I also will implement classes which check, that the option which was sent is valid or which convert a string into a number with optional checks if the value is within supplied bounds.

The class handling the forms will check, if the values it received match the specification. It will handle the case, where a key is missing, is sent multiple times or where unexpected keys are sent by rejecting the request. I will later also implement a second class using the specification to create the form.

I have continued a bit with implementing Collada-support. The point light sources should now also work and I have started with the spot lights. When those are done I will finally start with geometry. Then I have to implement support to write the scenes and that should be everything needed to export static scenes without animation support.

Nearly a month has passed since I did something at least a bit productive for the game. Today I finally seem to have found a solution for the problem. As often it turned out to be rather simple, but I really didn't think of it. I needed to find the intersection line between two track segments and I think I found a very nice way. I have the normals at the connection point of the track segments before and after that point. I calculate the average normal (just summing the two vectors) and use that and the point to define a plane. Into this plane I project the track segment directions and calculate the line which is exactly between the two segments.

The motivation for this is quite simple, I expect the tracks to be smooth, so I basically smooth out the tracks by taking the average normal. I think it makes sense to also use this normal for the geometry, but currently that isn't done. So I needed several weeks to find that simple solution.

The new source is fully working, I had to fix some minor bugs, though. But I have one issue, I have used the abstraction I built for the CSG-operations, but it isn't what I need. It always references geometry, I want to reference a model object, that is not an object with geometry, but for example a light source or an object pointer (which points to an object with geometry). So I have started to add a new class which does that. There are still some small problems, but I think it shouldn't be very hard to implement.

I have started with the next variable type, this one of type 3d point which tracks an arbitrary object. I am not sure if I can fully use the stuff I have written for the CSG-operator (relative position between two objects), but I guess I will at least use it and just treat one of the objects as empty. The class will be able to track any object in the hierarchy, so it will be able to track one instance of geometry, a camera or a light source. There is one extension I am thinking about, I could define a point in object coordinates so I could track a certain point on the surface of an object. But currently I don't see a use for it and will not add that feature, I think.

The new matrix variable is also working. I still have a small issue, but I think it is not the new code, but something I did wrong in the camera implementation. If I change the point looked at, the camera doesn't react. If I then do another change you can see, that the camera indeed uses the value I just set. That means, that some update is not done.

The next thing I will implement is quite simple, I will add a new kind for the point variables, it will just return the position of an arbitrary object. That way I can easily let a camera follow an object, I just need to use the right kind of variable for the look at position. Something I don't yet now is, if I should add a second kind of variable where the object being followed can be changed in an animation. Currently I don't see a good reason to do so, though.

Today I also finished the implementation of the form-data to UTF-8 decoder. So that part should be mostly finished now, I might need a way to encode UCS-4 to UTF-8 for sending the data, but that is fairly easy, most should be done already as I needed to first decode the characters to UCS-4 and then reencode them into UTF-8 to check if the sent data is correct.

And then I started with the last thing I will implement to finish the POST-requests. Technically it isn't necessary, but I want to have a class helping me create the forms and evaluating them. There will be two classes, one is an abstract class defining how to access and use the forms, it will have a facility to define the form fields and their data. The second will be an implementation of that and will also implement sending the form. It will allow a prefix and a postfix to be sent and will add all the available form data to a HTML-table. So I hope to cover all those standard forms you need with that later class, so I basically only have to implement evaluating the form to use it.

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

Continue reading "To Do in August"

Sorry for being really late this month. I had a busy weekend when I had planned to do the review of June. So here it is, quite some days late.

Continue reading "To Do in July"

I have changed my mind and have started to add the new matrix class. I think it makes sense to first implement this, as it makes it easier to test the coming spline versions for points and vectors. Using the matrix class will make it very easy to test it. Most of the code should be written, only the core functions are still missing, conversion from the internal representation back into a matrix and handling of transformations.

After quite a lot of tries I think I finally have found all the issues with the conversion of the form data to UCS-4. There were quite a number of stupid bugs in the conversion function. I am considering to add a second function to convert it just to UTF-8. I need both, because as soon as I start to work with the strings, UCS-4 is easier to handle, but for strings I only receive and send, UTF-8 is sufficient and needs less memory in most cases. UTF-8 is a bit less efficient when receiving, as I first have to decode the data (and build the UCS-4 representation of each character) to check, if the received data is valid UTF-8 and then encode it back to UTF-8.

I have continued work on the Collada export. The code now collects the cameras, light sources and object pointers. The camera library containing the optical properties of all cameras is also written. I should be able to export all cameras, though not all the specific settings. E.g. I have a fish eye camera in my program and I can't export that, in the Collada file it will be a perspective camera (so probably a rectilinear camera instead). It is possible to export those additional settings, but they can then be only read by my own program. Next are the light sources.

The 3d points and 3d vectors now also have an implementation which interpolates between key frames. It is just linear interpolation, so I don't consider this part finished, I also want to implement interpolation along a spline, at least for the points, but due to the high similarity between the two classes I will probably just add it for vectors as well. With that done I will add the new animated matrix implementation.

All the elements, which can currently be animated now have the key frame controls. Before I add the next feature (visualizing the paths on which an object moves), I will make two classes animatable, Points and Vectors and then add another implementation for the matrix variable. I want to add one mainly useful for cameras where you define the position, the point the camera looks at (the center of an object or a point, possibly animated) and a direction for the up vector, also animated. To do that, I obviously need to be able to animate points and vectors. I haven't decided if I need to be able to make it possible to change objects in an animation.

I have continued with the Collada format exporter today. The next step, after I was able to indeed write an empty file is to export some of the data. Although I am most interested in the geometry, I think it makes sense to start with something simpler and so will export the cameras (and the light sources). The format is much more rigorous than my internal data, I have to fist collect the different kinds of information, e.g. all cameras, and then have to write out their properties into something called "camera library" (the start tag is <library_cameras> in case you want to look for it in the documentation). That mainly defines the "optical" properties and then the camera is referenced in a "visual scene" (<visual_scene> contained in the <library_visual_scenes>) as a node, which defines the alignment and position of the camera. This scene can then be instanced in the scene (<scene>). So it will be some time until I have all the utility classes I need to get it working.

I have today also implemented the two buttons to add and delete key frames. Currently only the matrix-variables are using them, but it seems they work very well. I played with the new stuff for a bit and it really seems to work very well, I could do all the changes I wanted to do. There are some small issues, e.g. when I delete a key frame the UI doesn't get updated making it hard to see, that the key frame was really deleted, but that should be rather easy to fix. When it is done, I will add that code to the rest of the animatable classes.

I have worked in the last days to get the AniVals into shape. It was a big change, but now it seems to compile again (and I am very sure it is also working). The reorganization should help me to enhance the AniVals in the future while keeping the compile times low (implementing a new source will not cause a complete recompile). So next is to actually continue with the implementation of the key frame UI.

I tried to find out, if the decoding works and can now say for sure that it doesn't. I still didn't get it to print the values, but the string length of the converted form parameters is always 1 and that is not correct. I will try to debug the decoding function and find out, what is wrong.

I have also continued with the code to access the key frames. I have moved the code for the UI (and the handlers I have) to a new file. The next thing to be done is actually implement the last two functions, deleting a key frame and creating a new one at the current position. For that I need the help of the classes and there a little problem occurred.

For very long I have a less than ideal situation, the interface of the AniVals is mixed with the implementations, resulting in a huge header-file being used by most (or all?) of the cpp-files. That means I was always quite reluctant to make changes in the implementation for fear of the long compile times. So to fix that, I have started to drag out the implementations and put them in another file. That way compile times should go down and I should be able to add much more easily to the classes. I am in the middle of that transition and still have to write some smaller functions to extend the interface of some AniVal-classes slightly, but I hope to finish this tomorrow. Then I should be able to implement the missing two functions and start to add the same stuff to all the classes doing animations.

I am also planning the next feature in this area. I want the objects to be able to give AniVals the ability to draw themselves and react to selections. I need that especially for the matrix-anivals, I want to be able to see the paths of movement of animated objects and cameras. And I would like to see a representation of the positions of the key frames and a way to move them. Support for animations is still very bad in my program, I want to make it much better.

Not much to write, though it was not easy to implement. I also added decoding of the UTF-8 encoding so now I should be able to actually read (and understand) the forms. There only is one problem, I can't check if the decoding works. I tried to output the decoded values which failed completely and also the debugger only shows some error message and doesn't seem to be willing to show me the values. So for now I hope it works correctly and continue as if it would.

I have written most of the code to actually add the Collada-export to the program. Only the actual export is still missing, but that shouldn't be a big problem now. Then I can test the code and see, if I can indeed write a minimal, empty file. I am rather sure, that will work, then I will try to add export for cameras and light sources and finally I have to implement support to export the geometry of polyhedra.

I also continued with the key frame support. I can now jump to the time points stored in the object. And the buttons to move to the previous and next time point also work. So the part, which is independent from the object is now working, next are the two functions which need support from the object, add a key frame at the current point in time and delete the current key frame (if there is one at the moment in time we are currently). I hope to finish this thing this week and then fix the animation and render it again to post it.

Today I continued with the implementation of an export filter for Collada. If I am not completely mistaken, I would be able to write a very first, valid Collada file. It wouldn't contain any content, but at least it should be correct. To actually test that, I will add the new code to the editor so that I can actually call the function and then look into the created file to see, if it looks ok.

The next step is to go through the object hierarchy and export the data there into one of the library sections of the file. And then I have to go through the model object hierarchy and write that data into the scene section of the file and that should be all that is needed for a very first version of the export. I won't export any animation data yet and also no procedural materials.

I have defined the UI-elements and now have to connect them to some functions so they actually will do something. I hope to get that done tomorrow and then start to abstract the implementation so it is easy to use in all the classes implementing animatable variables.

I already wrote about it briefly, I am trying to make it possible to access the key frames. To do that I started adding some additional controls to the UI of the animated matrix variables. I want to have a list of key frames, a couple of buttons to move to the previous and next key frame and two more buttons to add and delete a key frame. When it is working with the matrices I will pull out the code and generalize it so it is easier to use for the other types of animatable variables.