Development Journal of a Raytracer

I haven't even written what kind of game I intend to write to learn my way in Java because I wanted to make a longer post out of it together with some general design ideas. I have in the last week occasionally looked into some documentation and also thought about some details and the general way I want to do this.

The problem in the DDA was a wrong sign in some cases. Easy to fix. Additionally I wasn't sure the points still work, but it seems they do. There is some unexpected reaction to singular points within ISO-areas when the difference between the heights is small. The points nearly vanish and pull up the complete surface around them so that it looks as if the area had a higher value as height. So now it really looks as if this part of the program is working and I can go to the next one.

The next few steps are finally adding the handling of the view frustum in the OpenGL representation, adding the texture coordinates and also adding the element to the raytracer. Then I will have to start on the LoD-scheme. If that is done I will finally start on the fractal component. I want the LoD to work before that, as I fear that it would get hard to judge the fractal stuff was working without an ability to see the details.

Something is still wrong with the DDA to find the boundaries of areas. Sometimes it creates big nonsense. The other thing I did was to add a flag so I can specify if I want to only create the low resolution height map. That way editing is much faster and I can switch to the high resolution when I am finished. I also fixed some parts of the code where the constructors were not executed when they should have been.

As I promised I would like to explain how the weighting of the distances and their heights for the terrains work. In principle it is totally simple, just coming up with a good incremental formula proved to be difficult.

Sorting the areas now also works. I think the code should be quite efficient. It is running through the areas which have been sorted by the area of their bounding boxes. For each of those areas it looks for any area which it contains and those are removed from the outermost container and added to a data structure I use while sorting which describes all I need to sort the areas. When the code has checked all the unhandled areas it checks, if any of the already handled ones might be contained by the current area. Then that area is moved to the collection of handled areas. When all areas are marked as handled (have been moved), the algorithm recursively calls itself on the children of all the handled areas.

I have been working on the terrain implementation today also. I continued with the implementation of sorting the areas so they show up as I expect them to. Most of the code is written, only the test if an area is within another one is still missing. If that is done I will look into rendering the terrain, I will add frustum culling and the texture coordinates to the OpenGL version and will add support to the raytracer.

I finally managed to get my first Java 3D test scene to actually show up. As I generally don't like to follow tutorials (I am of the opinion that you don't learn a lot if you just follow them), it took a bit longer. The thing I didn't know is, that the bounding volumes are very, very important in Java 3D. If they are not set on light sources or the background, the objects won't be lit or the background will stay black.

The book I use to get into Java game programming is "Killer Game Programming in Java" from Andrew Davison. The parts on 2D programming are very good, but the 3D part is weaker in my opinion. The introductory example (which is the basis for my test scene) for example sets all the bounding boxes but doesn't say a word if it is important or not. With the 2D examples I had the impression the author knew exactly what he was doing, for the 3D ones that impression is a lot weaker.

I finished the UV-mapping tool I had written about before. It even works as intended and I was able to create the UV-map for the socks where the left and the right sock don't share space in the UV-map and the left sock has an UV-map which is mirrored. It really is a nice little tool I will probably use quite a bit in the future.

While testing it I even found another little bug. I had added the ability to use a selection rectangle to the generic editor for polyhedron modifiers. Most of the modifiers don't even need an editor of their own as they only act directly on the selection. And those editors use the generic editor, so adding a feature to it adds it to a whole range of modifiers. But the rectangle selection accidentally only worked when the modifier used the selection. Most do, so I didn't notice that the others also should be able to use the rectangle selection. And so I fixed that bug as well.

So with this the socks are also complete.

I tried before to finally get up to speed with Java and failed. It seems my interests in calculators are very limited. On the positive side I learnt enough Java to at least be able to follow tutorials and with some checking of documentation get something together.

Although the calculator never got far, I at least found out, that one feature of Java I was suspicious of really is to be avoided. Java finally also got an Enum-type (since 1.5) and it has some strange features. You can define functions for the symbols and also associate data. I though that to be a strange feature and even without checking I am quite sure it is an artifact of the implementation, but wanted to see, if it has uses.

So I tried to use it to connect the buttons of the calculator to the functions in the class doing the calculations. It works, but I find it completely confusing and think the feature to define functions on enums shouldn't be used. I guess just using them as constant values as they are in C-like languages is the best way to use them.

To get to a grip on Java I guess it is best to do something I am interested in. So I guess it is time to use Java 3D and do some 3D stuff in Java. I surely think I showed that I have a deep interest in that subject and I really would like to try Java for 3D programming. My editor and the raytracer will stay in C++ and C++ will stay my main programming language, but I am really curious how good or bad Java 3D really is. And as I always wanted to try to see, if my editor can be used to model for games I will try to write a simple game.

I choose Java 3D for two reasons over a dedicated game engine. The first is threads I read on gamedev.net. Many people want to build game engines lately and the standard advice is to build a game instead. And I agree with that sentiment, my whole development works the same way. I try to come up with generic solutions in my editor, yes, but the most important thing is to solve real world problems. I try to not add things I might need some time in the future, development is driven by what I need for the next model I want to do. So developing a game engine (whatever that is meant to be, there are many definitions) should be driven by a game. Only then you can be sure that the engine is useful and most free ones seem to not use that model.

The second reason is simply that I haven't given up to write something for my mobile phone. I haven't looked around, but as far as I know most of the game engines are too old to have a port for mobile phones. But from the bit I read it seems, that Java Mobile 3D is similar to Java 3D, so I hope I can use parts of the same code.

Today I only did some introductory stuff, I created the Eclipse project, added the Java 3D libs, created a frame and the canvas to draw to and started to build the scene. Currently it draws a black window.

I will try to reserve Thursdays for Java development. If I actually manage to stick to this little project I will create a new category on the blog. Also I will try to describe what kind of game I have in mind soon.

I am still working on that UV tool thing. Now most of the code is in place, only the function which actually executes these settings is missing. The UI is in place, it should load and save correctly and I can also create it. And it is about time I get it to work, as it starts to get on my nerves.

Yesterday I had started a tiny little feature and I got completely stuck on it. The feature I had planned was a UV-mapping modifier to mirror a UV-mapping like I need with the socks. But when I started to implement it, it felt wrong and so I stopped and started thinking what I really should be adding.

The point is, that the mirror thing is very different from the rest of UV-mapping stuff I have to date. They basically fall into three categories, automatic mappings, compound mapping and editor. The automatic mapping maps vertices to some object and uses that objects "natural" mapping to derive the uv-coordinates. Examples are a planar or cylindrical mapping, where all vertices are projected onto a plane or a cylinder. The compound mapping is a graphical editor to ease combination of the automatic mappings. I can move, scale and rotate the created mappings much easier with it. Finally the editor is a complete manual method of mapping the vertices.

The mirror thing doesn't fit any of those categories and so I didn't want to rush it out. What the mirror thing would start is a category which is best called tools. And so I started to think if it wouldn't make sense to combine a hand full of those tools into a common object.

That is, what I have started now, it will be able to change the aspect ratio of a mapping, rotate it, scale it to fill the plane, half of the plane (with the ability to select into which half to move the object), quarter of the plane and and finally mirror it. So for the socks I would select the right foots mapping, tell the modifier to map from 1:1 to 1:2 (stretch it vertically) and move it to the right half of the UV-plane. The left foot would get similar instructions, only it would be moved to the left half of the plane and include the mirroring option. Like that it makes a lot of sense, because I can completely implement this functionality by first uniformly scaling the object to fit the plane and then build up one single transformation matrix and just do all those modifications in one go.

I fixed the DDA today, I have found two stupid bugs in it. The first was that I marched into the wrong direction when the end point had "smaller" coordinates than the start point, the second was, that I sometimes marched a pixel to far. Now I am sure that the algorithm works, I can create a square and after the algorithm has run I actually get a square with constant height which drops off to 0, exactly as it should be.

I also worked on the socks. I only had to mirror the geometry and do the subdivision and extrusion. I haven't yet finished them, I first have to draw a texture to see, if the mapping indeed works and I have to create a variation. The current version uses the same UV-mapping for both feet, I want to create a second one where the mappings are separate. It would be possible to assign different textures to the feet by using different materials already. But one of the textures would have to be created mirrored and that is an extra step I don't like.

I think I finally fixed the calculations. In the third try and with a lot of time. It is quite simple, but I needed quite a bit of time to come up with the solution, probably because it is so simple. I think I will write a bit more about it tomorrow (or at least in the next week).

It seems to work ok with points and lines, but the areas look strange. I think the problem is something with the areas, though.

I implemented the DDA today. So the Lines-constructor is now finished. But it also showed, that I will have to go back over the height field building algorithm again, I don't think it is working correctly. Up to now it wasn't really so important as the results were rather artificial in any case. But slowly the terrain gets more abilities which make it possible to start modeling. I think I will look into that tomorrow.

Something I have done today as well is to add a new constructor describing closed areas with a constant height. It is very similar to the Lines-constructor so was easy to implement. There is still a problem with editing, points are not inserted correctly when the line connecting the first with the last point is clicked, probably an off by one error.

I implemented that constructor because it is the most simple example of the next class of constructors which need work. The constructors which describe areas will be fill with a color representing their height value and I have to find a way to draw them in the right sequence. If an area completely encloses another one, then it has to be drawn before the enclosed one so both are visible. It is not enough to sort them by height, because an area with a low height value can be in another one with a high value and then should be visible. The algorithm should handle that situation correctly (once I fixed it, that is).