The planets really need a cloud cover ... It's in the pipeline.
Networking
I finally ended up implementing a client side prediction algorithm to provide first person shooter style interactivity with real time responses. After tweaking and experimenting for a while, I came up with a pretty robust and efficient solution using UDP. I have also added chatting capabilities and developed a reliable protocol on top of UDP, which is necessary for picking up objects or entering spaceship.
There are still improvements necessary to launch a demo server, including a user database and some kind of authentication. That will stay on the back burner for a while longer though. First, I would like to see a little more artwork in the demo and add some kind game play, either combat or skill based.
Planet Rendering
I have also improved how terrain patches are selected for splitting and merging. Until now, this decision was exclusively based on the screen space error of a patch. Now it also depends on the number of patches which are still unused out of the 1300 that are initially allocated. This has the effect that the planets are much more detailed when you are looking at them from space.
I have also increased the number of threads used to compute the geometry of the terrain patches. There are a lot of concurrency issues, especially since patches need to access their neighbors in order to compute smooth surface normals along the edges. It seems to me that concurrency on the patch level is too coarse and multi-threading is not right way to utlizie multiple cores. It will be interesting to see what kind of APIs and examples Intel comes up with for Larrabee.
Collision detection
I have created different collision categories which allows for fairly fine control over how objects collide. For example, a shuttle consists of a triangles mesh and a simple collision shape such as a box. The collision shape is only used for collisions with other triangles meshes, while the triangle mesh will collide with other simple collision shapes, but not triangle meshes. This way mesh-mesh collisions can be avoided but avatars and vehicles can still enter the shuttle bay. Here is an image of a vehicle in the back of a shuttle. The shuttle can actually fly away with the cargo secured in the back, land somewhere else and then the vehicle can exit the bay; all of it completely seamless.
Game Mechanics
Finally I have also worked on the dynamics of landing a space ship on the surface of a planet. Since the planet is generated by a noise function it becomes expensive to compute the exact shape of the terrain below the spaceship. An easier solution is to sample the surface at three points around an object and then create a plane against which to perform collision detection. This works rather nice, but it causes some strange artifacts such as the shuttle penetrating the terrain or vice versa (left image). This problem becomes even more pronounced on an uneven surface, especially where the features are smaller than the size of the shuttle. I have therefore come to the conclusion that space ships can only land on flat surfaces (right picture). In order to enforce this, I have come up with a simple sampling technique that determines how uneven the ground is. Depending on this metric, the spaceship will take damage. If the ground is too rough then it will get destroyed very quickly. I am quite happy with this approach. It will make for some interesting game play. Very large ships that may transport a lot of cargo can only land on certain spots; maybe not at all on some planets. Of course, there is always the possibility to construct a landing platform, where ships can safely land without taking damage.
