Research

With the Free Edit Modifier nearing an end I will try to finally model a blossom and get the plants to look
more realistic. I will also make more changes to the plants as I have
in the meantime managed to read past the first chapter of an entry level book on botany. The first chapter was not very interesting for me, it was an introduction to molecular biology, but I fear that they will use a lot of the concepts from that chapter later on.
It had its good points because I already found out that I had forgotten
a very important property of plant growth: light influences plants. So
I will probably add some support to find out, how bright a part of a
plant is.

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.

I tried a bit more and it is finally looking at least a bit like what I intended, but it won't work like that. The problem is that I am missing too much information to create the correct image. I am still sure that the principle is sound, but it won't work like that. I would need a complete description of the light arriving at the lens and that is not possible to derive from the image shot by an infinitely small aperture (as raytracing uses a single point as aperture).

To describe the problem I need a bit longer explanation. The description of the "circle of confusion" is correct but also confusing. Because it technically only is correct for a completely unobstructed point. In a real scene that is often not the case and so you can't really use the circle of confusion directly.

As promised I spent most of my time to create images of the formula behind rendering scattering media. I also calculated the formula for the next step I intend to do. As I haven't tried that last solution yet, I can't promise it is correct.

Quite some time ago I have started to implement the first animation support. And even earlier I had obviously started to implement the polyhedra and there decided on a design for the objects and their surrounding. For some time I have been thinking about some issues related to both and their design.

I wasn't just lazy yesterday, I also worked on sketches for an idea I had some time ago. If you looked into my ToDo-List you might have seen the point about height-fields. The idea I work on is not directly related to that, but would also work with my current implementation, it is an orthogonal issue.

Background

If you looked into this months todo-list you might have noticed I added the entry "plants" to it. I have been reading papers of how to do plants for some time. It isn't exactly easy, I think. If you want an overview, Algorithmic Botany is a good start. At the end of the publications page you find a PDF-version of the book The Algorithmic Beauty of Plants which contains quite a lot of background on L-systems, the standard technique for modeling of plants.

My problem is, that I never really liked L-systems. They are a nice formal description, but I simply can't see an easy way to program with them. And I don't seem to be alone in that respect. At last years SIGGRAPH there was a sketch presented by Gokhan Kisacikoglu from DreamWorks Animation Studio which showed how they did the hedge in the movie "Over the Hedge".

As you may have noticed I have been working with the terrains lately. I still don't like the stuff I have implemented a lot, so I have been looking around a bit if I could find new ideas. And I indeed did find some interesting stuff.

I was far too tired today to continue programming. But I can at least finally write about the search I was doing some days ago to find out, how to do inverse kinematics. I currently only have the reverse, forward kinematics. That means, that I would for example bend the shoulder of a character which would also move the elbow, the hand and so on. So to grab a cup I would first have to try to get the upper arm into the approximate position, then the lower arm, then the hand and so on. As you might imagine, it is nearly impossible to get that right in the first try so you normally iterate to the final position.

Inverse kinematics on the other hand works in the other direction. You grab the hand and move it to the cup. The system then calculates the movements of the arm and possibly the shoulder and if necessary the spine and so on. In theory you could even integrate the feet, although I never have heard of a system which incorporates a walk cycle so the character would make some steps to the target. This is much easier to use, but it is not easy to implement. So I went to search for papers how this works.

I found Inverse kinematics positioning using nonlinear programming for highly articulated figures from Jianmin Zhao and Norman I. Badler from October 1994 which seems to be something like the base of all of the modern systems. I haven't worked through it yet, only a bit. It isn't easy and I think there will be some problems to implement something like it. So I will probably postpone it quite a bit. And so I continued to look for something simpler. One of the problems when posing a character is, to not move parts to an unnatural angle. So if you could at least constrain the possible movements it would make it a bit easier. Additionally you need something like that for IK as well, as you normally assign constraints and weights to the joints. A human will normally move the elbow if it is possible and not leading to an uncomfortable position. E.g. when you type on a keyboard, your hands move a lot, your elbows quite a bit and your shoulders only slightly. But an IK-system doesn't know that intrinsically, it needs some form of constraints. That also means, that you would change the weights if you want to simulate someone with some kind of wound, e.g. a character with a badly bruised arm will try to not move it too much and so the weights of some joints will be different.

And so I found Fast and easy reach-cone joint limits by Jane Wilhelms and Allen Van Gelder, a quite interesting paper on how to constrain the possible movements of a joint. It is not specific to quarternions, but it is quite well suited for them. It basically draws polygons on a unit sphere and constrains movements to the inner of that area. Additionally it defines a (somewhat simple) subdivision scheme so the constraint area is smooth. That area only constrains the bone in two dimensions, rotations around the bone are handled by a quite clever scheme of attaching twist angles to the vertices of the control points and using a system similar to barycentric coordinates to interpolate between the discreete points. I think it probably would be possible to add weights in a similar fashion. I think I will implement this in the nearer future. But first I will have to get the skinning working and also make the skeleton animatable.

I thought a bit about the raytracer and the height fields and I thinj, I will eventually really implement a specialized structure for it, so I can use the complete field for rendering. That does not mean, that my work on LoD was in vain, I still need it for OpenGL preview. Additionally it will be used for the terrain model.

Last talk at the course for now was very interesting for me. This one was about the problems with animated scenes. There are problems with animations, as the speed up structures are often not easy to rebuild. So you might loose the advantage you get from them with animation.

Attending the Realtime Raytracing Course was a good idea. I already wrote, that it makes sense to do raytracing in clusters to let the systems caches work for you, but now I am also sold on implementing kd-trees.

As I had considerable problems to create useable height maps, I started to explore the possibilities. I already implemented a simple fractal landscape generator (using the Square and Diamond scheme, see the last entry before this one). But there are problems with that.

Another model, another lesson. Seems I get the most ideas from actually using my program. I am happy, that it is like that, because the latest small changes proved to be very good. Without them I probably could not have modeled the cog wheels.

But there are some things, that I missed. One was stability, I have a memory corruption somewhere. Have not found it yet and I have the impression, it is from the UI. I have noticed something when the properties dialog is open, every selection recreates it (yes, recreates it. The dialogs contents is destroyed and recreated). Ths is not necessary and I will change it. I think, that occasionally leads to the corruption.

The second thing I was missing was a command to turn the objects. I had modeled the cog wheels in the plane and then wanted to turn them upright. Forgot it and tried afterwards. Well, it didn't work. I then instead moved the light source . But that will not help in the future. So I will have to add a command for that.

I currently don't use the status bar. I think, I will have to, as I start to forget the commands I already added. So I need them to remind me. Should not be too difficult.

I cannot change the material in groups. Groups are a problem in general. Copying objects out of the group does not work, copying in neither. I cannot even move object in and out of groups. That will have to be changed. The command to ungroup objects was missing as well, but I needed it to finish the model, so I added it already.

The last one is a practical one. The files are getting to big, as I store all of the intermediate steps. I think, I will add something to not do that. Will speed up saving, loading and even working with the models. As long as you only have one object, it is OK, but it does not make sense, to load that stuff for objects, you haven't touched for some time.

I am still working on the Octtree, but I also started to actually find out, which other space partitioning schemes there are. Found a really interesting article (5 years old though), that had benchmarks for 14 different schemes. That article also showed me to the SPD (Standard Procedural Databases), a system to help benchmarking different raytracers. As the linked overview puts it, "[w]ith these databases
we may be comparing oranges and apples, but it's better than comparing oranges
and orangutans".

I am actually very happy to find this, as it should help me, to at least get some reliable test cases. Using only my own ones always poses the risk, that I inadvertantly use only cases, that are good for my system.