Development Journal of a Raytracer

I added some features to the stems today. The direction in which a branch grows can be controlled much finer now. Also I have the ability to limit the life time of a stem. So I think I am slowly reaching the point I was looking for. Now some small additions and the definition of the trunk and the tree should look quite nice.

Today's image may look worse than the ones from the last entry, but the three branches are actually forming the lowest layer of a quite big tree. I wanted them to fill out a small layer as the next layer of branches would be on top. Multiple layers then should give the tree its overall form.

Branching probability 30% on the primary branches.

Today I only fixed some smaller bugs and found out, that the forks worked correctly. The bug I found was rather stupid, I had mostly fixed the feature to thin out the standard branches after some time, but it still had a bug which removed it from the front as well. That alone helped a lot. The second thing I found out was, that the forking probability of the primary branches was way too high. That was the reason for the huge amount of branches.

Branching probability of 25% for the primary branches.

Then I changed the thicknesses of the branches. I think it looks much better now. And finally I played with some settings to thin out the leaves a bit. Also I played with the probabilities creating the random branches and I think I am finally on a good way. Finally I changed the angles the branches start with.

In the two images I added you can see, how strong the influence of one of the probabilities can be. As always the images link to bigger versions.

The track is now fully working. It is not very interesting, but at least it is rendered. I also added code for a third camera position, one looking down on the car from way up. I was even able to stay on the track, but it is still quite boring to "race".

Next I will model a simple sign to define start and finish. I will also paint a simple texture with a start/finish line and some markings where the car is supposed to start. The track-object will then have to place the object and use the texture. I will also add textures to the other track segments. Then it should at least look a bit less boring. The last thing the track object needs to do is to define a transformation with the start position and heading of the car.

Something else I have to work on is the steering. The steering wheel is overly sensitive. I guess I will have to add some dampening so that only somewhat larger movements have an effect and small ones are filtered out. Currently when I try to decelerate by taking away gas (I still have no brakes) I often leave the track.

After fixing a big bug with the probabilities I am finally back where I was before, the tree doesn't look good. I had to reduce the probabilities for branches very far to get the thing back under control. Now I can try to fix the problems and then hopefully I will get a nice looking tree. I even saw a new problem today, the forks create incredible thin branches. So I think I have to fix two things, the forks (shouldn't be very hard) and the distribution of branches (I will add a time after which a branch just vanishes). Then I will see, what else is wrong.

Today I removed the code which stored and loaded the plants. Now the rules are used to recreate the tree. It is faster and the files are smaller. I also found and fixed a stupid problem in the load-function for the stems which interfered with the random distribution for branches.

The result you can see in the image. Now much more branches are created. I also made the branches thicker and pushed the probabilities even higher. I fear I overdid it now, though.

I also have no clue where the black dots are coming from (visible in the linked bigger image). I will have to see what causes them this time.

Today I had a good idea I implemented right away. As I have still problems to navigate a scene where the tree is fully visible, I was thinking about a way to simplify the tree. It turned out to be primitive, I now have added a switch to turn simplified rendering on. That switch means to drop the leaves and switch the stems to the simplified rendering which uses one big vertex array. That way I can see the basic form in the editor and don't need to change anything for the raytracer to render it.

Tomorrow I will continue with something similar. Currently I store the symbols making up the tree. Storing and loading them takes very long, I think it would be more efficient to just recalculate the tree when loaded. Whenever I write "random branches" or "random distribution" that is not quite right, the random numbers I use are deterministic and the initial values are stored, so recreating the tree will create the exact same tree every time as long as no rule has been changed.

The problem, that only part of the tree was rendered was not hard to find in the end, it just took quite long as the data set is large. It once again was a problem with extents, the plants still couldn't correctly calculate their extents. It should be fixed now.

I also had a closer look on the result and there are some things I don't like. First the branches of level 2 loose their branches too fast. The hierarchy 1 branches work much better. The second problem is, that the branches are too thin. I will have to make them grow thicker.

But overall I like the look. It isn't all bad, so with the small fixes and defining a real trunk it might look interesting. There is also one small feature I will add, the probabilities for a random branch have to change over time. Close to the trunk there should be quite few branches, later it should branch more.

Contrary to my intentions from yesterday I today worked on the problems of the OpenGL-renderer in 64bit mode. Tomorrow I plan to continue on the port to Qt4 in the Linux-version and there I don't want to use the 32bit version when possible. So I have to get the OpenGL-renderer to work correctly, even in 64bit mode.

I at least managed it so far, that the code no longer crashes the OpenGL-driver. But it is still not fully working, only 3 of 6 faces of a cube are rendered. In 32bit mode it still works. It was hard to find the problems, the vertex and index arrays are not easy to build. Originally I used the "usual" data types (unsigned long) instead of the typedefs from OpenGL (GLuint). I found out today that that was a terrible idea. I needed some reinterpret_casts to pass the data to OpenGL, so the compiler had no chance to catch completely wrong conversions.

The hardest to find error was in a piece of code which creates an array of index pointers for use with glMultiDrawElements. It handles the case that I either create an index buffer object or use the indexes directly. The difference is, that the IBO uses relative indexes, the second way uses pointers into memory. I gave the function an offset to subtract from the pointer to get the right value. That offset was 32bit, the pointers are 64bit and so chaos resulted. The call I use to draw in 64bit mode has a strange datatype, it is a pointer to an array of 64bit values (either pointers or indexes) pointing to 32bit values (the indexes into the vertex array). I needed some time to get that right. It is also the thing which crashed the driver, it can't handle very big values (when you write the indexes as 32bit values, then two make up one 64bit value, a rather big value).

I continued with the tree. It slowly gets a form I think I can accept. Today I played with the settings and made generating the tree faster. I also rendered an image to finally show how far I have come. Something went wrong again, the tree got clipped. I will have to look for the problem tomorrow.

There are just three branches of the highest hierarchy, the rest is secondary and tertiary branches and some short branches which carry leaves. I think it is quite nice, no?

I have finally written all parts to turn the track into geometry. Contrary to my intent I forgot the inclination for now, I want to try the thing first. The inclination is quite simple to add, I have to refactor the code in any case. The function turning the logical track into geometry is breathtakingly ugly, way too long and hard to get. So I see no way that it could stay like it currently is.

The parts still missing was the function to calculate the intersection between two planes, the function to check if the lines direction was correct (which as I reconsider is implemented wrongly, it compares the normalized vectors, but it has to test for a positive dot product) and if not corrects it. Also I have written a function in the line to get the point which has a defined distance from the start point of the line.

Finally I wrote the code to turn this information into geometry. It currently throws an exception, I will have to see, what is wrong, the exception indicates I have a problem with the index array.

What I don't like is the vecmath library. It is a requisite of Java3d, but honestly it is a pain to use in my view. And it is not only the operators which are missed by a C++-programmer like me, there are many functions I am simply expecting, like one which tests if two vectors are parallel or conversion functions to add a vector to a point.

I finished the stuff I had started yesterday and played a bit with it. Rendering is still very slow and I have a little bit of a problem in the proportion of the stem lengths to the size of the leaves. Also I seem to have a bug somewhere in the input elements. I have a long time ago added the feature to treat a number as an angle in degree. The program sees radians, the user degree, that way it is easy to define (I have an idea how much 30° is, but when I see 0.5 I have to remember that it is the same) and also easy to use in the program.

So on Friday I will try to find and fix that bug and then will see, if forks are working. I will also try to find a better balance between the sizes of branches and leaves. If I find some time I might even render the tree to post an image.

Today I finally continued with the trees. I added two new facilities, the first is, that a stem segment already had a random length, but the number of segments was fixed, so the length difference was never very big. Now the number of segments can also be specified to be a normal distributed value with a defined standard deviation.

The second part I started to add is the ability to fork a stem. I still have to extend one class to tell the stem to stop adding segments and therefore branches. The fork is defined by a (normal distributed) angle and a probability that a segment branches. The plane the fork lies in is defined by using as normal the nearest vector to the up direction which is orthogonal to the growth direction. I think that is not very far from reality, at least I hope so.

As I had suspected the effect of the last changes was not big. I think it is quite a bit better now, but I could not say if the last step, to optimize drawing multiple polyhedra, had a small or a big effect. I still think it was worth it and I will probably also change the distribution object to use that facility in the future. But for now I want to finally continue at the tree.

The long pause at least gave me some distance and new ideas. I will continue with the tree tomorrow.

Now only the change in the polyhedron is missing. This thing makes very slow progress, but I hope to finish it soon. The changes up to date didn't have as big an effect as I had hoped for. I slowly doubt that I can get the plants really fast, the problem is that the batches being sent to the graphics card are probably too small (e.g. one single leaf).

There is not a lot I can do, as currently I don't reuse parts. If I would create only two or three branches of the lowest hierarchy level I could create a batch for that compound object (though it would still not be that easy), but for now I don't want to do that. So I guess I will have to live with the slow editor.

Today I played a bit with the distributions and found and fixed a number of bugs. I also added a simple feature to make it work better in the editor. The most simple way to date was to reduce the density of the objects. But before storing the file to send it to the raytracer I had to return it to its correct value. So today I added a simple value which tells the OpenGL-renderer how many objects to ignore after it has drawn one. That way I still have a reactive editor and don't need to do anything so the raytracer does the right thing.