Spiritus Astrum

I have made some progress with researching CLOD. It seems quite tricky to implement, but essentially, the data is stored in a quadtree. This quad tree is created at design time, and does not need to be recalculated every tick.

The algorithm then selects patches from the quad tree based on an error calculation. Patches further from the player are at a lower level of detail, while patches close to the player are in full detail.

I understand the basic concept, but before I can implement this, I have to figure a few more things out. For example, are the different LOD’s of the mesh stored in different quadtrees? Or are they somehow combined into the same quadtree? Does each patch get it’s own vertex buffer, or are they combined into one?

I will need to continue my research on this.

I have been researching the next stage of the spherical terrain. I need to implement some kind of optimised paging system. Rendering an entire planet-sized terrain at once is, obviously, impossible, so I need to find a way to page the terrain to ensure it can be represented in the game.

The two most common techniques that I have seen that are capable of this are geomipmapping and chunked levels of detail. I am researching both options at the moment, and I am currently leaning towards the CLOD implementation.

Once this is done, I should be able to render massive worlds with little difficulty.

I now have working player collision! This took a lot longer than I expected, and there is still quite a bit of work needed to clean this up, but it is working well.

The problem was that a variable was not being updated on the server, only on the client, and so the server didn’t have access to the polylist for the collision calculations. This is now fixed.

I can now begin work on large terrains, and optimisation of the collision system and rendering. I need to implement a system which only renders and collides with the polygons close to the player, and then updates these polys as the player walks around the surface of the planet.

I also need to deal with the famous 10,000 unit problem in Torque. Torque uses 32-bit floats to store position transforms, and when the player gets to about 10,000 units from the origin, these 32-bit values lose precision, and this causes a noticeable “jitter” effect. To deal with this, I would either have to replace all of the 32-bit floats with 64-bit floats, which would require major reworking of the engine, or, implement a system where the player actually remains at the origin, and the world moves around them.

This system is the one that I used in my Icarus Rocket Simulator, and it works quite well. This project is multiplayer however, which does make things more complex, since I will need absolute coordinates on the server (in the database) and I will need to translate those to local coordinates for each player (centered about the origin).

I have made quite a lot of progress with the collision issues that I have been having, although player collision is still not working. I now believe that the issue lies in a particular variable not being updated on the server.

What I think is happening is that the collision is being detected on the client, and the list of collision polygons is being generated on the client. However, that list of polygons is not being sent properly over the server, and so the server doesn’t have anything to collide with, resulting in no collision.

The collision with objects of the item class probably works because it’s collision system is different, and simpler.

I am currently implementing a solution which I believe will fix this issue.