P-152: Virtual World Concept Update 115: Collision (Ground Cover, Precipitation, and Projectile)

I have discovered another problem with the implementation of my spherical terrain concept. Currently, player collision works quite well, but no other form of collision works at all. Ie, I cannot add ground cover or shape replicators to the terrain, nor can projectiles or precipitation blocks collide with the terrain.

The reason for this is that the collision system, at the moment, just adds the polygons at the highest detailed tier (the ones closest to the player) to the collision list. As the player moves, this list is updated, so the player always has a complete collision mesh underneath them. However, this collision mesh only works for the nodes that are very close to the player, it wont work for projectiles impacting the terrain at a distance, or for distance trees or ground cover objects.

I will need to spend some time coming up with a solution for this.

Clearly, I can’t just add all of the visible polygons to the collision list, this would be far too slow, even with the frustum culling and CLOD system that I have in place. I also can’t implement a quad-tree parsing system for each of the environment objects of projectiles, because this would also be too slow, (in the case of the large numbers of environment objects that would need to be created) and would not update fast enough to handle the fast-moving projectiles, resulting in them passing through the terrain in some cases.

Currently, I am looking at a hybrid system. I could add all of the nodes within a reasonable distance of the player to the collision list. With frustum culling and CLOD, I should be able to generate collision details in this way for a reasonable distance. This collision list would then be used for  ground cover, precipitation, “thrown” objects, and any user interaction with the terrain, such as creating/placing objects, etc etc. This should cover most of the requirements for the collision system, since the vast majority of the time, the player is only interacting with the area around them.

This terrain is designed for an online virtual world, which means all “Objects” (trees, buildings, large rocks, etc) will need to be stored on the server. This means that they don’t really need collision, the position of the object is set when the object is created, and simply stored. I can then page the objects in and out of the world without worrying about collision at all, since the terrain height hasn’t changed.

The only issue with this would be that the height of the terrain actually does change for distant objects, because of the CLOD system. As the resolution of the terrain changes, the height will change slightly too. This means that an object that would be placed neatly on the terrain at a high level of detail, could be floating above the terrain or stuck underneath it at a lower level of detail. I will also need to determine the position to place the object at in the first place, which would need to be done by parsing the quad tree, for each object. However, this parsing could be done at load time, during run time, the positions of the objects would only need to be updated if they changed, which wouldn’t happen often.

I could store multiple positions for the objects, one for each resolution that the object is visible for. This, combined with a fast parsing and subdividing algorithm and a reasonable collision distance, should result in a relatively serviceable collision solution.

AI players and projectiles fired over long ranges would be a problem however. The only way to really deal with that would be to add a quadtree parsing system for them, similiar to the players system. This would be slow.

I will likely need to research collision techniques further, to find something that works for this project. The challenge here, as before, is to find something that works with a very large world, and a Chunked Level of Detail implementation, since most terrains are much smaller, and are generated all at once.