Development Journal of a Raytracer

I am still struggling with the chamfer modifier. As can be seen on the image, I also have implemented the second way to chamfer an edge. But I am still some way from finished. For one I currently make no decision on how to handle the ends, they are hard coded. I will soon change that.

But first I have to handle two much more serious problems. There is an assert in the program at a place where I am simply clueless how to decide for a sequence of substituted edges where to start. When that case occurs I am completely without context. To solve this, I will first have to refactor the code, because the code which basically creates those substitute edges is also the code which can tell me, how the next edge to be processed will look after processing. And that is what will give me the answer to the question with which end of the current edge sequence I should start.

The second is also a hard one. If I would also chamfer the edge opposite the two edges in the image, the program would fail. The problem is the handling of the edges in faces which hit a chamfered edge but don't contain that edge. Basically the two edges there are modified and two are inserted between them. If that happens twice, I have a problem, the program does not handle this situation correctly.

The second case is nearly done. It looks correct on the image, but there are actually two errors which can't be seen, there is still a vertex in the middle where the edges originally met and an edge going to that vertex. They aren't rendered in that view and so don't appear.

This case turned out much harder than I had thought after the first case was working. It turned out, that the first case only worked on the cube, because when implementing it, I had always though of the cube. So all the directions were just right, but as soon as I had added a vertex at the middle of the edge and moved it inwards, those assumptions no longer held and so the algorithm fell down. I have fixed those issues and it now actually works as expected.

Next is the removal of the unused vertex and the edge to it. And then the last case has to be implemented. I hope to finish this thing tomorrow. A lot of work for such a small feature, but I truly believe it is worth it. A lot of furniture (especially old ones) and machinery has chamfered edges. Also I think the way I implement the modifier it should create a bevel when I use it on an inner edge. I haven't tried this, as I first have to get the chamfering right, if it should also implement beveling, the better. If it does something strange on inner edges it is also ok.

After some more work, the modifier starts to work. Currently the selected ends are still wrong, but I choose to start with this case, as it it the simpler one. Now that this one is working, I can continue with the next one, it will be the case where at a vertex only edges to be chamfered meet. That should also be quite simple.

I was working most of today on implementing the chamfer-modifier. It really isn't easy, but slowly I make progress. Currently I always use the bisector as limit to the chamfered edge, as it is easier to implement for a start. The design I have chosen should also work for the other way. Currently only the vertices and edges are created.

So the next step is to include the faces. After that I will probably add support for two edges to be chamfered being connected and then finally add the last bit, the ability to end the new edges on edges and not the bisector. Then it should work, only the lark's tongues missing. I don't know if I will implement that last bit, currently I don't need it.

While looking at the footing of the stand for the lab scene I found, that I should chamfer the top edges of it. As I thought, that chamfering should be easy to implement, I just started to do so. Shortly after that it appeared to me, that I was wrong. Chamfering is all but simple.

So I started to draw some sketches to find out, how to do it. I added them to the documentation, so I won't forget the reasons for some decisions.

Today I mostly did some modeling. The T-shirt slowly looks good, but the seams I added yesterday need more work, after subdivisioning there are problems. I need to remove some edges and add some at another place. But all in all it looks quite well. Some more tweaks and I can fix the object as a base for T-shirts of different lengths.

I also started to model a new part for the lab. I want to add a stand and started on a foot for it. While doing so I actually managed to crash my application, but it wasn't something big and is already fixed. When a modifier is removed and the system can reuse the editor, some settings have to be checked and eventually changed.

I didn't have a lot of time today, but I continued work on the T-shirt. I will soon post an image of it. All the changes made to the program in the last time really, really work. They make modeling a lot of fun. The program has become responsive, the rendering finally doesn't have such big problems with transparency and I didn't have any crash today. So I am currently very happy with my progress and hope I will soon have some more cloths.

Something quite strange was, that I didn't know, where a T-shirt has seams, especially if there are on the shoulders. I think to remember that I saw both. Hey, don't laugh, do you know? If not, I found this description. And I have that fear again that some day I will stand somewhere staring at some clothing intently trying to figure out, how to model it.

The speed up was a full success, I am back at interactive frame rates. My hunch that the code to make faces planar/convex was a significant part of the slow reaction proved to be correct. It is much easier to continue work now.

For the DrawOn-modifier it is working, but it is not fully finished, the uv-mapping gets lost. The modifier actually never preserved the uv-mapping, so it is not a new bug. But the function I have implemented also has to do that part to be useful in other modifiers which should also profit from the possible speed up. Also the DrawOn-modifiers belong into the group I called "lazy" when I wrote about the stored selections. So I will spend some time to finally correct those issues.

In any case, this again shows, how very important interactive frame rates are when working with a 3D editor. It can't be over emphasized, slow reactions can greatly hinder your modeling, so sometimes it is the best thing you can do to speed up an operation and not work on new features. But the basic rule of software engineering still holds true: "premature optimization is the root of all evil", so first get it right, then make it fast. The other way around leads to premature baldness.

Yesterday I had restarted to work on the T-shirt I left at its unfinished state quite some time ago. In the mean time I should have made changes which should have helped me to continue. Especially the incremental evaluation should make some editing steps a lot faster. But as it turned out, it doesn't on the "DrawOnSurface"-modifier. First it still had a bug, which wasn't too hard to fix, but even after it was very slow to react. It is possible to do the editing I still need to do, but I want it to react much faster. Currently it can't be called interactive, it is more like moving the mouse, waiting 3 seconds and then judge if the movement was good. I have enough experience to actually get work done like this, but it is still no fun and takes much longer than it should.

So I also started to think about a change I had in mind for some time. My modifiers always rebuild the complete geometry and I want to keep that. It takes some time, but it also has enough positive effects to stay with the basic model if possible. But there are some steps I can save. I believe that there are three very time consuming steps (I know, I should benchmark before doing optimization, but this time I also want to make that change for structural reasons), making the faces planar, making them convex and calculating the normals. The first two steps are not too hard to speed up by only doing them when necessary. I can quite easily find out, if I moved one of the vertices of a face and if I partitioned an edge of it. If I didn't do either, the new faces partitions to make it planar and convex can be copied from the last state, as the faces geometry is identical.

For the normals that is not entirely true. The face normal obviously stays the same when the geometry is identical, so could be copied, but the edge normals and the vertex normals also depend on the adjacent faces. So for those I need to keep more state. I will extend the speed up work to those eventually, but it obviously depends on the knowledge which face normals haven't changed.

I already prepared the DrawOn-modifier with the necessary book keeping functions, I know, if a faces edges are the same and I have a list of vertices which have been moved. So next is the function which should find out, if the vertices of that face have been moved. That isn't so easy to track in the algorithm, so instead of making it even more complicated, I will do this step separately. Then I should be able to decide if the old data can be used. I hope I will notice a speed up there.

I think I fixed the problems. In the MFC version of the program it actually worked, in Qt you have to set the QGLFormat by hand. The default version used when you don't specify it does not include the alpha planes. The other change I had to make was for the laptop. It has a rather old graphics card which only supports OpenGL 1.3 and that has no glBlendFuncSeparate, so I have to get by with the simpler getBlendFunc.

Today I worked on the problem of the depth sorting to handle transparency. All in all it is working quite well, only a little detail didn't want to work: when I draw a transparent face behind another one, I need the original transparency of the face.

For that there is a mode in OpenGL named destination alpha. When you activate blending you can define the way the colors of the current pixel and the one already in the buffer are combined. The two functions to define that are glBlendEquation and glBlendFunc. I only need to set the second one, the first one has a default which is ok. The glBlendFunc can take the parameters GL_DST_ALPHA and GL_ONE_MINUS_DST_ALPHA, these are supposed to read the alpha value from the color buffer you render to and return the alpha (or one minus the alpha) value in the buffer. With the use of the function glBlendFuncSeparate (an extension to glBlendFunc) I can make sure to write the right value of alpha to the buffer.

But it didn't work, it always behaved as if the destinations alpha value was 1 meaning completely opaque. I finally found out, what the problem is, my graphics card is running in 24 bit mode and so doesn't store the alpha value in the color buffer. So I have to find an alternative, because I don't want to limit my choice of hardware. As OpenGL has quite some buffers I haven't used to date, I will see if I can use one of those.

I have removed the ribs which are not needed for this rendering. The others will be changed, so they don't poke through the hull.

The problem was indeed from the backsides sticking through. Especially where the hull is strongly bent the backsides (which are less precise and so have a bigger spanning length) were poking through. I had to add the checks for backsides for the transparency stuff. I now simply added a preprocessing step which checks if there are materials which are transparent. If not the backsides are completely ignored.

There are still some black spots, I have to see, what happens there.

It is working. The bug was at a place I didn't expect it. The dialog box was at fault. I use a modal dialog box for the stored selections and my modal dialogs don't make any changes to the model as long as they aren't ask to do so. This is typically done when the OK-button is clicked.

But for the stored selections to work I need the controls to give immediate feedback. I had forgotten that they don't do that. So I extended them a bit and now they can be instructed to do it. And as soon as I had done that, the stored selections were working. So I hereby declare the stored selections as finished.

Something which only occurred to me recently when I read a bit about Java Mobile 3D was, that I generally ignored some of the abilities of the glNormal and glVertex functions: the ability to use integers. In mobile applications that is quite important, because most of the devices implementing the mobile 3D variant are lacking a floating point unit. So they have to emulate the FPU and that means, it is probably slower. So if possible you should use integers there.

As expected the new stored selections function didn't work. I will have to look further into it tomorrow. The problem seems to be in propagating the selections up the modifier tree. I don't know, if one of the modifiers I used for testing was one of the "lazy" ones where I didn't fully implement all the necessary functionality or if it is a bug in the function traversing the modifier tree.

The second thing I have been working on are the rendering problems. Before I even started on the black spots, I first tried to find out, why one face was missing in the editor. I haven't progressed yet, I think all looks ok. I slowly think I might have hit a strange issue in connection to OpenGL. I have the impression, that somewhere between the internal geometry and the OpenGL output is a problem I just haven't understood yet. Perhaps something to do with sign changes on coordinates (my current guess). Somewhere in my code is probably an assumption which is wrong.

In any case, to find that I have started to extend the diagnostics editor for the polyhedra I added some days ago. I need to get more information more easily. It really was a good idea to implement it. Extending it is not too hard.